那一年我还在读研二，投字节跳动2018校招Android方向（第四批）的时候，其实没有抱太大希望。当时字节的校招声势已经很大了，尤其是头条系产品如日中天，知乎、牛客上全是面经，随手一翻都是“三面算法题”“四面HR聊人生”之类的帖子。我属于那种专业课不差、但项目经历平平的普通候选人，投第四批本来就是想练练手，没想到这一趟走下来，反而把我对Android整个知识体系的理解重新梳理了一遍。这篇文章不是面经搬运，而是我当时考完试就着记忆写下的复盘，后来工作几年再看，很多题确实值得反复咀嚼。
先说结论：字节2018校招Android方向第四批的题目风格，和别家最大的区别是——它不怎么考“八股文”式的标准答案，而是大量给你一个实际场景，问你“怎么排查、怎么设计、怎么优化”。面试官全程盯着你的思考路径，而不只是对错。这篇文章适合正在准备Android校招的同学，也适合那些想看看大厂到底怎么考察候选人的开发者，我会尽量把每道题背后的考点和原理都拆给你看。
1. 2018年第四批笔试：几道让我印象深刻的真题
1.1 在线笔试的整体结构与时间分配
第四批笔试是在牛客网上做的，我记得时间是19:00到21:00，整整两个小时，题目分三块：不定项选择题、两道编程题、一道系统设计题。选择题大概有20道，覆盖面特别广，从Java基础、数据结构、网络到Android四大组件、Handler、Binder，几乎每个方向都扫了一遍。我当时最大的感受是“范围太宽了”，如果平时没有系统积累，临时抱佛脚根本来不及。
这里先说一个重要的时间分配经验：选择题如果30秒内没有明确思路，立刻标记跳过。因为后面的编程题分值高、耗时大，系统设计题更是需要整块时间构思。我当时给自己定的红线是选择题最多花40分钟，剩下80分钟全部留给编程题和设计题。实际做下来，选择题大概用了35分钟，有两道不确定直接蒙了，事实证明蒙题在某些情况下比死磕划算得多。
1.2 两道编程题：算法与数据结构的直接考察
编程题第一道是“合并多个有序链表”，但加了点变形——链表节点里除了val还有一个priority字段，要求按priority升序合并。本质上就是多路归并，用优先队列就能解决。考的是你对Java PriorityQueue（或手动实现堆）的熟练度，但如果没看出来是“多路归并”这个模型，就会走弯路。我当时用的PriorityQueue，比较器按priority排序，每次取出堆顶节点接到结果链表尾部，再将该节点的next入堆，时间复杂度O(NlogK)，N是总节点数，K是链表条数。
第二道题是“字符串中的最长无重复子串”，这题在LeetCode上是第3题，滑动窗口的标准解法。但字节在这道题上埋了个小坑：输入字符串可能包含中文和emoji，如果你直接用String.length()取长度，再按charAt遍历，遇到emoji就会出错。因为Java里char是UTF-16编码单元，emoji是代理对，会占两个char。所以正确做法是先转成codePoint数组，或者用String.codePointAt()配合Character.charCount()来滑动。这个细节当时坑了不少人，也提醒了我：大厂算法题不光是数据结构，还考察你对语言底层编码的理解。
1.3 选择与填空中的高频Android陷阱
选择题里Android相关的占比大概三分之一，几乎每一题都踩在一个常见的误区和边界条件上。我挑几个印象特别深的回顾一下。
第一题：Activity的启动模式。题目描述了一个场景：A是standard模式，B是singleTask模式，从A启动B，再次从A启动B，问任务栈里最终有几个A实例、几个B实例。这题看起来简单，但singleTask的“栈内复用”和“clearTop”行为很容易记混。standard模式每次启动都会创建新实例并压入当前任务栈；singleTask启动时，如果栈内已有实例，会把该实例上面的所有Activity弹出，然后复用该实例。所以答案是栈底一个A，B复用一个，A的第二个实例被clearTop干掉了。后来我在实际项目里遇到过类似问题——从分享链接拉起App主页时，如果不小心把主页设成了singleTask，会导致用户在二级页面点分享返回后被“清栈”，体验非常诡异。这是面试题直接对应生产事故的典型例子。
第二题：ContentProvider的uri匹配伪代码。题目给了一段ContentResolver查询的代码，问你uri的authority和path分别是什么。这题直接对应了后来热词里那串content://com.baidu.searchbox.fileprovider/baiddpath/android/data/com.baidu...之类的东西。其实考的就是ContentProvider的基础结构：content://authority/path。authority是唯一标识，path是资源路径，真正复杂的是多级path和通配符匹配（*、#），但那年笔试还停留在最基础的语法解析层面，没有深入到底层。
第三题：Android Studio的构建流程。问的是编译APK时，R.java、resources.arsc、classes.dex各自的生成顺序。这题我答得不完整，因为我当时真的没细想过资源编译流程。现在回头看，R.java是资源索引，resources.arsc是资源映射表，classes.dex是Java源码编译后的字节码，标准构建顺序是：资源文件先被AAPT编译打包生成R.java和resources.arsc，然后Java源码和R.java一起被javac编译成.class，再通过D8/R8转成dex。在AGP（Android Gradle Plugin）高版本里R类改成了R2，还涉及到非传递性R类，这些都是后话了。
1.4 那道系统设计题：日志SDK的设计思路
笔试最后一道题是“设计一个App内的日志上报SDK，要求性能好、不丢数据、不阻塞主线程，并且要便于后续扩展”。这种题在笔试里比较少，更像面试中的开放题，说明字节从笔试阶段就在筛选“有工程思维”的人。
我当时从四个维度答的：第一，采集层用单例+队列，子线程写文件，避免主线程I/O卡顿；第二，存储层用文件分片，超过一定大小就滚动写新文件，防止单个文件过大；第三，上报网络用独立的Service或者WorkManager，结合WiFi状态做延时上报；第四，策略层要做分级，普通日志当天上报，崩溃日志立即上报。后来工作里真正做过埋点SDK，才发现当时的答案太理想化了——漏掉了文件损坏、磁盘满、加密、多进程并发写这些真实场景。但至少当时展现出了“分层设计”的思维，这可能是通过笔试的关键。
2. View、Handler与线程通信：Android基础面的深水区
2.1 Handler/Looper/MessageQueue：你以为懂，一问就露馅
笔试结束后一周收到了面试邀请，两轮技术面，第一轮开头不算太刁难，但很快进入了我最虚的领域：Handler机制。面试官问了一个我现在还记得清清楚楚的问题：“子线程里能不能创建Handler？如果能，需要满足什么条件？为什么主线程可以直接new Handler？”
这个问题表面考的是Handler，实际考的是Looper.prepare()和Looper.loop()的机制，以及ThreadLocal的底层原理。主线程能直接new Handler，是因为ActivityThread在main()方法里已经调用了Looper.prepareMainLooper()和Looper.loop()。子线程如果直接new Handler，会抛RuntimeException：Can't create handler inside thread that has not called Looper.prepare()。正确做法是在子线程里先调用Looper.prepare()，再new Handler，最后调Looper.loop()。当然现在有了HandlerThread，就不用这么裸写了。
但面试官显然不满足于这个答案。他紧接着追问：“如果Looper.loop()是一个死循环，为什么主线程不会卡死？ANR是怎么触发的？”
这个问题才是真正的分水岭。我当时磕磕绊绊说了“loop里拿不到消息就阻塞在nativePollOnce”，但说不清楚阻塞和ANR之间的区别。后来看了张绍文等大佬的解析才彻底明白：主线程的Looper.loop()确实是个死循环，但它不会真正占满CPU，因为当MessageQueue里没有消息时，loop会进入epoll阻塞，等待下次消息写入时通过pipe唤醒；而ANR不是因为这个死循环产生的，而是因为某个事件（如输入事件、广播、Service）超时没被处理完，系统ActiveServices或InputDispatcher才会弹ANR。死循环是主线程的“等待方式”，超时是业务处理超过阈值，两者不在一个维度。
2.2 自定义View：Measure、Layout、Draw的现场推演
一面第二题关于View。面试官在电脑上投了张截图，是一个类似环形进度条的自定义View，让我口述measure和draw的流程，重点说onMeasure里如果没处理wrap_content会怎样。
这题的坑在于：直接继承View的自定义View，如果不在onMeasure里处理MeasureSpec.AT_MOST模式，那么它的默认行为就是占用父布局剩余空间的全部或直接使用父容器的可用大小，效果等同match_parent，wrap_content就会失效。标准写法是给wrap_content指定一个默认尺寸，比如200dp，然后在onMeasure里判断MeasureSpec.getMode()是AT_MOST时使用这个默认值。
接下来是draw流程，面试官问的是“Canvas的drawXXX方法内部到底发生了什么”。我当时答了“调用Skia底层绘制”，但不够细。实际上Canvas.drawCircle最终会经过DisplayListCanvas（新版本是RenderNode）的记录，把绘制指令记录为一条条DisplayList，再由RenderThread在GPU上渲染。这是硬件加速的基础逻辑。所以“自定义View性能优化”里有一个经典手法：在onDraw里避免分配对象、避免复杂路径运算，本质上就是为了减少DisplayList的记录开销和GPU渲染压力。
另外面试官还问到了View.post()为什么能在子线程安全地更新UI。这个点很冷门但很有意思：View.post()在View还没attach到Window时，会把Runnable存到View的RunQueue里，等dispatchAttachedToWindow时再通过Handler执行；如果已经attach了，就通过mAttachInfo.mHandler.post()。所以“子线程里更新UI”真正可靠的方式是post到主线程Handler，而View.post()只是一种便捷封装。
2.3 线程通信题目背后的真实场景
两轮面试里线程通信相关的题出现了三次，除了Handler，还问了AsyncTask在并发下的问题，以及线程池怎么选型。AsyncTask这题其实是在考“你知不知道它已经过时了”。在Android 11（API 30）里AsyncTask已经被标记为deprecated，主要原因是它自身的串行/并行切换逻辑反直觉，而且容易在Activity销毁后回调导致内存泄漏。我当时坦诚地说自己项目里用过AsyncTask但后来都改用Kotlin协程，面试官反而点头认可了。
这里特别想提醒后来的候选人：不要为了显得“精通”而死记硬背一些技术，大厂面试官非常擅长顺着你说的名词往下挖，一旦发现你是背的，印象分会大打折扣。我当时宁可承认“源码没读全，但我知道设计思路和适用场景”，也好过硬着头皮编。
3. Framework题：AMS、ContentProvider与系统服务调用链
3.1 “启动一个Activity，进程里发生了什么”——被追问到第三层
二面开始后，面试官的节奏明显快了很多，第一个问题就是“从点击桌面图标到Activity显示出来，系统做了什么”。这种题在当年Android面试里已经算常规题，但字节的面试官会一层一层往下追，直到你答不动为止。
我当时的回答框架是：Launcher通过Binder调用AMS.startActivity，AMS检查Activity的进程是否存在，如果不存在则通过Zygote fork新进程，新进程入口是ActivityThread.main()，里面创建主线程Looper、注册ApplicationThread，然后调用AMS的attachApplication，AMS再通过ApplicationThread的scheduleLaunchActivity通知应用创建Activity并执行生命周期。核心链路就是：Launcher → AMS → Zygote → ActivityThread → 生命周期回调。
面试官显然要往下深挖，他追问了两个细节。第一个是“AMS和ActivityThread之间的通信是靠什么”，我回答是ApplicationThread这个Binder对象，它运行在应用进程侧，作为服务端接收AMS的调用。第二个问题是“你说AMS在system_server进程里，那system_server和Zygote是什么关系”，这个问题差点把我问懵。我努力回忆后答出：system_server本身也是由Zygote fork出来的，但它是“特殊”的子进程，承载了AMS、WMS、PKMS、PMS等一大堆系统服务，所以它崩了系统就会重启（软重启）。这个答案算勉强过关。
后来我意识到，这种追问模式的核心目的不是让你背出所有源码头文件，而是看你在“知识地图”里能不能准确定位到每一个概念的位置，并且通过Binder这条主线把它们串起来。所以准备这类题的时候，最好的方式是画出你自己的调用链图，而不是直接背面经。
3.2 ContentProvider与FileProvider：一场真实的跨应用授权实战
第二轮的第二个问题反而接地气了很多。面试官问我：“如果你要在App里调起系统相机拍照，然后把照片传给另一个App处理，该怎么安全地传递这张照片的URI？”
这题问的就是FileProvider。Android 7.0以后，直接传file://URI会抛FileUriExposedException，必须用content://URI配合临时授权。FileProvider本质上是一个特殊的ContentProvider，它在Manifest里配置的authority，就是后来我在热词里看到的那种content://com.ss.android.uri.key/external_root/android/data/com.ss.android...。这个字符串的格式就是authority+path的组合。
实际操作流程是：在Manifest里声明FileProvider，配置android:grantUriPermissions="true"，在res/xml里写好paths，把实际文件路径映射成/external_root/android/data/你的包名/...之类的逻辑路径，然后通过Intent的setClipData和addFlags(FLAG_GRANT_READ_URI_PERMISSION)把读取权限临时传给目标App。目标App在onCreate里通过ContentResolver.openInputStream就能拿到输入流。
那年面试官还补了一个热知识：“如果目标App临时权限失效怎么办？”答案是：ContentResolver.openInputStream(uri)在权限有效期内才能用，如果对方一直持有你传的URI，在授权失效后再读会抛SecurityException。所以严谨的做法是配合permission的持久化授权（takePersistableUriPermission）但需要对方主动调用，或者直接在Intent里让目标App立即消费。这种细节非常能体现一个Android开发者的工程素养。
3.3 AMS、WMS、PKMS的分工与协作
三面时（其实我后来才知道那是二面加面），面试官让我聊聊AMS、WMS、PKMS各自负责什么，并且问“一个App冷启动过程中，这三个服务分别在哪个节点被调用”。
这个问题比前一个更有挑战性，因为它要求你知道的不只是单个服务的功能，而是它们在一件事上的协作顺序。我的回答思路是：
- PKMS负责在安装APK时解析Manifest，把Activity、Service、Receiver、Provider等组件信息存到包数据里，同时拿着签名信息做权限校验。
- AMS负责Activity生命周期和任务栈管理。它收到启动Activity的请求后，会确认进程是否存在，不存在就请求Zygote创建进程；进程存在就通过ApplicationThread驱动Activity的onCreate/onStart/onResume。
- WMS负责窗口管理和布局。Activity创建后通过WindowManager.addView把DecorView添加到WMS，WMS计算窗口层级和尺寸，然后交给SurfaceFlinger做合帧显示。
冷启动的调用顺序大致是：Launcher发起startActivity → AMS查进程 → 没有进程则和Zygote通信fork → 新进程初始化ActivityThread → attach到AMS → AMS通过ApplicationThread调attachApplication → 应用创建Application、启动Activity → Activity.onResume后通过ViewRootImpl向WMS请求布局 → WMS返回窗口信息 → 系统把窗口合成到屏幕。
面试官听完点头，然后问我：“那热启动和这个流程有什么区别？”这就简单了——热启动时进程已存在，直接走attachApplication之后的部分，少了fork进程和初始化Application的耗时，所以启动速度会快很多。后来做启动优化时，我立刻想到了这题的答案：“减少Application.onCreate的工作量就是在优化冷启动”，原理其实在面试那天就埋下了。
4. 从R8混淆到AGP版本：工程化能力的隐性考察
4.1 一道“APK瘦身与混淆”的题目，考的是思路不是命令
笔试和面试里都出现了和打包、构建相关的题，其中有一道是：“如果线上APK崩溃栈显示的是混淆后的方法名，你怎么定位到原始代码？”
这题的正确思路分三步：第一，保存构建时生成的mapping.txt文件；第二，用SDK里的retrace工具，执行java -jar proguard-retrace.jar mapping.txt stacktrace.txt把混淆后的类名和方法名还原为原始名称；第三，如果mapping丢失，就尝试用反编译工具（如jadx）结合崩溃地址做手工定位，但效率极低。这题背后其实是想看你有没有真正打过release包，而不是只在debug模式下跑过。
顺带一提，R8和ProGuard的区别也是热词里反复出现的。R8是AGP 3.4之后默认集成的压缩混淆工具，它同时做代码缩减、资源缩减、混淆和优化。和ProGuard相比，R8的优化更激进，比如能分析并删除大量不会被调用的方法和字段。但也因为“更激进”，偶尔会有误删导致运行时NoSuchFieldError或NoSuchMethodError的问题，所以keep规则要写得比ProGuard更精确。大厂面试里如果你能主动说出“R8的keep规则和ProGuard不完全兼容”，面试官会觉得你有实战经验，而不是只会搜索。
4.2 Android Studio与AGP版本：一场“环境地狱”的真实教训
热词里有人搜“android studio hedgehog | 2023.1.1 patch 2支持agp8版本吗”，这其实是2023年那会儿很多人被AGP和Android Studio版本匹配搞疯了的缩影。我在做某个老项目升级时，就因为AGP版本从4.2升到7.4，踩了无数坑，那时候才深刻理解为什么面试题会涉及构建工具链。
简单科普一下：Android Studio（IDE）和Android Gradle Plugin（AGP）是两个独立但强关联的东西。IDE要求最低AGP版本，AGP版本又要求最低Gradle版本、最低JDK版本。比如Android Studio Hedgehog（2023.1.1）通常搭配AGP 8.1/8.2，而AGP 8.0开始要求Gradle 8.0+和JDK 17。如果你只升级了Android Studio但项目里的AGP还停在老版本，IDE会直接提示“This version of the Android Gradle plugin requires a newer version of Gradle”之类的话。
我的建议是：不要盲目追新，项目的AGP版本能用就不要轻易动。如果必须升，一定要先看官方兼容性表，然后保证 gradle-wrapper.properties、build.gradle里的AGP版本、JDK版本三者匹配。热词里的“android studio 4.1.3下载”说明还是有人用的是老版本，那我多说一句：除非项目锁死，否则别再用4.1.3了，因为很多新的依赖库最低都要求AGP 7.0以上。
4.3 MVVM架构题：从“会不会用”到“为什么这么设计”
二面快结束时，面试官问了我一个偏架构的问题：“你们项目里用的是什么架构？如果用MVVM，ViewModel在配置变化时为什么不会丢失数据？”
这个问题如果只看面经，答一句“ViewModel在Activity重建时通过ViewModelStore保存”就可以了。但字节的面试官会追问：“ViewModelStore是谁来管理的？Activity重建时它为什么不会被销毁？”
答案是：Activity被重建时，系统会调用NonConfigurationInstances机制，将旧的ViewModelStore实例传给新的Activity。具体来说，Activity.onRetainNonConfigurationInstance会在配置变化时被调用，把ViewModelStore放进去，新Activity在attach时再把它取回来。而普通的成员变量不具备这个能力，因为Activity实例本身就是新创建的。所以ViewModel能够存活，靠的不是ViewModel本身，而是系统对ViewModelStore这个容器的特殊保留机制。
这个回答如果能在面试中完整讲出，几乎就是稳了。我当年只能说个大概，但现在回头看，这种架构题的底层就是Activity的重建机制和NonConfigurationInstances链路，理解了这个，再去看ViewModel的源码就会豁然开朗。
4.4 关于R8、AGP这些“工程化”题，为什么要重视
热词里还有“android r8”“android framework”“android ams”并列出现，这其实说明很多人在搜索时是带着“一次性搞清楚”的心态在整理的。我的感受是，校招笔试选择题可以考命令和参数，但面试里的工程化题，考的永远是“你是否出现过、解决过、总结过”。比如R8导致崩溃的问题，你没遇到过是真的编不出来；可一旦遇到过，你就会明白keep规则为什么重要、mapping文件为什么“打死不能删”。
5. 现场两轮技术面：开放题、手写代码与压力测试
5.1 手写LRU Cache：不背到肌肉记忆就会被淘汰
现场面试有一道手写题：实现一个LRU Cache，要求get和put都是O(1)复杂度。这道题在字节面试里的出现率极高，2018年是这样，到现在也还是高频题。
我当时没用LinkedHashMap，而是手写了HashMap+双向链表。因为面试官明确说“不要直接用LinkedHashMap，我要看你对数据结构的理解”。手写双向链表的思路是：HashMap里存key到Node的映射，Node有prev和next指针，维护一个伪头节点和伪尾节点。get的时候从HashMap取Node，命中就移动到链表头部；put的时候先判断key是否存在，存在则更新值并移动到头部，不存在则新建Node插到头部，再判断链表长度是否超过capacity，超过就删除尾部节点，同时从HashMap里移除对应key。
这个题的关键不是代码本身，而是你别紧张，在纸上把结构画清楚再写。我当时先画了五个元素：head哨兵、tail哨兵、HashMap、Node节点、capacity。然后写代码，最后跑了几个测试用例。面试官追问了一个细节：“为什么链表节点要存key？”答案是删除尾部节点时，需要通过key来从HashMap里remove，如果Node只存value，在删除时还得额外遍历HashMap。
5.2 开放设计题：写一个图片加载库的核心流程
还有一道开放题，面试官说：“假如让你设计一个类似Glide的图片加载库，从加载到显示你认为最核心的5个模块是什么？”
这道题其实没有标准答案，但在大厂面试里几乎成了固定节目。我的回答是：
- 请求管理层：统一处理加载请求，去重、取消、优先级。
- 缓存层：内存缓存（LruCache）→ 磁盘缓存（DiskLruCache）→ 网络下载三层。
- 解码与变换层：BitmapFactory解码，支持采样率压缩、旋转修正、圆角/模糊等变换。
- 生命周期绑定层：通过Lifecycle监听页面销毁，及时取消加载、释放资源。
- 线程调度层：网络请求放IO线程池，解码放CPU线程池，回调切主线程。
面试官问我：“如果让你优化，第一优先会优化哪一层？”我说优先做缓存层，因为缓存命中率直接决定加载速度和流量消耗。他表示认可，然后补充说“实际上Glide里还有一个很重要的模块是Bitmap池，用来复用内存，这不只是性能优化，更是内存管理的关键”。这句话后来在我做项目时反复验证成真——大量图片加载场景下，没有Bitmap复用，频繁GC和内存抖动非常可怕。
5.3 行为面试：被问“你最大的一次技术失误”
出乎意料的是，二面最后居然问了一个行为题：“你过去做过的项目里，最大的一次技术失误是什么？后来怎么解决的？”
这题我当时差点翻车，因为我差点开始背诵那种“简历里没有真实经历但面经里常见”的回答。但我犹豫了一下，决定讲一个真实的案例：我研究生期间做了一个校园二手交易App，上线前没做多机型适配，测试机是小米系统，运行很流畅；结果发布后，有好几个用户反映在华为、OPPO机器上启动就闪退。后来排查发现是SharedPreferences里存了一个巨大的JSON字符串，在低端机IO缓慢导致ANR，而且我用了一个只在高版本系统上可靠的API，低版本直接找不到方法。
这个案例虽然不够“高大上”，但面试官看到了真实的排查过程，他接着问：“排查时你最难忘的定位手段是什么？”我说是抓logcat崩溃日志，再通过用户反馈的具体机型反查，最后用adb install一个旧版本APK逐步对比。现在想想，这个回答之所以没扣分，是因为“真实感”太强了。大厂面试官见过太多背答案的候选人，一个能自圆其说、有细节、有教训的真实故事，价值远高于一个漂亮但没有体温的成功案例。
5.4 HR面与整体节奏
两轮技术面结束后是HR面，问的问题相对常规：为什么想来字节跳动、职业规划、手里有没有其他Offer，以及能接受的工作地点。那年字节在北京、上海、深圳都有Android岗位，HR会问你的城市倾向，这个一般不影响技术面评价，但会影响后续部门分配。
唯一想提醒的是：HR面不代表稳了，但也不代表随便聊。我见过有人因为在HR面时表现出“我要拿Offer当跳板”的态度，被直接挂在池子里。HR会评估你的稳定性、沟通能力、团队匹配度，尤其是当你和另一个候选人技术考核差不多时，HR的一票就显得格外重要。所以哪怕技术面聊得再high，最后这轮也要认真对待，体现真诚和职业素养。
6. 复盘清单：给后来者的Android校招准备路径
6.1 基于这次真题整理的知识点地图
我把自己在2018年字节第四批笔试和面试中遇到的所有知识点做了个分类，整理成下面这份“自查表”，现在回头看依然有参考价值：
| 考察方向 | 具体知识点 | 推荐准备方式 |
|---|---|---|
| Java基础 | 集合、HashMap/Hashtable、String/StringBuilder、异常体系、反射、泛型 | 读源码，重点看HashMap的resize和put流程 |
| 并发 | synchronized、volatile、ReentrantLock、线程池参数、Handler线程切换 | 自己写Demo验证可见性和原子性 |
| Android基础 | 四大组件、启动模式、Handler/Looper、View绘制、事件分发、Binder | 结合源码和实际崩溃案例双线准备 |
| Framework | AMS/WMS/PKMS、Activity启动流程、ContentProvider原理、SystemServer | 画出调用链图并复述三遍 |
| 工程化 | Gradle构建、AGP版本兼容、R8混淆、APK瘦身、多渠道打包、CI/CD | 一定要亲手做过一次release打包 |
| 架构 | MVC/MVP/MVVM、Jetpack、组件化、插件化 | 能说出每种架构解决什么问题、代价是什么 |
| 算法 | 链表、树、动态规划、LRU、TopK、滑动窗口、二叉树遍历 | LeetCode高频题至少刷100题以上 |
这张表不是要你背，而是要拿来当“检查单”用——每个格子你能否用一分钟讲清楚原理？能不能举出实际项目里的对应例子？
6.2 面试官视角的三层考核模型
复盘了整场面试之后，我总结出字节面试官选拔Android校招候选人的三个层次：
第一层：基础是否扎实。Java、算法、数据结构、Android组件与消息机制，这些是硬通货，答不上来基本直接淘汰。第二层：是否理解原理。比如Handler的epoll阻塞、AMS的启动调用链、ViewModel的NonConfigurationInstances，如果你能说出底层机制而不是背结论，分数会明显高一个档。第三层：是否具备工程思维。面对开放设计题时，你能否分层拆解、识别风险、拿出可落地的方案，这决定了你是否能在团队里真正独立干活。
这三个层次不是割裂的，而是层层递进。很多人只准备第一层就冲去面试，结果第二层就直接露馅。我的经验是：准备基础知识时，每掌握一个概念，多问自己两个“为什么”——“为什么这样设计？”“如果不这样会有什么问题？”把这个习惯养成后，你就不会在层层追问下慌了。
6.3 简历评分标准与表达建议
针对2018年那个时间节点，我的简历写得其实挺普通的，但幸运的是在面试中讲项目时，我注意了几个原则，后来发现这些原则确实有效：
- 项目描述里“负责”“参与”这类词不要出现，直接用“实现了XX功能，解决了XX问题，性能提升XX%”，用数据说话。
- 讲项目时先讲背景和难点，再讲方案，最后讲结果和反思，这比平铺直叙有感染力得多。
- 项目里每一个技术名词都要能展开讲，比如写了“使用Glide加载图片”，就要准备好被问“Glide的缓存机制是怎么设计的”“如果图片加载失败会怎样”。
- 不会的技术不要写，写了就一定要懂。面试官最反感的是简历上写着高深技术，但一问三不知。
6.4 一些个人体会和踩坑教训
最后说说我的个人体会。2018年那次字节面试，我其实没有拿到Offer——两轮技术面都过了，但最终因为HC数量和其他原因被放进了备选池，后来也没捞起来。当时挺失落的，但现在回头看，那场面试对我职业发展的帮助远大于一纸Offer。因为它让我明白了几个很重要的事情：
第一，面试不应该是“背答案”，而是“展示思维”。字节的面试官几乎每次都会追问“为什么”，这种压力会逼着你把“知道”变成“理解”。第二，Android面试的范围远不止Java和四大组件，Framework、工程化、架构、算法缺一不可。第三，准备面试最好的方式不是刷面经，而是拿着系统源码和一台真机，亲手把知识链条打通。
如果你现在正在准备Android校招，我想给你一个最实用的建议：准备时间线至少留出三个月，第一个月吃透Java基础和Android基础，第二个月往Framework和工程化方向扎，第三个月全部用来做真题和模拟面试。面试时如果遇到不会的题，大方承认“这块我没深入研究过”，但接着补一句“我理解的相邻领域是XX，如果允许的话我可以从那个角度尝试分析”——这种态度比硬装懂要好一百倍。
那场面试已经过去很多年，但每次有学弟学妹问我“Android校招该怎么准备”，我都会翻出这份复盘给他们看。技术会过时，题目会更新，但“一层层往下问，直到问到底”的考察逻辑，和“用真实经历而不是漂亮辞藻打动面试官”的原则，到今天依然成立。
