2017年的校招季，我翻出了当年收藏的挖财安卓工程师笔试试卷。考的不是什么刁钻算法，反而是大量基础题、原理题和场景题。作为一家做记账理财的互联网金融公司，挖财在2017年就问过Handler机制、AIDL、图片缓存、内存溢出这些老话题，同时也考了类似“如何保证本地数据安全”“怎么处理弱网环境下请求失败”这种业务感极强的题目。今天换个视角，把这份试卷当做一个案例来拆，聊聊每一类题背后到底想考察什么，安卓校招面试准备应该怎么使劲，顺带把高频考点的底层原理和答题思路理清楚。
现在回头看，这份试卷的最大价值不在“会不会做题”，而在它完整展现了校招面试官在筛选候选人时的逻辑：基础扎不扎实、原理理解透不透、工程意识有没有、遇到线上问题的排查思路是否清晰。这四个维度，直到今天依然是安卓岗面试的主线。
1. 整体出题思路与考察方向拆解
1.1 为什么基础题是重头戏
挖财这份试卷一大半题目都围绕着安卓四大组件、消息机制、异步任务、性能优化这几块。很多同学一看到“生命周期”这种题就以为是送分题，其实不然。同一个知识点，面试官能问到三个深度层级：第一层是“Activity有哪些状态”，第二层是“配置文件里声明了哪些属性会影响行为”，第三层是“如果有两个Activity叠加，它们的生命周期回调顺序是怎样的，为什么”。
校招生的项目经验普遍比较浅，面试官没法像面社招一样全程聊项目。这时候基础题就成了最公平的筛选工具，它能在短时间内区分出“背过答案”和“真正理解”的人。我当年见过很多人能把Activity的七个生命周期方法倒背如流，但只要一问“启动一个半透明主题的Activity，旧的Activity会调用onStop吗”，就立刻卡壳。这种问题靠背是背不出来的，必须真正跑过项目、看过日志才行。
1.2 笔试题目里的业务导向信号
挖财是互联网金融公司，做记账和理财，这类产品有账号体系、账单数据、资金信息，所以试卷里明显增加了数据安全、本地存储、异常处理的题目比重。这在当时是很有代表性的信号：金融类App对稳定性和安全性的要求远高于普通工具类应用。
笔试中有一道题大意为“如何保证用户账单数据在本地存储时不被篡改”，还有“弱网环境下提交订单应该如何处理”。这类题不会在《第一行代码》里找到标准答案，但它考察的是一个工程师面对业务场景时能不能想到数据校验、幂等性设计、失败重试机制这些工程手段。哪怕你的答案不够完整，只要思路能落在“校验”“加密”“异常分支处理”这些点上，面试官就能知道你平时写代码是有业务敏感度的。
1.3 校招试卷和社招试卷的差异
校招笔试题一般不会考太深的技术栈（比如热修复框架原理、组件化路由设计都在社招题里更常见），而是以基础为主、场景为辅。原因很简单：校招生还没入职，公司不指望你立刻能干活，而是想看你的学习能力和可塑性。所以答题时不必为了炫技堆一堆生僻概念，老老实实把原理讲清楚，把场景题的思考路径理顺，比什么都重要。
我的一个体会是：笔试写答案时，不要只写结论，要把“为什么”也写出来。比如问你“AsyncTask有哪些缺点”，不能只写“容易内存泄漏、串行执行”，要说明为什么会导致内存泄漏、内部串行执行采用的是哪种线程池模型。这种层次的答案，才说明你是真的在用它，而不是背了八股。
2. 核心题目考点与解题要点
2.1 四大组件是永远绕不开的主干
挖财这份试卷里的Activity、Service、BroadcastReceiver、ContentProvider考题都占了不小篇幅。先说Activity，最常考的三块是生命周期、启动模式、界面跳转与数据传递。
生命周期题最容易被忽视的是“配置变化”场景。旋转屏幕时Activity会重建，这背后是onSaveInstanceState和onRestoreInstanceState的配合。2017年那会儿还没有ViewModel和rememberSaveable这种现成方案，所以只能靠开发者自己妥善保存界面状态。放到现在答这道题，可以结合ViewModel的onCleared机制来讲“配置变化时如何避免状态丢失”，这是加分项。
启动模式里，singleTop、singleTask、singleInstance是高频考点。我特别想提醒的是“singleTask和singleInstance到底有什么区别”：singleTask保证栈内唯一，但仍然和其他Activity在同一个Task中；singleInstance则是单独占一个Task。网上很多答案把两者混为一谈，能准确说出区别就能拉开差距。
Service方面，考得最多的是“startService和bindService的区别”以及“Service和Thread的区别”。前一个区分点在于启动方式、生命周期回调、能否获取Service实例。后一个区分点在于Service运行在主线程、Thread运行在子线程。很多同学会错误理解为“Service就是后台线程”，这个误解在笔试里特别致命。只要你了解Service里的方法默认是在UI线程执行，就不会掉进这个坑。
BroadcastReceiver的考点集中在动态注册和静态注册的差异、广播类型（无序广播/有序广播/本地广播），以及对Android 8.0后隐式广播限制的认知。ContentProvider考察的更多是底层原理，比如它是基于Binder实现的，调用方通过ContentResolver访问数据，底层要经过AMS和Binder跨进程通信。
注意：在回答四大组件相关题目时，适当提到“进程优先级”“ANR机制”“Binder vs AIDL”这些延展概念，会让面试官觉得你对底层有了解，而不是只停留在API使用层面。
2.2 Handler消息机制：必考中的必考
如果只允许选一个知识点来押题，我一定会押Handler。它几乎出现在所有安卓公司校招笔试里，挖财也不例外。为什么？因为Handler机制牵涉到线程通信、消息队列、主线程事件循环、内存泄漏等多个关键考点，一个题就能串起一大片知识网络。
最核心的链路是这样：主线程在启动时通过Looper.prepareMainLooper创建唯一的Looper对象，把它绑定到当前线程，然后进入Looper.loop()的无限循环中不断从MessageQueue里取出消息，交给对应Handler的handleMessage处理。子线程想要更新UI，最简单的做法是拿到主线程的Handler，调用sendMessage把消息放进主线程的MessageQueue，主线程在空闲时取出并执行。
答题时要把几个点讲足：
- 一个线程只能有一个Looper、一个MessageQueue，所以Looper必须配合ThreadLocal来实现线程隔离；
- Handler在创建时会自动绑定当前线程的Looper，所以新手最容易犯的错就是在子线程里直接new Handler，会抛RuntimeException；
- MessageQueue的enqueueMessage和next方法内部会调用nativeWake/nativePollOnce，设计上利用了epoll机制让线程在没有消息时休眠，而不是忙等；
- 由Handler持有外部Activity的引用导致的内存泄漏问题，以及常规解法（在onDestroy时removeCallbacksAndMessages，或者用静态内部类+弱引用）。
想拿高分的话，可以在最后补充一段“从Handler到IdleHandler再到同步屏障”的理解。面试时如果能说出“同步屏障其实就是为了保证UI绘制这样的异步消息能够优先处理”，证明你是读过源码的人。
2.3 AsyncTask、线程池、看得到的异步处理
挖财这套卷子里一定有异步任务相关题目。AsyncTask这颗雷，当年几乎所有公司都在考，现在虽然已经在实际开发中使用率大大降低，但校招笔试依然爱问，因为它的坑“丰富且经典”。
要答好AsyncTask，先要清楚它在不同系统版本下的执行策略：在Android 1.6到3.0之间，AsyncTask是并行执行的；从3.0开始，execute()方法默认串行执行，核心改动是把线程池换成串行Executor；如果你想并行，必须调用executeOnExecutor(THREAD_POOL_EXECUTOR, params)。这个版本演变本身就是一道判断题，能答出API 11这个分水岭是加分项。
接着是典型坑点：
- 内部持有Activity引用导致内存泄漏。AsyncTask是匿名内部类时，会隐式持有外部Activity，如果任务还没跑完Activity就销毁了，这个引用无法被回收；
- 旋转屏幕后Activity重建，旧Activity未被销毁，页面上会出现两个实例；
- doInBackground执行过程中如果抛出未捕获异常，整个线程会挂掉，不会自动回调onCancelled；
- 多个AsyncTask同时更新UI，可能出现界面状态不一致，需要手动做同步控制。
答题时如果能把AsyncTask和Handler机制串起来讲（AsyncTask内部正是基于Handler和线程池封装的），会显得非常有深度。我当时笔试时写了“AsyncTask = 线程池 + Handler，由FutureTask来管理后台任务的运行和结果回调”，面试官后续追问时明显兴趣变浓。
2.4 内存与性能优化题：体现工程经验的试金石
金融类App对内存优化格外敏感，因为记账应用会长期在后台运行，用户每天都可能打开好几次，内存占用过高很容易导致被系统杀掉，进而影响用户体验和口碑。
试卷里几乎必有“如何避免OOM”“图片缓存如何设计”这类题。图片这块是安卓优化的重灾区，尤其在2017年还没有成熟的Glide/Coil一统天下的时候，面试官喜欢追问：Bitmap内存是怎么计算的、图片压缩有哪些策略、三级缓存如何设计。
答题思路可以围绕这么几条线展开：
- Bitmap占用的内存计算公式：宽 × 高 × 每像素字节数，ARGB_8888就是4字节，RGB_565是2字节；
- inSampleSize的采样压缩策略，根据View的实际尺寸来降低加载到内存中的图片分辨率；
- 使用LruCache做内存缓存，计算方式通常是“系统可用内存的1/8”，底层基于LinkedHashMap的accessOrder实现LRU；
- 把图片保存到磁盘缓存（DiskLruCache），内存没有命中时读磁盘；
- 适当情况下使用RGB_565而不影响视觉效果。
还有一个高频点是内存泄漏场景总结。除了Handler导致的泄漏外，还有静态集合引用Activity、单例持有Context、匿名Runnable持有外部引用、未注销的BroadcastReceiver、未关闭的Cursor、未释放的动画监听器等。答题时可以举一个自己实际修过的例子，会比列十个理论泄漏点更有说服力。
2.5 自定义View与事件分发：拉开差距的深水区
这是安卓校招里两极分化最严重的一类题。基础一般的同学看到自定义View就发怵，而基础扎实的同学靠这道题能直接翻盘。挖财试卷里考了这个方向，估计是想筛掉只写业务界面的“调用型选手”。
自定义View的核心知识框架是三个过程：measure（测量）、layout（摆放）、draw（绘制）。答这类题最关键的一点是讲清楚MeasureSpec的三层含义：UNSPECIFIED、EXACTLY、AT_MOST分别对应什么场景，以及父View的MeasureSpec和子View的LayoutParams结合后怎么推出子View的MeasureSpec。这个逻辑只要捋顺了，不管试题里怎么变着花样问，都能答到点上。
事件分发则要背熟三个方法——dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent，再理清它们之间的调用顺序：先从Activity到ViewGroup再到View，逐层down事件分发；如果中间的ViewGroup拦截了down事件，后续的move和up都会直接给该ViewGroup处理。
我建议笔试遇到这类题，干脆画个简单流程图辅助表达：DOWN事件从Activity向下分发，子View没有消费就逐层向上返回到Activity，最后没人处理就丢弃。虽然答案本身是文字，但能清晰描述这条链路，面试官就能确定你不只是在背API。
3. 金融类App场景下的特殊考点
3.1 本地数据安全与加密策略
做题时我看到试卷里有“用户账单数据在本地存储时如何保证安全”一类的问题，第一反应是“这题是懂业务的人出的”。记账App的用户数据虽然不像支付密码那样需要实时校验，但一旦被篡改，可能导致用户的统计报表错误，严重的话还会影响理财行为的真实性。
这类题的答题框架可以拆成四层：
- 加密层面：敏感字段不在本地明文存储，使用AES对称加密或RSA非对称加密，密钥不要硬编码在Java代码里，可以放到NDK层或使用Android Keystore；
- 完整性校验：对关键数据生成HMAC签名，每次读取时校验签名是否一致，防止存储内容被篡改；
- 越狱/root检测：在金融App里属于标配。检测到root后可以选择降级功能或提示风险，但不能直接闪退（这会影响正常用户）；
- 防调试与防抓包：debug状态检测、证书校验、SSL Pinning，防止中间人抓取明文数据。
就算这些点不能全答上来，能说出“用AES加密存储、签名防止篡改、密钥放到Native层”这三板斧，也已经能展示出基本的安全意识了。
3.2 弱网与请求失败处理
金融类App最怕什么？怕用户提交了一笔操作，结果网络超时，用户不知道操作到底成没成功。如果用户重复点击提交，还可能导致重复下单。所以试卷里有“弱网环境下提交订单如何处理”这类场景题，考察的是工程系统设计能力。
答题时应该从三个维度展开：
- 请求层：设置合理的超时时间，区分连接超时、读取超时、SSL握手超时；失败后根据错误码判断是网络问题还是服务端问题，网络问题可以自动重试一两次，服务端错误不要盲目重试；
- 业务层：提交订单要带全局唯一的请求ID（幂等键），服务端根据这个ID判断是否处理过，防止重复扣款或重复记录；本地数据库要记录“待提交”状态，网络恢复后自动补交；
- 体验层：任何操作都要有明确的loading状态和失败后的用户提示按钮，不能直接弹Toast“网络错误”就完事。更好的方案是用本地乐观更新，先更新UI，在后台同步，如果失败再回滚并提示。
这道题在面试中的区分度极高。只会写代码的人会回答“用retrofit的retryWhen”，懂业务的人会回答“幂等性设计和状态机管理”。前者是工具思维，后者是系统思维，面试官一眼就能看出来。
3.3 崩溃率与稳定性治理
记账类App的核心使用场景是“记录每一笔花销”，如果用户刚输入完金额，正在保存时App闪退了，大概率这个用户会直接跑去给应用商店写差评。所以金融类产品的崩溃率KPI往往定得非常严格，面试官在校招笔试里也会通过“如何降低App崩溃率”这种题去考察候选人的质量意识。
这类题可以从“事前预防”和“事后治理”两个角度答。事前预防包括：代码review时关注空指针和数组越界风险；使用StrictMode检查主线程耗时操作和错误磁盘访问；上线前做充足的机型适配和回归测试。事后治理包括：接入Bugly或自建崩溃日志采集，拿到崩溃堆栈后按Top N排序、逐一修复；在崩溃发生无法恢复时，用“闪退保护”机制在下一次启动时清空不安全缓存页面，把用户引导到首页。
如果能在这个答案里加入一个自己处理过的真实Bug案例，比如“上次线上遇到的崩溃是因为某个机型上SharedPreferences的apply没执行导致数据为空”，整个回答会变得非常有画面感。考官会觉得你不是在背模板，而是真的扛过线上故障。
4. 从笔试到面试：答题实战中的经验技巧
4.1 答案的组织结构
我见过很多同学笔试答题，写得很“程序员式”——上来直接贴代码，或者堆概念名词，没有上下文。但笔试题的阅卷人往往是团队的资深工程师或leader，他们读答案时最关心的不是“你会不会这个API”，而是“你的思考过程是什么样”。
一个比较通用的答题结构是“是什么—为什么—怎么解决—有什么坑—有没有更好的方案”。以“Handler内存泄漏”为例：
- 是什么：Handler持有外部Activity的引用导致Activity无法被回收；
- 为什么：消息队列里堆积了未处理的消息，消息持有Handler引用，Handler持有Activity引用，形成引用链；
- 怎么解决：在onDestroy中removeCallbacksAndMessages，或使用静态内部类+WeakReference；
- 有什么坑：单纯removeCallbacks并不能清空消息队列，必须用removeCallbacksAndMessages(null)；
- 更好的方案：从架构层面把耗时任务从界面层剥离，配合Lifecycle组件自动清理回调。
这种结构层层递进，阅卷人扫一眼就能抓住重点。而那些只写“使用弱引用解决”的答案，一眼就能看出是背过的。
4.2 场景题的优先级排序
场景题往往有多个答案，但面试官想看到的不是“标准的唯一解”，而是“你是否具备判断优先级的意识”。比如“首页加载很慢，你如何优化”，有些同学上来就回答“用多线程并发请求”，这其实是个典型误区。
正确的思考顺序应该先测量再优化。先埋点看各项数据——首屏接口响应时间、图片加载耗时、布局渲染时长、主线程是否有卡顿。有一个数据作为依据再谈优化方向：优化布局层级用ConstraintLayout减少嵌套、对RecyclerView使用懒加载、图片预加载、接口数据缓存到本地、首帧不用等待所有接口返回。没有数据进行“盲优化”，在工程上是很危险的。
所以笔试答场景题，一定要带上“先定位瓶颈，再动手优化”这种意识。哪怕你列的优化手段不够全面，这种思路本身就已经赢了。
4.3 手势与绘图表达能力的隐藏加分项
笔试答题完全不涉及画画是不可能的，尤其是考察事件分发和自定义View的时候。把自己的思路用简单的箭头图或流程图表达出来，效果远好于大段文字。
举个例子，在回答“一个点击事件在ViewGroup和View之间是怎么传递的”时，我当年是这么画的：
Activity.dispatchTouchEvent └─> ViewGroup.dispatchTouchEvent ├─ onInterceptTouchEvent? true → ViewGroup.onTouchEvent └─ false → 子View.dispatchTouchEvent └─ 子View.onTouchEvent不需要画得多精致，箭头方向、关键方法、判断条件清晰即可。阅卷人看到这种结构化表达，会立刻明白你对事件分发是有体系化理解的。如果还有富余时间，还可以在下方补一句“如果down事件没有被消费，后续的move和up事件也不会再传递”，这句补充比画图更有含金量。
5. 重做一遍：结合2024年的技术栈复盘老题目
5.1 从Java到Kotlin，答案的底层逻辑没变
现在校招笔试的代码题基本默认用Kotlin答卷了，挖财这份2017年的试卷虽然当时是Java语境，但核心概念的底层逻辑放在今天依然成立。比如Java里用静态内部类+WeakReference解决Handler内存泄漏，放到Kotlin里不过是用object声明或弱引用包装的Kotlin写法替代；RecyclerView的DiffUtil、ListAdapter这些新工具，理解它们的核心思想还是要先懂“Item复用与局部刷新”的老问题。
以Activity重建时的状态保存为例，当年靠onSaveInstanceState手写序列化，现在有了ViewModel + SavedStateHandle，但本质仍然是“配置变更后怎么恢复UI状态”。看懂了这个“不变”，你在面对任何新框架时都能快速找到它在整个体系里的位置。
5.2 老题和新技术的对应关系
很多2017年的“难题”，在2024年已经有了官方推荐的现成方案。比如：
- 权限申请的运行时处理：老试卷考“如何在6.0+动态申请权限”，现在的答案直接是registerForActivityResult + ActivityResultContracts.RequestPermission；
- 数据库升级：以前要手写SQLiteOpenHelper的onUpgrade，现在用Room的Migration机制；
- 后台任务：以前考JobScheduler或Service保活，现在推荐WorkManager；
- 异步处理：以前谈AsyncTask的坑，现在谈协程的Dispatchers和Flow的背压处理。
但这不是说老题目过时了。恰恰相反，面试官会通过“你有没有踩过老方案的坑”来判断你的经验深度。所以基础题的复习标准，不是“知道新方案怎么写”，而是“知道为什么出现新方案来替代旧方案”。
5.3 一套高效的校招复习路线
回到开头的问题：如果你现在准备安卓校招，挖财这套试卷应该怎么刷？
我的建议是三阶段走：
第一阶段（1~2周）：基础扫盲。把Activity生命周期、启动模式、Fragment生命周期、Service、BroadcastReceiver、ContentProvider、Handler、线程池、 RecyclerView缓存机制、自定义View、事件分发全部过一遍。这个阶段的目标是能把每个知识点说清楚“是什么”和“为什么”。
第二阶段（2周）：项目深挖。拿出自己做过的项目，按“技术选型—框架设计—遇到的问题—解决过程”来准备。特别要注意的是，不要只讲功能，要讲难点。哪怕是“一个列表页用了下拉刷新”，也要能讲清楚“怎么避免刷新过程中的数据错乱”。
第三阶段（1周）：刷题与模拟面试。刷真题、模拟30分钟电话面试。对着镜子或者录音设备，用口头表达的方式把一套笔试题完整讲一遍。这个方法很土，但特别有效，因为很多同学写答案时条理清晰，一张嘴就乱了。
我个人在实际操作中最深的一个体会，是“把每一个知识点都当成项目遗产来对待”。不要为了应付面试去背某个答案，而是动手写这个小Demo、拆源码、画时序图，研究清楚一套Handler机制可能花掉一个周末，但之后遇到任何线程通信问题都能第一时间反应过来。
5.4 面试中不要踩的雷
最后再说几个面试时容易踩的雷。第一个是“过度抢答”。面试官问“你熟悉Activity的启动模式吗”，你噼里啪啦把这四种模式全部讲一遍，讲完还洋洋得意。但面试官接下来想问的可能是“你们项目里为什么要用singleTop”。最好的节奏是：简单答出基础定义，然后留个钩子“我们项目里在某某场景下遇到过栈溢出问题，当时通过singleTop解决了”，看面试官是否追问。
第二个雷是“空泛地谈经验”。别说什么“我负责项目里的性能优化”，要具体到“我用Systrace发现了启动阶段存在一个重复Inflate布局的问题，优化后冷启动时间从1.8秒降到1.1秒”。面试官听到这种细节，比听十句自我评价都有用。
第三个雷是“对做过的项目没有反思”。面试官问“你这个项目哪里可以做得更好”，如果你只会说“都挺好”，这说明你没有沉淀和复盘习惯。哪怕说一句“现在回看，如果当时用了协程，代码会更简洁，错误处理也更统一”，都体现出了你的成长性。
从2017年的挖财笔试题一路聊到今天的安卓技术栈，你会发现技术迭代非常快，但面试官对候选人的核心期待始终没有变过：基础扎实、思路清晰、有工程质量意识、有好奇心。这份试卷的意义不只是让你知道当年考了什么，而是帮你建立一套持续迭代自我的方法论——把每一个用过的方案问透，把每一个踩过的坑写进知识体系里。
我个人每年都会把这份老试卷拿出来重新做一遍，看看自己当前的技术理解比去年深在哪儿。这个习惯，我建议你也试试。
