小满这批春招笔试是直接发邮箱的不留防备。我下午两点坐到电脑前看到“Android研发岗第二批笔试”几个字心跳先漏了一拍——两小时50道选择加4道主观题再加一道手写代码。这个组合在如今的Android岗位笔试题里算相当常规但这恰恰是它最坑的地方常规题目人人眼熟考的就是谁理解得更准、答得更实。考完出来我坐在地铁上把整张卷子从头到尾过了一遍发现里面有几类题特别有代表性一是经典概念换了个壳来考二是工程经验直接做成题干三是源码细节要求你答到“面试官心坎”层面。以下是我个人对这份笔试的完整复盘包括出题意图、踩坑点和可复现的解题思路不是官方答案但应该能帮后来的人少走一段弯路。1. 这套卷子的整体观感与作答策略1.1 题型分布与时间分配建议先还原一下卷面结构选择题占大头50道范围覆盖Java/Kotlin基础、Android四大组件、Handler与消息机制、View绘制、线程与进程、网络与图片加载、性能优化、架构模式、Gradle与打包、AGP版本适配、极个别的新技术题比如Compose和协程。主观题是4道简答或设计题最后一道是算法/数据结构手写题。这个结构比例是有讲究的。选择题量多单题分值不高但覆盖广主要作用是快速筛掉基础不扎实的人。4道主观题才是拉开分差的地方题目往往不直接问“是什么”而是问“为什么这么设计”或“在某某场景下你怎么选型”。最后的手写题反而不是最难的部分常见的是LRU、链表反转、字符串处理这类比算法竞赛题简单得多。时间分配上我当时的做法是先花5分钟把整张卷子浏览一遍给主观题和手写题留足40分钟剩下75分钟全部给选择题。这个分配在复盘之后依然成立——选择题看着快但稍不小心就会在“好像对又好像不对”的选项上卡住而且工程经验题一道就能耗掉5分钟。主观题如果放到最后写思想压力大手容易乱不如趁头脑清楚先拿下。1.2 一眼识破考点的“快速判断题”选择题里有一批属于“秒杀题”考点极其明确基本是看到关键词就能定位Activity启动模式结合Intent flag组合考Task栈行为线程间通信选Handler还是runOnUiThread考消息队列理解ContentProvider的调用是否跨进程考Binder基础ANR触发条件考InputDispatchingTimeout和BroadcastReceiver的timeout时长图片压缩的采样率计算考BitmapFactory.InSampleSize逻辑内存泄漏场景里哪个不属于考静态持有没有清理这类题我的答题原则是不能只看记住了什么要看题目在问什么。比如Activity启动模式那道题我印象里给了一个场景——“MainActivity启动SecondActivitySecondActivity设置了singleTask然后点Home键再点图标回到桌面入口”问回到桌面入口时栈里的Activity顺序。很多人一看singleTask就开始背启动模式规则忽略了“从桌面入口恢复”实际上走的是Launcher重新发起Intent的过程需要结合launchMode默认值的兜底行为才能判断。这种题就是那种“看似送分实则送命”的典型。1.3 什么时候该果断放弃卷二里有几道题我确实没把握比如一道关于OpenJDK与Android运行时差异的选择另一个车机场景里I2C设备节点访问的权限问题。这两个我平时接触不多当时给自己的策略是先排除两个明显错误的选项剩下二选一凭工程直觉选同时做标记不回头死磕。后来复盘的时候我觉得这个策略是对的。笔试限时一道题卡5分钟后面的简答题就可能写不完得不偿失。对于冷门领域题它考的是知识面而不只是知识深度会就是会不会就是不会用20秒做个判断远比用3分钟硬猜划算。2. 基础题里的“送分”与“送命”陷阱2.1 Activity启动模式的临界情况启动模式是Android笔试的万年考点但这次卷子没有直接问四种launchMode的定义而是全部换成了场景判断。有一道题把我身边好几个同事都绕进去了一个App的主Activity设置成singleTask另一个App通过隐式Intent去启动它问此时Task栈的变化。很多人想当然认为singleTask启动一定会清理该Task栈顶之上的Activity于是选了“把原栈全部清空再启动”。但这里的临界点是通过隐式Intent从别的App启动时如果不额外设置FLAG_ACTIVITY_NEW_TASK目标Activity会以启动者所在Task为宿主去查找而singleTask本身自带NEW_TASK语义系统会复用它原本所在的任务栈。如果该Task不存在才新建。这个行为差异不写一次原生代码很难踩到。我的心得是遇到启动模式题先画一个Task栈再把“是谁发起、有没有带Flag、目标Activity是否已在栈中、复用后会不会回调onNewIntent”四个问题按顺序过一遍基本不会错。这比凭记忆硬答准确很多。2.2 进程优先级与内存回收的真实排序有一道选择题问的是“以下哪种进程被回收的优先级最高”选项包括前台进程、可见进程、服务进程、缓存进程。这个知识点属于经典老题面试背过的都能答出顺序但卷子里换了考法它给出了一个实际App的状态组合——界面处于后台、有一个前台服务在跑、同时屏幕上有通知问整个App进程属于哪一类。这个就有点阴险了。前台服务运行中进程会被提升为前台进程而不是服务进程。很多人一看到“服务”两个字就直接选了服务进程忽略了前台服务对进程优先级的提升作用。这种题考察的不是你会不会背Android的进程优先级表而是你能不能把运行时状态映射到那张表上。平时做性能优化的时候对进程优先级其实是有体感的定位类App在后台持续上报位置时系统内存吃紧最先被杀掉的往往是不带任何前台属性的App。理解这个映射关系不仅是为笔试更是排查线上偶发被系统回收问题时的一条重要线索。2.3 自定义View与MeasureSpec的边界条件View的自定义是选择填空题的高发区。这次考了一个不算偏但容易答错的知识点父容器是FrameLayout子View宽高设置为match_parent此时子View的MeasureSpec是什么。这个题考的是MeasureSpec的生成规则。FrameLayout在measureChildWithMargins时会根据子View的LayoutParams和父容器的MeasureSpec计算出childMeasureSpec再传给子View的onMeasure。match_parent在父容器是EXACTLY模式下最终得到的是EXACTLY parentSize。看起来简单但有一道干扰项描述成了“子View自己会先测量内容再决定大小”这个是对wrap_content行为理解不深的人才会选的选项。自定义View的题本质上考的是你对测量流程有没有真正上手改过。我的建议是准备笔试前至少手写一次自定义View把onMeasure的三种模式逻辑处理一遍比如wrap_content时给一个默认尺寸、match_parent时取parentSize、使用MeasureSpec.getSize和getMode时注意边界值。写过一遍和背过十遍做选择题的感觉完全不同。2.4 线程池与协程的“等价比对”陷阱今年这批选择题有一道很新的题关于线程池和Kotlin协程的说法哪个是正确的。选项里有两个极具迷惑性协程比线程更轻量所以协程一定不会阻塞主线程线程池解决的是线程频繁创建销毁的开销问题协程解决的是回调嵌套问题第二项看起来很有道理其实是把两个层级的优势混在一起谈了。协程确实可以简化异步代码结构但它并不会替代线程池解决线程复用问题。Dispatchers.IO底层依赖的是线程池Dispatchers.Main底层依赖的是主线程Handler。第一项就更离谱协程里如果调用一个阻塞方法比如Thread.sleep同样会卡住所在线程只是它卡住的是工作线程还是主线程取决于你用什么Dispatcher。这种题考的是概念辨析能力。我的经验是凡是看到“一定”“完全”“绝对”这类词先打个问号再回到原理层面验证。面试官出这种干扰项的目的就是看你有没有真正理解这些技术的边界。3. 源码级问题把答案写到面试官心坎上3.1 Handler机制从“听说”到“讲清楚”主观题里有一道几乎是必考题“请简述Handler、Looper、MessageQueue的工作原理以及为什么主线程的Looper不需要手动调用loop方法。”这类题考的是源码级理解。我答题时没有直接贴源码而是按“生产者-消费者”模型来组织Handler是生产者sendMessage将Message入队MessageQueue是缓冲区按时间戳排序的单向链表结构Looper是消费者不断死循环从队列取消息并分发处理主线程的入口函数main里ActivityThread会调用Looper.prepareMainLooper和Looper.loop所以不需要手动调用我还补充了一个很多答案会漏的点Looper.loop是个死循环为什么不会导致主线程卡死。这里的关键是当MessageQueue为空时主线程会进入epoll机制挂起等待而不是忙等。这是Android经典问题“为什么主线程的Looper不会卡死应用”的标准回答路径。把这个点写出来和那种只背了参数的答案高下立判。3.2 Activity启动流程和AMS的全链路另一道主观题我印象很深完整描述从点击桌面图标到Activity显示出来的过程要画出涉及的进程和关键类。这个题乍一看像八股文但其实非常考验你是否真正理解Android的系统架构。我的回答按调用链拆Launcher进程捕获点击事件通过Binder调用AMS.startActivityAMS校验Intent、权限并通知Launcher进入Paused状态AMS通过Socket通知Zygote进程fork出App进程App进程入口是ActivityThread.main然后通过Binder向AMS报告attachAMS调用 scheduleLaunchActivity通过Binder回到App进程ActivityThread通过Handler切换到主线程创建Activity实例依次调用onCreate、onStart、onResumeViewRootImpl与WindowManagerService完成窗口布局DecorView被添加到WMS并触发首次measure/layout/draw我在结尾处特意强调了一个容易忽视的细节新进程的创建是Zygote通过Socket通知的App进程和AMS之间的交互全部走Binder但Zygote fork用了另一个通道两个体系不能混为一谈。这个细节能体现你不是背了一条流程而是真的读过多篇源码分析。3.3 Binder内核对一次进程间调用的完整处理还有一道主观题问Binder的优势和一次完整调用过程。Binder在Android面试里的地位不用多说几乎每一场系统侧面试都会涉及。答题思路我是按这四个层面铺开的为什么是Binder而不是传统的System V共享内存安全和性能折中。Binder为每个进程分配UID/PID内核态可以校验调用方身份这是Android安全模型的基石一次完整调用代理对象持有一个句柄Client调用transact方法数据被序列化后打包成binder_transaction_data通过内核驱动的binder_ioctl写入内核Binder驱动做的事拷贝一次数据到目标进程的内核缓冲区然后通知目标进程的Binder线程池去处理Server处理完毕后将回复数据沿同一路径返回整个过程内存拷贝次数少于传统IPC我特别写了“内存拷贝一次”这个点。网上很多文章说Binder“只需要一次拷贝”时指的是用户空间到内核空间的拷贝但你要能说清楚目标进程需要从自己的内核缓冲区再拷贝到用户空间严格来说是“一次半”或“一次内核态拷贝加一次目标进程读取”。这个细节一写出来面试官就知道你是真绕过内核代码的哪怕看得不多。4. 工程化与新技术题AGP、R8、协程这些平时容易忽略的点4.1 AGP版本与构建配置的连环坑2023年这批题开始明显偏向工程化有一道选择题直接拿AGP版本做文章项目使用的Android Gradle Plugin是8.0但Gradle版本还是7.4问构建会出现什么问题。这道题对于只会打开Android Studio点Run的人几乎是必错项。AGP 8.x要求最低Gradle 8.0且要求Java 17如果项目还在用Java 11即使Gradle升上去了也会直接报错。加上AGP 8.0默认不再支持某些旧API比如buildConfig生成方式默认关闭需要自己配置buildFeatures { buildConfig true }。这些坑我在实际升级项目的时候都踩过所以看到这题的时候直接能判断出“版本不匹配”这个正确答案。当时我在答案旁边标注了一行话“AGP与Gradle的版本对应关系一定要以官方兼容性表格为准不要凭感觉升级。AGP 8.1要求Gradle 8.0以上AGP 8.2要求Gradle 8.2以上AGP 8.3要求Gradle 8.4以上。升AGP不顺带升Gradle报错信息会挂羊头卖狗肉指向一个无关的DSL配置项半天定位不到。”4.2 R8/混淆在实际项目里的作用边界有一道选择题考R8和ProGuard的区别。这个知识点平时在release打包时会接触到但不少人的理解停留在“R8是新版混淆工具”这个层面。实际上R8是AGP 3.4之后默认开启的压缩器它同时做了四件事代码裁剪shrinking、资源裁剪、混淆obfuscation、优化optimization。ProGuard主要做的是裁剪和混淆优化能力弱很多而且R8的优化包括方法内联、常量传播、无效代码消除这些ProGuard基本不做。题目的坑在于给了一个选项“R8和ProGuard都能做资源裁剪”这个是错的资源裁剪是Android资源打包工具配合R8完成的ProGuard只处理字节码。如果你想在项目里把R8用透建议先在debug包上开启试跑收集完整的使用映射文件usage.txt和混淆映射mapping.txt。很多线上崩溃堆栈无法还原不是R8的问题是你没有配置mapping文件的上传和保留策略。4.3 MVVM模式下数据层设计题的共性答案4道主观题里有一道是在MVVM架构下设计一个网络请求模块ViewModel、Repository、Data层如何划分如何处理生命周期和异常。这道题表面是架构题实际上考的是数据流设计的成熟度。我给的回答分了三层ViewModel层持有UI状态StateFlow或LiveData暴露不可变状态给View不持有任何Context和View引用。生命周期问题交给ViewModel的viewModelScope处理在onCleared时自动取消协程。Repository层是数据的唯一来源Single Source of Truth负责判断数据是走网络还是走本地缓存同时做数据转换和错误归一化。ViewModel不直接碰ApiService是为了后续加入缓存、埋点、拦截器时不用改UI层。Data层Retrofit接口定义、数据库DAO、本地文件存储纯数据实现不包含业务逻辑。层与层之间用接口依赖而非具体实现方便测试时mock。我还额外写了异常处理的顺序先检查网络异常再检查服务端返回的业务码最后才处理解析异常。这道题想拿高分不只是把MVVM的类名写出来而是要把每层职责边界和调用方向交代清楚。5. 编程题与方案设计题临场发挥的思路还原5.1 手写LRU缓存的两种路径最后一道手写题是经典的LRU Cache要求实现get和put方法时间复杂度都为O(1)。这个题在力扣上是146题很多准备过的人都见过。但笔试现场有个坑它不要求你写完整可运行的工程代码而是要求在纸上把核心逻辑写清楚。我的实现选了HashMap 双向链表的方案这也是最标准的做法节点定义包含key和value以及prev和next指针。HashMap存的是key到节点的引用。get时从map里拿节点命中后把节点移到链表头部。put时先判断key是否已存在存在就更新value并移到头部不存在则插入头部同时检查容量是否超出超出则删除尾部节点并移除对应map键。我给出的代码只写了核心函数没有在笔试里贴全量字段定义。如果平时没写过这个结构建议至少手写两遍特别是“删除节点”和“把节点移到头部”这两个操作要能拆成独立函数。有些版本实现用LinkedHashMap一行搞定笔试时可以提一句“生产环境我会基于LinkedHashMap实现但为了展示底层理解这里给出双向链表版本”这反而会加分。5.2 “模拟公交到站提醒”这类设计题的答题框架有一道方案设计题很有趣设计一个公交到站提醒功能用户选择公交线路和站点到站前通知用户。需要给出整体架构设计。这是一道典型的开放题考察的不是你有没有做过公交App而是你有没有把技术方案拆解成模块的能力。我的答法分五块数据来源公交车GPS位置数据由车载终端上报通过消息队列接入后端后端维护每辆车的实时位置和预估值后端模块线路解析、车辆轨迹匹配、到站时间预估ETA、用户订阅关系管理推送链路后端算出用户关注的站点距离和预计到站时间在预期时间窗口内通过推送服务下发消息客户端侧接收推送后拉起本地通知根据用户是否在前台决定是弹Toast还是走系统通知栏边界情况车辆离线、GPS漂移、用户换乘、多家数据源时间不一致我还特意写了容错“如果车辆定位超过2分钟没有更新后端应该主动剔除该车辆并降级为时刻表预测而不是给用户推送一个不准确的到站时间。这种边界情况在面试里说出来比堆一堆技术名词更让面试官印象深刻。”5.3 什么时候写伪代码是加分项系统设计题里如果直接写大段Java代码反而会浪费时间。笔试阅卷看的是思路清晰度不是代码量。我的做法是先画模块关系然后每个模块用3到5行伪代码表达关键逻辑比如订阅关系的Redis存储结构可以用一个哈希表描述终端上报数据流的处理可以用管道符号串联。比如公交到站提醒的核心订阅关系我写的是Redis Hash: route:station:subscribers key: line_102:st_people_square value: Set这样的表达在阅卷人眼里比一大段完整代码更快理解。而且伪代码允许你在不确定APM细节时规避错误比如你不确定通知栏点击跳转怎么拿Intent就不用纠结具体API把意图写到“onNotificationClick跳转详情页”就足够了。考试不是工程评审抓到核心设计才是首要目标。6. 考完复盘第二批笔试的查漏补缺与备考建议6.1 我在这次笔试里暴露的短板考完之后发现自己有三块明显短板。第一是AGP与构建配置的版本兼容细节掌握得不够细。卷子里的AGP版本题我虽然能做对但回头看是因为最近刚踩过坑如果早几个月考我大概率会选错。这类知识的特征是不常用、需要时却救急、报错信息不直观所以特别容易被忽略。建议面试前一两个月把项目的Gradle和AGP升到最新稳定版完整跑一遍构建所有报错处理一遍这些经验比背十篇博客都有效。第二是新技术相关概念有“听说过但说不透”的问题。比如Compose的状态管理和重组机制我了解基本用法但没法从原理层面讲清楚重组范围的判断逻辑。卷子里有一道题确实考到了Compose的remember和rememberSaveable区别我答得不够深入。这说明如果目标岗位明确要求用Compose千万不能只懂写布局要能说清snapshot state和重组流程。第三是代码手写题虽然能做出来但细节处理不够优雅。LRU那道题我写完后自己检查发现删除尾节点时没有在HashMap里同步移除对应键。这种低级失误在思维紧张时很容易出现。我的经验是手写题写完以后至少要拿一组边界数据自行验算一遍比如空缓存、容量为1、get一个不存在的key这三种情况。6.2 给准备Android岗位笔试的3个建议结合这次笔试我总结出三条最实在的建议。第一条按“选择题快答、主观题结构化、手写题保基础”的节奏训练。选择题要练到看完题干就能定位考点的程度主观题要养成用“总-分-总”结构答题的习惯手写题每天保持两道简单的数据结构题目保持手感。第二条把“为什么”作为复习主线。别只背“Handler是做什么的”要问“Android为什么不用普通的Java线程池来做主线程消息处理”。别只背“Binder效率高”要问“内核为什么要专门设计一个Binder驱动而不是复用已有的IPC机制”。实践里面试官和阅卷人最欣赏的永远是那些能讲出设计动机的候选人。第三条考前一定自己搭建一个真实的Android工程把AGP/Gradle版本、依赖、MVVM分层、混淆配置、协程请求网络全部跑通一遍。笔试里大量工程题比如R8的作用、AGP版本报错来源就是真实的日常开发。自己构建过和没构建过做这些题时的手感完全不同。6.3 后续的复习方向这次“小满春招第二批笔试”之后我给自己定的计划是先补Compose原理重点是状态管理和重组机制再把Handler和Binder的源码重新读一遍这次要自己画调用链图而不是看别人的总结然后是刷AGP升级相关的踩坑记录整理成自己的笔记最后每天做一道LeetCode中等题保持算法手感。另外我打算把Android的动态图标、蓝牙、OTA、AMS这几个热搜里出现的高频词按照“基础概念-系统机制-实际项目经验”三层结构梳理成文档。这些都是当前行业里出现频率很高的技术点面试被问到的概率相当大。笔试只是第一道门槛后面大概率还有技术面和HR面。与其焦虑结果不如把每次笔试当成一次技术体检考完之后立刻把不会的题变成笔记这才是这批笔试真正值回票价的地方。