20分钟前我刚从考场出来趁着记忆还热乎赶紧把今天这场2023年度小满春招Android研发岗第二批笔试的完整复盘写下来。先说结论整套卷子不算偏但非常考察“基本功是否扎实”尤其是对Android系统机制的理解深度光背面试题没用得真正写过代码、排查过线上问题的人才能答得顺手。这应该是今年春招Android岗里质量比较高的一套笔试题了。我参加的是第二批笔试整体时长120分钟题量不大但每一道题都值得展开说。题型分四块不定项选择题、手写代码题、系统机制分析题、开放性设计题。分值分布大概是选择30分、代码40分、系统分析20分、设计10分。从这分值就能看出来这场笔试的核心导向是——代码能力是底线系统理解是分水岭。这篇复盘我会按题型逐一拆解每道题不光给答案还会把我当时为什么会这么想、有哪些容易踩的坑、以及考完查资料验证后的结论都写出来。如果你的目标也是大厂Android岗这份内容能帮你少走很多弯路。1. 整体试卷结构与考察逻辑拆解1.1 为什么是这样一份卷子春招笔试和秋招不太一样。秋招更像海选题量大、覆盖面广用来快速筛人春招一般是补录名额少所以题目会更精准专门考察“你来了能不能直接干活”。小满这场第二批笔试就很有代表性没有一道题是纯粹背概念的所有题都长在真实开发场景里。从出题逻辑来看这套卷子先通过选择题把基础不牢的人筛掉再用代码题确认工程能力然后靠系统机制题区分深度最后用一道设计题考察架构思维。这个逻辑和很多一线互联网公司的面试流程是一致的——先是简历筛选再是笔试筛基础然后面试看潜力。有个细节值得注意不定项选择里好几道题都是“下列说法正确的是”这种题型比单选难很多因为选项里常常有两三个都是对的只是表述的严谨程度不同。我旁边好几个考生就栽在这上面看到某个选项觉得眼熟就直接选了没注意到它少了一个限定条件。1.2 选择题高频考点分布我把整张卷子的选择题考点整理了一下大致分布如下考点方向题数考察深度Java/Kotlin基础4道中等偏底层实现四大组件与启动模式3道中等偏边界场景Handler与消息循环2道较深涉及同步屏障Binder与IPC机制2道深涉及底层原理内存管理与优化3道中等偏实战排查多线程与并发2道较深涉及锁机制新特性与Jetpack2道中等偏版本差异编译构建与混淆2道中等偏流程理解这个分布其实透露了一个重要信息纯API调用和控件使用几乎没考考的全是“你在用的时候知不知道它背后发生了什么”。比如有一道题问SharedPreferences的apply()和commit()的区别表面上是问两个方法的差异实际是在考察你对进程存活时间、ANR触发机制、以及SP实现原理的理解。所以准备笔试的时候我强烈建议不要只看面试题大全那玩意儿只能帮你过选择题的前几道送分题。真正的分水岭在系统机制题和手写代码题这两块必须靠平时积累。1.3 第一批和第二批的差异推测我没参加第一批但考完和群里的同学对了下信息发现两批试卷在风格上高度一致只是具体题目不同。第一批考了RecyclerView的缓存复用机制第二批考了自定义View的绘制流程第一批的算法题是TopK问题第二批改成了合并区间。这说明出题人手里有一整套题库每次笔试随机抽题但考察维度是固定的。这个信息有什么价值呢如果你还在等第三批那复习重点应该放在Android系统机制里的三大核心——Binder机制、Handler机制、View绘制流程算法题重点准备数组操作、链表、二叉树这三种高频题型。往年真题可以参考牛客网上的Android专区但更重要的是把每道题的原理彻底搞懂因为换一层皮就又是一道新题。2. 不定项选择题逐题复盘2.1 Java/Kotlin基础题看似送分实则陷阱多选择题第一道就给我来了个下马威。题目大概是关于Kotlin的协程下列说法正确的是。选项里有几个表述我印象很深协程比线程更轻量协程必须运行在线程上withContext可以切换线程GlobalScope是推荐使用的协程作用域。这道题单看每个选项前三个都是对的但第四个就有问题了。GlobalScope虽然确实存在但官方文档里明确标注它是非结构化并发生命周期跟整个应用绑定容易造成内存泄漏因此不推荐在业务代码里使用。如果对协程只是停留在“会用launch和async”的层面这道题很容易选错。还有一道题考Java的字符串比较问下面哪个表达式返回true。这种题在面试里已经算老掉牙了但笔试里依然会出现而且大多数人都栽在细节上——new String(a) a返回false因为一个是堆对象一个是常量池引用但a new String(a).intern()又返回true因为intern()会去常量池里找。这种题考察的就是JVM内存模型的基本功看书的时候觉得简单考试的时候却容易脑子一热选错。2.2 四大组件相关启动模式的边界情况Activity启动模式这道题考的是singleTask和singleTop的区别。普通场景大家都知道但题目设置了一个场景当前栈顶是Activity A此时又通过Intent启动Activity A如果A的启动模式是singleTop会不会创建新实例答案是复用栈顶实例并回调onNewIntent()不会创建新实例。但如果不限定是栈顶那就得看singleTask的栈内复用了。这题的坑在于很多人记住了“singleTask是栈内复用”就以为万事大吉却没注意到它还有个附带效果——它会清空它之上的所有Activity。笔试题目把这个也作为选项设计了而且这个描述单独看是“正确”的但放在“以下说法错误的是”这个题干下就变成了正确答案。还有一道Service相关的题也值得一说。问的是startService和bindService同时调用时Service的生命周期是怎样的。大多数人只知道startService会启动服务、bindService会绑定服务但题目问的是两者都调用时onCreate、onStartCommand、onBind、onUnbind、onDestroy的调用顺序。结论是第一次startService时先走onCreate再走onStartCommand第一次bindService时走onCreate再走onBind如果前面已经onCreate过了就不会重复调用。最后分开解绑和停止时关键是看Service实例的引用计数归零——当start和bind都调用了需要stopService和unbindService都执行完onDestroy才会被调用。这个知识点在开发中挺常见的比如音乐播放器既被start又需要让Activity绑定拿Binder很多人就是因为没搞懂才写出内存泄漏。2.3 BroadcastReceiver与Android 8.0限制今年笔试的热点题目之一就是Android 8.0之后对静态广播接收器的限制。题目问的是在Android 8.0及以上版本隐式广播的静态注册现在怎么样了答案是系统限制了静态注册接收隐式广播但显式广播和一些特定系统广播比如BOOT_COMPLETED不受影响。这个知识点如果只是背八股很容易把“所有静态注册都失效”这种错误表述当成对的。但实际开发中你会遇到Manifest注册的Receiver收不到通知的现象多数情况就是版本限制导致的。我在实际项目里也踩过这个坑。当时是做一个开机自启动的功能在Android 9的设备上完全收不到BOOT_COMPLETED广播排查了半天最后发现是国内厂商ROM的电池优化策略给杀了。这个问题的排查思路也值得分享一下先确认广播是显式还是隐式再看是否属于系统白名单广播最后检查应用是否被厂商后台限制。笔试题目里虽然没考得这么深但如果你在答题时能提到这些边界情况阅卷人的印象会好很多。2.4 Handler机制同步屏障与消息优先级Handler机制这道题我看完心里是有点惊喜的因为考到了同步屏障。题目大概是关于Handler的消息处理机制以下说法正确的是。其中一个选项是“MessageQueue可以通过postSyncBarrier插入同步屏障此时异步消息会优先执行”。这个知识点偏底层但这两年特别爱考。原因也很简单——Choreographer处理帧绘制时就用到了同步屏障机制如果你只停留在“Handler是用来切换线程的”这个层面遇到掉帧问题根本无从下手。这里我建议准备笔试的同学花点时间把Handler、MessageQueue、Looper三件套的源码静下心看一遍尤其是MessageQueue的next()方法里屏障相关的逻辑搞清楚之后很多选择题基本就是送分。我当时在这道题上多留了个心眼把“同步屏障需要手动移除”这个选项也一起选了。因为确实是这样postSyncBarrier之后必须调用removeSyncBarrier否则消息队列会一直卡在同步屏障这里那些“同步消息”就永远得不到执行。这在实际开发里就是那种“偶现卡死过会儿自己好”的诡异bug面试官要是追问起来答不上来就很尴尬。2.5 Binder与IPC不止于AIDLBinder机制在选择题里考了两道。一道是问Binder相对于其他IPC方式的优势另一道是问mmap在Binder中的作用。这两个问题我在准备阶段刚好都复习到了所以答得比较顺畅。先说优势Binder只需要一次数据拷贝而传统的管道、消息队列和Socket都需要两次拷贝。原因是Binder在驱动层利用mmap把内核缓冲区和用户空间做了内存映射数据从发送方用户空间拷贝到内核缓冲区后接收方通过映射直接就能访问不需要再往接收方用户空间拷贝一次。这个设计让Binder在性能上碾压了传统IPC方式同时又因为每个进程都有UID内核层可以直接校验调用方身份安全性也更好。mmap那题更细一点问的是Binder中mmap的作用是什么。选项有分配内核缓冲区、建立数据映射、拷贝数据、管理引用计数。前两个是核心数据拷贝和引用计数都不是mmap直接做的事。我见过不少同学AIDL用得很溜但问到底层就答不上来可笔试偏偏就是要考这一层。2.6 内存管理与Splash冷启动内存管理方向出了三道题其中一道考的是Activity泄漏的检测方式和常见原因还有一道考了冷启动的定义和耗时统计。Activity泄漏这题比较常规常见原因就是静态变量持有了Activity引用、Handler未移除回调、内部类隐式持有外部类引用等。比较新奇的是冷启动那道题它问的是冷启动的时间从哪个节点开始算。正确答案是从进程创建开始到Activity的onResume执行完结束。但这里有个细节很多资料都没讲清楚从onCreate到onResume只是开发者能感知的部分进程创建和ActivityThread.main()的启动时间也占了大头。优化冷启动性能时不能只盯着自己的启动代码Application的初始化、ContentProvider的启动耗时都影响巨大。我在项目中优化启动速度的实操经验是先用adb shell am start -W命令拿到Displayed时间和TotalTime再结合systrace或者Perfetto看主线程到底在等什么。很多性能优化的文章一上来就讲怎么用工具但笔试只考结论——冷启动时间过长的常见原因包括主线程做耗时操作、ContentProvider初始化慢、首帧布局过于复杂。这几个结论在选择题里对应了好几个选项纯靠猜很难全对。2.7 选择题核心考点速查表复盘完整张选择题部分我把重要考点做成了一张速查表方便后面批次的考生快速定位复习方向考点核心结论易错点Kotlin协程GlobalScope不推荐使用只看launch/async用法不看生命周期字符串比较比较引用equals比较内容intern()入池混淆池中对象和堆对象singleTop栈顶复用回调onNewIntent忽略“栈顶”前提Service生命周期onCreate只执行一次startbind要同时解绑才销毁以为start和bind是两条独立生命周期Android 8.0广播隐式广播静态注册受限以为所有静态注册都失效Handler同步屏障屏障期间异步消息优先需手动移除不知道postSyncBarrier的副作用Binder mmap内核态与用户态映射一次拷贝把数据拷贝也归功于mmap冷启动耗时进程创建到onResume完成只统计Activity内部的onCreate如果你现在正准备第三批笔试这张表值得重点背。表里每一行都是选择题高频出题方向我复盘了下周围参加第一批、第二批的人大家反馈的考点基本没跳出这个范围。3. 手写代码题四道题四种风格3.1 算法题一合并区间这道题是LeetCode 56题的原题给定一个区间的集合合并所有重叠的区间。题目本身不难但笔试要求写出完整可运行的代码而且要考虑边界条件。我的第一反应是按区间左端点排序然后依次遍历合并。思路很简单排完序后如果当前区间的左端点大于上一个合并后区间的右端点说明不重叠直接加入结果否则更新右端点为两者最大值。时间复杂度是O(n log n)主要花在排序上。当时我额外注意了两个边界一个是空数组的判断另一个是int值溢出。区间合并时右端点用Math.max处理但如果区间值可能是Integer.MAX_VALUE排序和比较时就要小心。我写的核心代码如下public int[][] merge(int[][] intervals) { if (intervals null || intervals.length 1) { return intervals; } Arrays.sort(intervals, (a, b) - a[0] - b[0]); Listint[] merged new ArrayList(); int[] current intervals[0]; for (int i 1; i intervals.length; i) { if (intervalis[1] current[0]) { current[1] Math.max(current[1], intervals[i][1]); } else { merged.add(current); current intervals[i]; } } merged.add(current); return merged.toArray(new int[merged.size()][]); }这题的坑不在算法本身而在代码规范。我记得题目要求里特别写了“请使用Kotlin或Java实现并注意代码风格”这就意味着哪怕是笔试也要写出工程化的代码——变量命名要清晰、空值要判断、循环要避免越界。3.2 算法题二实现一个线程安全的LRU缓存这道题是整张卷子里我觉得最有区分度的一道。它要求实现一个LRU缓存支持get和put操作并且要求线程安全。题目没指定语言我选了Kotlin因为Kotlin在表达链表操作时更简洁。LRU的经典实现是HashMap加双向链表。HashMap负责O(1)查找双向链表负责维护访问顺序。每次get时把节点移到链表头部每次put时如果容量满了就淘汰尾部节点。用Java的话可以直接继承LinkedHashMap然后重写removeEldestEntry但笔试如果只写这个会显得你只会调库所以我选择了自己实现。线程安全方面可以直接在get和put方法上加synchronized也可以用ReentrantReadWriteLock做读写分离。我当时用的是ReentrantReadWriteLock因为get操作是读多写少读写锁性能更好public class LRUCacheK, V { private final int capacity; private final LinkedHashMapK, V map; private final ReadWriteLock lock new ReentrantReadWriteLock(); public LRUCache(int capacity) { this.capacity capacity; this.map new LinkedHashMapK, V(capacity, 0.75f, true) { Override protected boolean removeEldestEntry(Map.EntryK, V eldest) { return size() capacity; } }; } public V get(K key) { lock.readLock().lock(); try { return map.getOrDefault(key, null); } finally { lock.readLock().unlock(); } } public void put(K key, V value) { lock.writeLock().lock(); try { map.put(key, value); } finally { lock.writeLock().unlock(); } } }这里有个细节笔试容易忽略LinkedHashMap的accessOrder参数。构造器第三个参数传true时每次get都会把对应节点移到链表尾部从而实现LRU顺序。如果不传这个参数那就是插入序完全达不到LRU效果。如果实在不放心自己手写用LinkedHashMap这一版不但简洁而且不容易写出链表断裂的bug笔试现场能减少废代码量。3.3 代码题三自定义View实现圆角ImageView这道题出现在笔试里我还挺意外的因为一般自定义View更多在面试里以口头问的形式出现。但小满这批笔试直接要求手写代码题目是实现一个圆角ImageView要求支持任意圆角半径并且能处理图片缩放。核心思路是把Bitmap裁剪成圆角用Paint的Xfermode或者直接使用Outline。当时我选择的是先用BitmapShader加载图片然后通过drawRoundRect绘制。这样代码简洁而且性能比用Bitmap.createBitmap重新裁剪要好很多因为避免了二次拷贝像素。关键代码大致是这个结构public class RoundImageView extends AppCompatImageView { private float radius; private Paint paint; private BitmapShader shader; private RectF rectF; public RoundImageView(Context context, AttributeSet attrs) { super(context, attrs); init(); } private void init() { paint new Paint(Paint.ANTI_ALIAS_FLAG); paint.setFilterBitmap(true); rectF new RectF(); } Override protected void onDraw(Canvas canvas) { if (getDrawable() null) { return; } Bitmap bitmap drawableToBitmap(getDrawable()); if (bitmap ! null) { shader new BitmapShader(bitmap, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP); paint.setShader(shader); rectF.set(0, 0, getWidth(), getHeight()); canvas.drawRoundRect(rectF, radius, radius, paint); } } }这道题考察的知识点很综合图片的采样、Canvas绘制、Shader的TileMode、onDraw方法的调用时机。我现场写完后还专门检查了有没有处理scaleType的差异——setImageURI和setImageBitmap都会走不同的内部路径如果没处理好图片显示会被拉伸变形。我当时的处理方式是覆写setImageBitmap和setImageResource方法统一invalidate触发重绘并在drawableToBitmap里按控件宽高做CenterCrop逻辑这样圆角效果就不会被原始的fitCenter缩放破坏。3.4 算法题四TopK高频元素这道题是从一个非空整数数组里找出出现频率最高的K个元素。我选了小顶堆的实现先用HashMap统计频率再维护一个大小为K的小顶堆堆顶是当前K个元素中频率最小的新元素频率比堆顶大就替换并调整堆。public int[] topKFrequent(int[] nums, int k) { MapInteger, Integer freqMap new HashMap(); for (int num : nums) { freqMap.put(num, freqMap.getOrDefault(num, 0) 1); } PriorityQueueInteger minHeap new PriorityQueue( (a, b) - freqMap.get(a) - freqMap.get(b) ); for (Integer num : freqMap.keySet()) { minHeap.offer(num); if (minHeap.size() k) { minHeap.poll(); } } int[] result new int[k]; for (int i 0; i k; i) { result[i] minHeap.poll(); } return result; }这种解法时间复杂度是O(n log k)空间复杂度是O(n)。现场能写出来不算难但有些同学会直接想到用sort那样就是O(n log n)了在数据特别大时会有性能问题。笔试一般不会要求你现场跑大数据量但如果你在复杂度分析里写错还是会扣分的。代码题总结下来就一句话平时多练LeetCode的Top100尤其是数组、链表、二叉树三块同时要把每道题的复杂度和边界条件讲清楚。笔试考的不只是会不会写更是你有没有编程的基本素养。4. 系统机制分析题直击Android内核与框架4.1 Binder驱动的mmap机制系统机制分析题的第一道直接给了一段Binder发送数据的底层描述要你说明Binder在数据拷贝和线程等待方面的设计。这题我答得比较细。Binder通信中当进程A调用进程B提供的服务时数据流向是这样的进程A的用户空间数据通过copy_from_user拷贝到Binder驱动程序的内核缓冲区这个过程发生一次拷贝然后因为进程B在binder_mmap时已经将自己的用户空间地址映射到了这个内核缓冲区所以进程B可以直接读取不需要第二次拷贝。线程等待方面Binder的调用是同步的进程A的调用线程会通过binder_thread_read进入wait_event_freezable直到进程B完成处理后唤醒。理解了这个机制你才能解释为什么主线程调用Binder接口可能导致ANR——如果B服务端处理过慢A的主线程会一直阻塞在Binder调用上超过5秒就触发ANR。这道题我在答题时特意画了一个简化的流程A进程用户空间 - Binder驱动内核缓冲区一次拷贝 - B进程用户空间mmap映射。然后在旁边写了Thread A等待和唤醒的时机。虽然笔试是文字回答但能把流程理到这个颗粒度说明你是真的理解过而不是背的八股。4.2 AMS与Activity启动流程第二道系统机制题问的是从startActivity到首帧显示整个过程中涉及哪些关键系统服务说出至少四个并分别说明作用。我按流程答先说了Instrumentation种的execStartActivity发起请求然后是AMS接收Intent完成进程检查、Activity栈管理、生命周期调度如果目标进程不存在就要通过Zygote fork出新的应用进程新进程初始化时通过ActivityThread的main方法启动主线程创建Application然后通过H类Handler把消息切回主线程创建Activity最后是ViewRootImpl的performTraversals方法触发测量、布局、绘制三步曲完成首帧显示。这题考察的是对整个启动链路的理解如果能补充一些细节会更好比如ActivityRecord和TaskRecord的关系、Zygote的Socket通信机制、以及冷启动时Application和ContentProvider的初始化顺序。阅卷人看到你能把链路串起来就不会只给个基础分。4.3 ANR的成因分析与排查思路ANR这道题比较务实。题目给了三段日志要你说出可能产生ANR的原因并给出至少两种排查方法。我在分析日志时发现一个特征主线程在等待一个Binder调用返回已经超过了5秒而且CPU占用率很低。这个现象基本可以推断为应用在等待某个系统服务或者跨进程操作该操作迟迟没有返回而主线程被锁死了。正常ANR有三种类型——输入事件超时5秒没处理完、BroadcastReceiver超时前台10秒后台60秒、Service超时前台20秒后台200秒。但笔试给的这段日志更偏向常见的Binder阻塞。我给的排查思路是先看trace文件定位主线程在哪个方法阻塞再看是不是有死锁比如主线程等子线程释放锁子线程又在等主线程的Binder调用。这种死锁在实际开发中特别常见尤其是用了同步锁又跨进程通信时。我还补充了一种排查经验用adb shell am force-stop先杀掉App进程再通过修改代码在关键方法前后加日志缩小阻塞范围。很多新人对ANR的排查无从下手其实就是因为不会用系统输出的trace日志觉得信息量太大。其实只要抓第一屏的main线程堆栈看它在等什么锁或什么IPC基本就能定位方向。4.4 View绘制流程measure、layout、draw最后一道系统机制题是自定义View的绘制流程。题目给了自定义View的onMeasure实现要你说出存在的问题。这个代码我印象很深它直接用getSuggestedMinimumWidth()作为测量结果忽略了MeasureSpec的specSize和specMode。我在分析时指出了关键问题如果父布局给的是AT_MOST模式也就是wrap_content直接返回最小宽度会导致自定义View占据的内容区域比预期小如果父布局给的是EXACTLY模式也就是match_parent或精确值直接忽略specSize也会导致尺寸不对。正确做法是对EXACTLY模式直接用specSize对AT_MOST模式取specSize和期望宽度中的较小值对UNSPECIFIED模式用期望宽度。这个知识点在自定义View入门时很容易忽略因为大多数人都是直接写一个固定的onMeasure交给框架处理但当你的自定义View需要支持宽高自适应时就必须要理解MeasureSpec的三种模式。5. 开放性设计题网络层、缓存与启动优化5.1 设计一个高性能的网络层开放性设计题只有一道但分值不低10分。题目是如果让你从零设计一个网络层你会怎么做考虑哪些维度这类题的答题思路不是把代码写出来而是展示你的架构思维。我分了五块答接口设计、线程模型、缓存策略、安全性、监控体系。接口设计上我参考了Retrofit的设计理念——用注解声明请求参数把网络请求抽象成接口业务层面向接口编程不关心底层是OkHttp还是别的实现。这样换网络库时业务代码几乎不用改。线程模型方面请求分发放到IO线程池回调切到主线程用协程或者Handler都可以关键是不要在调用方手动切线程。缓存策略我特别强调了两层内存缓存用LRU磁盘缓存用OkHttp的Cache类同时根据接口的幂等性决定缓存策略——GET请求可以加缓存POST请求要老实走网络。安全方面HTTPS证书校验不能只是信任所有证书至少要做证书固定Certificate Pinning避免中间人攻击。监控体系则是要统计请求成功率、耗时分布、错误码分布这块如果笔试题能想到说明你有线上意识。5.2 App启动优化你会怎么优化冷启动速度这道设计题其实很落地给的场景是线上反馈App冷启动慢用户感知明显请给出你的排查和优化思路。我分三步回答第一步先量化用adb shell am start -W拿启动耗时再用Perfetto抓trace确定耗时分布第二步是分模块优化——Application的onCreate里如果有大量SDK初始化就改成懒加载或者并行初始化ContentProvider如果太重可以用ActivityLifecycleCallbacks替代减少启动时的内容提供者开销首帧布局太复杂就做布局异步inflate或者用ConstraintLayout减少层级第三步是兜底方案启动页可以先展示一个简单的占位布局等首帧数据准备好再切换到主界面这样用户感知上启动快了。这类题没有标准答案但出题人想看你有没有系统性思维。面试官最怕的就是只会某个单一技术点、一提到整体优化就抓瞎的候选人。所以答题时宁可答得宽一点也不要在某一个点上钻太深耽误后面做设计题的时间。5.3 设计题答题策略与常见误区设计题最重要的不是写代码而是展示分析框架。我看到有些同学拿到这题就开始写OkHttp的封装源码写了半小时还没写完这就是方向跑偏了。正确的时间分配应该是想清楚架构10分钟画出模块图5分钟然后写清楚每个模块的职责和取舍理由20分钟最后留一点时间补充边界情况和扩展思考。这样答出来的东西既能让阅卷人看到广度又能体现深度。还有一个常见误区是把设计题当成八股文来背。比如问网络层就直接把OkHttp拦截器背一遍而不提为什么需要这些拦截器——连接复用是为了减少TCP三次握手开销超时重试是为了应对弱网环境数据解析需要支持Protobuf和JSON两种格式是因为不同业务线协议不同。如果你不提“为什么”那这段回答就只是知识点的堆砌不是真正的设计能力。6. 高频失分点总结与备考建议6.1 这次笔试大家都在哪里丢分考完走出考场我在楼下碰到好几个一起考试的同学大家交流下来发现几个集中的失分点特别有代表性。第一个是读题不仔细尤其是“下列说法正确的是”“以下哪项不是”这类反向提问。有一个同学说他把双选题做成了单选题就是因为题干里写了“选出所有正确的选项”他扫一眼就以为是单选白白丢了五六分。第二个是概念细节掌握不牢。比如单选里面有一道考Android Studio相关的构建工具版本对应关系问AGP 8.0版本对Gradle版本的要求是多少很多人只记了个大概结果选项给的是含糊的版本号就懵了。这类题考验的不是刷题量而是平时开发中是否关心工程配置。第三个是手写代码时的代码风格问题。有一些同学明明算法思路是对的但没处理空指针、没加注释、变量名起得不好结果被扣了分数。笔试的代码题其实是模拟Code Review的过程阅卷人第一眼看的是“这段代码像不像一个合格工程师写出来的”其次才是正确性。第四个是时间分配不合理。这套卷子120分钟我周围有两位同学在选择题上花了太多时间最后代码题来不及写完。我自己的节奏是选择题控制在35分钟内遇到犹豫的题先标记绝不恋战代码题每道控制在15到20分钟系统分析题控制在10分钟内最后留10分钟检查。6.2 针对后续批次的精准复习建议如果你参加的是后续批次我的建议可以浓缩成三句话刷透LeetCode Top100、精读Handler和Binder源码、自己动手写两个自定义View。LeetCode刷题建议按专题刷数组、字符串、链表、二叉树、动态规划。其中二叉树相关的遍历、重建、路径问题几乎每年春招笔试都会出现。链表题的指针操作和边界处理也是面试官判断你基本功是否扎实的重要参考。Handler和Binder是Android系统机制的重灾区也是选择题和系统分析题的共同重点。Handler要把MessageQueue的enqueueMessage和next方法读一遍理解同步屏障、空闲消息、消息复用这些概念。Binder要把ServiceManager、Binder驱动、mmap机制这条链路摸透最好能自己写一个AIDL的Demo遇到跨进程回调时能讲清楚oneway和同步调用的区别。自定义View则不用贪多写两三个就够了但每个都要写完整一个支持wrap_content的圆角ImageView、一个自带测量逻辑的流式布局、一个带缩放和拖动的图片控件。写完之后多问自己几个“为什么”——为什么onMeasure要处理三种MeasureSpec为什么draw的时候要save和restore这样笔试时遇到相关题目你就不是背答案而是讲自己的实践。6.3 版本兼容与技术演进相关考点我发现今年的笔试已经把Android新版本特性作为一个独立的考察板块了。虽然只考了两道选择题但背后传递的信号很清楚团队需要能跟上技术演进的Android工程师。有一道题考的是Android 14的某些行为变更比如前台服务类型声明、动态广播接收时的导出要求。如果你平时开发的项目targetSdkVersion还停留在28或30那你对Android 14的这些变更肯定没有感知。想补这块最有效的方式是看官方文档的版本行为变更页面尤其是与targetSdkVersion强相关的变更这些都是笔试的高频素材。还有一道题跟R8代码混淆有关。问的是R8和ProGuard的区别以及在开启资源收缩时需要注意什么。这道题对平时不接触构建优化的同学来说有点冷门。结论是R8在ProGuard的基础上还内置了资源压缩、内联、常量折叠等优化但开启资源收缩时要注意keep规则否则会误删反射调用的类。这题恰恰是很多做过马甲包或海外包优化的工程师的日常考到反而能筛出有真实构建经验的人。6.4 工具链与开发环境考点选择题里有道题我记得比较清楚问Android Studio Hedgehog对应哪个AGP版本。这种题目说难不难但就是在考你有没有跟进工具链版本更新的习惯。我当时按记忆选了AGP 8.2因为Hedgehog | 2023.1.1的版本号对应关系在官方Release Notes里写得很清楚。我强烈建议准备笔试的朋友把AGP和Gradle的版本对应关系整理成一份速查表。这不仅是备考实际开发中也很常用——项目升级Android Studio后AGP版本不匹配会直接导致编译失败报错信息就是“Could not load compiled classes for settings file”之类的诡异提示这时候排查就得先看版本对应表。还有一道题问Android SDK的目录结构说到了platform-tools、build-tools、platforms这几个目录的作用。这道题对一直用IDE开发、没自己配置过SDK的人来说可能靠猜但只要你手动配置过环境变量基本就是送分。6.5 车载与跨端方向的新变化我在复盘最后想特别提一下车载和跨端。今年春招Android岗位的描述里明显多了车载相关的方向笔试虽然没有直接考车载系统的题目但有一道选择题考的Phonestatelistener的注册和回调其实就是车载场景里处理电话状态的基础。另外与跨端相关笔试考到了HarmonyOS Next的兼容性。题目问的是一套代码需要适配iOS、Android和HarmonyOS时消息推送和文件存储模块分别有哪些注意点。这其实已经超出了传统Android的范畴我认为出题人的意图是考察候选人能否跳出单一平台思考——文件路径不能硬编码要用平台提供的沙盒目录ContentProvider的Uri对外暴露时要设计权限控制这些都是跨端开发最常见的兼容性问题。如果你投递的岗位描述里带了“车机方向”“跨端方向”这类关键词建议笔试前专门看下对应方向的基础概念。车机方向重点看蓝牙配对、CarService、多屏互动跨端方向重点看统一存储、消息通道、包管理差异。不需要太深但至少不能被选择题问倒。7. 考后复盘这套题传递出来的招聘信号7.1 基础、深度和工程能力三位一体整套卷子做下来我的感受是这是一套很聪明的试卷。它没有出偏题怪题所有题目都是日常开发中真实会遇到的场景但每道题都可以向深处延展。选择题里问SP的apply和commit代码题里让你写LRU设计题里问网络层架构——这三个题覆盖了一个Android工程师的三个层级会用API、懂原理、能设计系统。对于想拿Offer的同学这套题其实就是一份免费的能力体检报告。如果你选择题做得顺说明你的基础不错如果代码题写起来不卡壳说明你有真正的编码量如果系统分析和设计题能答出框架感那你应该有希望进入下一轮面试。7.2 笔试和面试的衔接点笔试结束并不意味着复习结束。按照往年经验笔试里考到的知识点大概率会在三轮面试中再次出现只是形式更灵活——笔试考你选择题面试直接让你“讲一下Handler机制”笔试考你写合并区间面试让你“分析一下这个算法的时间和空间复杂度能否优化”。所以我的建议是考完当天就把错题和不确定的题目整理出来对照源码和官方文档答疑把这些知识点变成自己的表达素材。这样笔试就成了面试的第一轮预习。我见过很多同学笔试过了但挂在技术面复盘时发现原因惊人一致笔试时蒙对的题面试时原形毕露。所以千万别有侥幸心理蒙对的题也要搞明白。7.3 下一批次复习的优先级排序最后再说一下优先级。如果把三批笔试的备考时间分配出来我建议这样安排第一优先级是代码能力占比约四成。每天固定刷2到3道LeetCode重点放在数组、链表、二叉树、动态规划。第二优先级是Android系统机制占比约三成。每天精读一个源码文件优先顺序是MessageQueue、Binder、ActivityThread、ViewRootImpl。第三优先级是工程化和新版本特性占比约两成。关注AGP和Gradle版本对应关系、Android 14的行为变更、R8混淆规则。第四优先级才是八股文背诵占比约一成。背的时候也要结合自己的项目经历去理解不要死记硬背。7.4 写在最后的个人体会我是从秋招一路走到春招的最大的体会有两点。第一点Android开发这个行业现在确实不缺只会写界面的人缺的是能深挖系统原理、能解决线上疑难杂症、能设计稳定架构的工程师。笔试题目再怎么变核心考察的还是这三项能力。第二点备考不只是为了拿到Offer。我在准备这套笔试的过程中重新把Handler的源码、Binder的驱动逻辑、LRU的实现都读了一遍花了不少时间但收获很大——这对后面面试的成长价值比我刷十套题都大。如果你也在准备Android春招希望这份复盘能帮你少走一些弯路。笔试本身不是终点它是你开始系统梳理自己知识体系的契机。祝后面批次的同学都能稳定发挥拿到心仪的Offer。 2023小满春招Android笔试复盘：系统机制与代码能力全解析
20分钟前我刚从考场出来趁着记忆还热乎赶紧把今天这场2023年度小满春招Android研发岗第二批笔试的完整复盘写下来。先说结论整套卷子不算偏但非常考察“基本功是否扎实”尤其是对Android系统机制的理解深度光背面试题没用得真正写过代码、排查过线上问题的人才能答得顺手。这应该是今年春招Android岗里质量比较高的一套笔试题了。我参加的是第二批笔试整体时长120分钟题量不大但每一道题都值得展开说。题型分四块不定项选择题、手写代码题、系统机制分析题、开放性设计题。分值分布大概是选择30分、代码40分、系统分析20分、设计10分。从这分值就能看出来这场笔试的核心导向是——代码能力是底线系统理解是分水岭。这篇复盘我会按题型逐一拆解每道题不光给答案还会把我当时为什么会这么想、有哪些容易踩的坑、以及考完查资料验证后的结论都写出来。如果你的目标也是大厂Android岗这份内容能帮你少走很多弯路。1. 整体试卷结构与考察逻辑拆解1.1 为什么是这样一份卷子春招笔试和秋招不太一样。秋招更像海选题量大、覆盖面广用来快速筛人春招一般是补录名额少所以题目会更精准专门考察“你来了能不能直接干活”。小满这场第二批笔试就很有代表性没有一道题是纯粹背概念的所有题都长在真实开发场景里。从出题逻辑来看这套卷子先通过选择题把基础不牢的人筛掉再用代码题确认工程能力然后靠系统机制题区分深度最后用一道设计题考察架构思维。这个逻辑和很多一线互联网公司的面试流程是一致的——先是简历筛选再是笔试筛基础然后面试看潜力。有个细节值得注意不定项选择里好几道题都是“下列说法正确的是”这种题型比单选难很多因为选项里常常有两三个都是对的只是表述的严谨程度不同。我旁边好几个考生就栽在这上面看到某个选项觉得眼熟就直接选了没注意到它少了一个限定条件。1.2 选择题高频考点分布我把整张卷子的选择题考点整理了一下大致分布如下考点方向题数考察深度Java/Kotlin基础4道中等偏底层实现四大组件与启动模式3道中等偏边界场景Handler与消息循环2道较深涉及同步屏障Binder与IPC机制2道深涉及底层原理内存管理与优化3道中等偏实战排查多线程与并发2道较深涉及锁机制新特性与Jetpack2道中等偏版本差异编译构建与混淆2道中等偏流程理解这个分布其实透露了一个重要信息纯API调用和控件使用几乎没考考的全是“你在用的时候知不知道它背后发生了什么”。比如有一道题问SharedPreferences的apply()和commit()的区别表面上是问两个方法的差异实际是在考察你对进程存活时间、ANR触发机制、以及SP实现原理的理解。所以准备笔试的时候我强烈建议不要只看面试题大全那玩意儿只能帮你过选择题的前几道送分题。真正的分水岭在系统机制题和手写代码题这两块必须靠平时积累。1.3 第一批和第二批的差异推测我没参加第一批但考完和群里的同学对了下信息发现两批试卷在风格上高度一致只是具体题目不同。第一批考了RecyclerView的缓存复用机制第二批考了自定义View的绘制流程第一批的算法题是TopK问题第二批改成了合并区间。这说明出题人手里有一整套题库每次笔试随机抽题但考察维度是固定的。这个信息有什么价值呢如果你还在等第三批那复习重点应该放在Android系统机制里的三大核心——Binder机制、Handler机制、View绘制流程算法题重点准备数组操作、链表、二叉树这三种高频题型。往年真题可以参考牛客网上的Android专区但更重要的是把每道题的原理彻底搞懂因为换一层皮就又是一道新题。2. 不定项选择题逐题复盘2.1 Java/Kotlin基础题看似送分实则陷阱多选择题第一道就给我来了个下马威。题目大概是关于Kotlin的协程下列说法正确的是。选项里有几个表述我印象很深协程比线程更轻量协程必须运行在线程上withContext可以切换线程GlobalScope是推荐使用的协程作用域。这道题单看每个选项前三个都是对的但第四个就有问题了。GlobalScope虽然确实存在但官方文档里明确标注它是非结构化并发生命周期跟整个应用绑定容易造成内存泄漏因此不推荐在业务代码里使用。如果对协程只是停留在“会用launch和async”的层面这道题很容易选错。还有一道题考Java的字符串比较问下面哪个表达式返回true。这种题在面试里已经算老掉牙了但笔试里依然会出现而且大多数人都栽在细节上——new String(a) a返回false因为一个是堆对象一个是常量池引用但a new String(a).intern()又返回true因为intern()会去常量池里找。这种题考察的就是JVM内存模型的基本功看书的时候觉得简单考试的时候却容易脑子一热选错。2.2 四大组件相关启动模式的边界情况Activity启动模式这道题考的是singleTask和singleTop的区别。普通场景大家都知道但题目设置了一个场景当前栈顶是Activity A此时又通过Intent启动Activity A如果A的启动模式是singleTop会不会创建新实例答案是复用栈顶实例并回调onNewIntent()不会创建新实例。但如果不限定是栈顶那就得看singleTask的栈内复用了。这题的坑在于很多人记住了“singleTask是栈内复用”就以为万事大吉却没注意到它还有个附带效果——它会清空它之上的所有Activity。笔试题目把这个也作为选项设计了而且这个描述单独看是“正确”的但放在“以下说法错误的是”这个题干下就变成了正确答案。还有一道Service相关的题也值得一说。问的是startService和bindService同时调用时Service的生命周期是怎样的。大多数人只知道startService会启动服务、bindService会绑定服务但题目问的是两者都调用时onCreate、onStartCommand、onBind、onUnbind、onDestroy的调用顺序。结论是第一次startService时先走onCreate再走onStartCommand第一次bindService时走onCreate再走onBind如果前面已经onCreate过了就不会重复调用。最后分开解绑和停止时关键是看Service实例的引用计数归零——当start和bind都调用了需要stopService和unbindService都执行完onDestroy才会被调用。这个知识点在开发中挺常见的比如音乐播放器既被start又需要让Activity绑定拿Binder很多人就是因为没搞懂才写出内存泄漏。2.3 BroadcastReceiver与Android 8.0限制今年笔试的热点题目之一就是Android 8.0之后对静态广播接收器的限制。题目问的是在Android 8.0及以上版本隐式广播的静态注册现在怎么样了答案是系统限制了静态注册接收隐式广播但显式广播和一些特定系统广播比如BOOT_COMPLETED不受影响。这个知识点如果只是背八股很容易把“所有静态注册都失效”这种错误表述当成对的。但实际开发中你会遇到Manifest注册的Receiver收不到通知的现象多数情况就是版本限制导致的。我在实际项目里也踩过这个坑。当时是做一个开机自启动的功能在Android 9的设备上完全收不到BOOT_COMPLETED广播排查了半天最后发现是国内厂商ROM的电池优化策略给杀了。这个问题的排查思路也值得分享一下先确认广播是显式还是隐式再看是否属于系统白名单广播最后检查应用是否被厂商后台限制。笔试题目里虽然没考得这么深但如果你在答题时能提到这些边界情况阅卷人的印象会好很多。2.4 Handler机制同步屏障与消息优先级Handler机制这道题我看完心里是有点惊喜的因为考到了同步屏障。题目大概是关于Handler的消息处理机制以下说法正确的是。其中一个选项是“MessageQueue可以通过postSyncBarrier插入同步屏障此时异步消息会优先执行”。这个知识点偏底层但这两年特别爱考。原因也很简单——Choreographer处理帧绘制时就用到了同步屏障机制如果你只停留在“Handler是用来切换线程的”这个层面遇到掉帧问题根本无从下手。这里我建议准备笔试的同学花点时间把Handler、MessageQueue、Looper三件套的源码静下心看一遍尤其是MessageQueue的next()方法里屏障相关的逻辑搞清楚之后很多选择题基本就是送分。我当时在这道题上多留了个心眼把“同步屏障需要手动移除”这个选项也一起选了。因为确实是这样postSyncBarrier之后必须调用removeSyncBarrier否则消息队列会一直卡在同步屏障这里那些“同步消息”就永远得不到执行。这在实际开发里就是那种“偶现卡死过会儿自己好”的诡异bug面试官要是追问起来答不上来就很尴尬。2.5 Binder与IPC不止于AIDLBinder机制在选择题里考了两道。一道是问Binder相对于其他IPC方式的优势另一道是问mmap在Binder中的作用。这两个问题我在准备阶段刚好都复习到了所以答得比较顺畅。先说优势Binder只需要一次数据拷贝而传统的管道、消息队列和Socket都需要两次拷贝。原因是Binder在驱动层利用mmap把内核缓冲区和用户空间做了内存映射数据从发送方用户空间拷贝到内核缓冲区后接收方通过映射直接就能访问不需要再往接收方用户空间拷贝一次。这个设计让Binder在性能上碾压了传统IPC方式同时又因为每个进程都有UID内核层可以直接校验调用方身份安全性也更好。mmap那题更细一点问的是Binder中mmap的作用是什么。选项有分配内核缓冲区、建立数据映射、拷贝数据、管理引用计数。前两个是核心数据拷贝和引用计数都不是mmap直接做的事。我见过不少同学AIDL用得很溜但问到底层就答不上来可笔试偏偏就是要考这一层。2.6 内存管理与Splash冷启动内存管理方向出了三道题其中一道考的是Activity泄漏的检测方式和常见原因还有一道考了冷启动的定义和耗时统计。Activity泄漏这题比较常规常见原因就是静态变量持有了Activity引用、Handler未移除回调、内部类隐式持有外部类引用等。比较新奇的是冷启动那道题它问的是冷启动的时间从哪个节点开始算。正确答案是从进程创建开始到Activity的onResume执行完结束。但这里有个细节很多资料都没讲清楚从onCreate到onResume只是开发者能感知的部分进程创建和ActivityThread.main()的启动时间也占了大头。优化冷启动性能时不能只盯着自己的启动代码Application的初始化、ContentProvider的启动耗时都影响巨大。我在项目中优化启动速度的实操经验是先用adb shell am start -W命令拿到Displayed时间和TotalTime再结合systrace或者Perfetto看主线程到底在等什么。很多性能优化的文章一上来就讲怎么用工具但笔试只考结论——冷启动时间过长的常见原因包括主线程做耗时操作、ContentProvider初始化慢、首帧布局过于复杂。这几个结论在选择题里对应了好几个选项纯靠猜很难全对。2.7 选择题核心考点速查表复盘完整张选择题部分我把重要考点做成了一张速查表方便后面批次的考生快速定位复习方向考点核心结论易错点Kotlin协程GlobalScope不推荐使用只看launch/async用法不看生命周期字符串比较比较引用equals比较内容intern()入池混淆池中对象和堆对象singleTop栈顶复用回调onNewIntent忽略“栈顶”前提Service生命周期onCreate只执行一次startbind要同时解绑才销毁以为start和bind是两条独立生命周期Android 8.0广播隐式广播静态注册受限以为所有静态注册都失效Handler同步屏障屏障期间异步消息优先需手动移除不知道postSyncBarrier的副作用Binder mmap内核态与用户态映射一次拷贝把数据拷贝也归功于mmap冷启动耗时进程创建到onResume完成只统计Activity内部的onCreate如果你现在正准备第三批笔试这张表值得重点背。表里每一行都是选择题高频出题方向我复盘了下周围参加第一批、第二批的人大家反馈的考点基本没跳出这个范围。3. 手写代码题四道题四种风格3.1 算法题一合并区间这道题是LeetCode 56题的原题给定一个区间的集合合并所有重叠的区间。题目本身不难但笔试要求写出完整可运行的代码而且要考虑边界条件。我的第一反应是按区间左端点排序然后依次遍历合并。思路很简单排完序后如果当前区间的左端点大于上一个合并后区间的右端点说明不重叠直接加入结果否则更新右端点为两者最大值。时间复杂度是O(n log n)主要花在排序上。当时我额外注意了两个边界一个是空数组的判断另一个是int值溢出。区间合并时右端点用Math.max处理但如果区间值可能是Integer.MAX_VALUE排序和比较时就要小心。我写的核心代码如下public int[][] merge(int[][] intervals) { if (intervals null || intervals.length 1) { return intervals; } Arrays.sort(intervals, (a, b) - a[0] - b[0]); Listint[] merged new ArrayList(); int[] current intervals[0]; for (int i 1; i intervals.length; i) { if (intervalis[1] current[0]) { current[1] Math.max(current[1], intervals[i][1]); } else { merged.add(current); current intervals[i]; } } merged.add(current); return merged.toArray(new int[merged.size()][]); }这题的坑不在算法本身而在代码规范。我记得题目要求里特别写了“请使用Kotlin或Java实现并注意代码风格”这就意味着哪怕是笔试也要写出工程化的代码——变量命名要清晰、空值要判断、循环要避免越界。3.2 算法题二实现一个线程安全的LRU缓存这道题是整张卷子里我觉得最有区分度的一道。它要求实现一个LRU缓存支持get和put操作并且要求线程安全。题目没指定语言我选了Kotlin因为Kotlin在表达链表操作时更简洁。LRU的经典实现是HashMap加双向链表。HashMap负责O(1)查找双向链表负责维护访问顺序。每次get时把节点移到链表头部每次put时如果容量满了就淘汰尾部节点。用Java的话可以直接继承LinkedHashMap然后重写removeEldestEntry但笔试如果只写这个会显得你只会调库所以我选择了自己实现。线程安全方面可以直接在get和put方法上加synchronized也可以用ReentrantReadWriteLock做读写分离。我当时用的是ReentrantReadWriteLock因为get操作是读多写少读写锁性能更好public class LRUCacheK, V { private final int capacity; private final LinkedHashMapK, V map; private final ReadWriteLock lock new ReentrantReadWriteLock(); public LRUCache(int capacity) { this.capacity capacity; this.map new LinkedHashMapK, V(capacity, 0.75f, true) { Override protected boolean removeEldestEntry(Map.EntryK, V eldest) { return size() capacity; } }; } public V get(K key) { lock.readLock().lock(); try { return map.getOrDefault(key, null); } finally { lock.readLock().unlock(); } } public void put(K key, V value) { lock.writeLock().lock(); try { map.put(key, value); } finally { lock.writeLock().unlock(); } } }这里有个细节笔试容易忽略LinkedHashMap的accessOrder参数。构造器第三个参数传true时每次get都会把对应节点移到链表尾部从而实现LRU顺序。如果不传这个参数那就是插入序完全达不到LRU效果。如果实在不放心自己手写用LinkedHashMap这一版不但简洁而且不容易写出链表断裂的bug笔试现场能减少废代码量。3.3 代码题三自定义View实现圆角ImageView这道题出现在笔试里我还挺意外的因为一般自定义View更多在面试里以口头问的形式出现。但小满这批笔试直接要求手写代码题目是实现一个圆角ImageView要求支持任意圆角半径并且能处理图片缩放。核心思路是把Bitmap裁剪成圆角用Paint的Xfermode或者直接使用Outline。当时我选择的是先用BitmapShader加载图片然后通过drawRoundRect绘制。这样代码简洁而且性能比用Bitmap.createBitmap重新裁剪要好很多因为避免了二次拷贝像素。关键代码大致是这个结构public class RoundImageView extends AppCompatImageView { private float radius; private Paint paint; private BitmapShader shader; private RectF rectF; public RoundImageView(Context context, AttributeSet attrs) { super(context, attrs); init(); } private void init() { paint new Paint(Paint.ANTI_ALIAS_FLAG); paint.setFilterBitmap(true); rectF new RectF(); } Override protected void onDraw(Canvas canvas) { if (getDrawable() null) { return; } Bitmap bitmap drawableToBitmap(getDrawable()); if (bitmap ! null) { shader new BitmapShader(bitmap, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP); paint.setShader(shader); rectF.set(0, 0, getWidth(), getHeight()); canvas.drawRoundRect(rectF, radius, radius, paint); } } }这道题考察的知识点很综合图片的采样、Canvas绘制、Shader的TileMode、onDraw方法的调用时机。我现场写完后还专门检查了有没有处理scaleType的差异——setImageURI和setImageBitmap都会走不同的内部路径如果没处理好图片显示会被拉伸变形。我当时的处理方式是覆写setImageBitmap和setImageResource方法统一invalidate触发重绘并在drawableToBitmap里按控件宽高做CenterCrop逻辑这样圆角效果就不会被原始的fitCenter缩放破坏。3.4 算法题四TopK高频元素这道题是从一个非空整数数组里找出出现频率最高的K个元素。我选了小顶堆的实现先用HashMap统计频率再维护一个大小为K的小顶堆堆顶是当前K个元素中频率最小的新元素频率比堆顶大就替换并调整堆。public int[] topKFrequent(int[] nums, int k) { MapInteger, Integer freqMap new HashMap(); for (int num : nums) { freqMap.put(num, freqMap.getOrDefault(num, 0) 1); } PriorityQueueInteger minHeap new PriorityQueue( (a, b) - freqMap.get(a) - freqMap.get(b) ); for (Integer num : freqMap.keySet()) { minHeap.offer(num); if (minHeap.size() k) { minHeap.poll(); } } int[] result new int[k]; for (int i 0; i k; i) { result[i] minHeap.poll(); } return result; }这种解法时间复杂度是O(n log k)空间复杂度是O(n)。现场能写出来不算难但有些同学会直接想到用sort那样就是O(n log n)了在数据特别大时会有性能问题。笔试一般不会要求你现场跑大数据量但如果你在复杂度分析里写错还是会扣分的。代码题总结下来就一句话平时多练LeetCode的Top100尤其是数组、链表、二叉树三块同时要把每道题的复杂度和边界条件讲清楚。笔试考的不只是会不会写更是你有没有编程的基本素养。4. 系统机制分析题直击Android内核与框架4.1 Binder驱动的mmap机制系统机制分析题的第一道直接给了一段Binder发送数据的底层描述要你说明Binder在数据拷贝和线程等待方面的设计。这题我答得比较细。Binder通信中当进程A调用进程B提供的服务时数据流向是这样的进程A的用户空间数据通过copy_from_user拷贝到Binder驱动程序的内核缓冲区这个过程发生一次拷贝然后因为进程B在binder_mmap时已经将自己的用户空间地址映射到了这个内核缓冲区所以进程B可以直接读取不需要第二次拷贝。线程等待方面Binder的调用是同步的进程A的调用线程会通过binder_thread_read进入wait_event_freezable直到进程B完成处理后唤醒。理解了这个机制你才能解释为什么主线程调用Binder接口可能导致ANR——如果B服务端处理过慢A的主线程会一直阻塞在Binder调用上超过5秒就触发ANR。这道题我在答题时特意画了一个简化的流程A进程用户空间 - Binder驱动内核缓冲区一次拷贝 - B进程用户空间mmap映射。然后在旁边写了Thread A等待和唤醒的时机。虽然笔试是文字回答但能把流程理到这个颗粒度说明你是真的理解过而不是背的八股。4.2 AMS与Activity启动流程第二道系统机制题问的是从startActivity到首帧显示整个过程中涉及哪些关键系统服务说出至少四个并分别说明作用。我按流程答先说了Instrumentation种的execStartActivity发起请求然后是AMS接收Intent完成进程检查、Activity栈管理、生命周期调度如果目标进程不存在就要通过Zygote fork出新的应用进程新进程初始化时通过ActivityThread的main方法启动主线程创建Application然后通过H类Handler把消息切回主线程创建Activity最后是ViewRootImpl的performTraversals方法触发测量、布局、绘制三步曲完成首帧显示。这题考察的是对整个启动链路的理解如果能补充一些细节会更好比如ActivityRecord和TaskRecord的关系、Zygote的Socket通信机制、以及冷启动时Application和ContentProvider的初始化顺序。阅卷人看到你能把链路串起来就不会只给个基础分。4.3 ANR的成因分析与排查思路ANR这道题比较务实。题目给了三段日志要你说出可能产生ANR的原因并给出至少两种排查方法。我在分析日志时发现一个特征主线程在等待一个Binder调用返回已经超过了5秒而且CPU占用率很低。这个现象基本可以推断为应用在等待某个系统服务或者跨进程操作该操作迟迟没有返回而主线程被锁死了。正常ANR有三种类型——输入事件超时5秒没处理完、BroadcastReceiver超时前台10秒后台60秒、Service超时前台20秒后台200秒。但笔试给的这段日志更偏向常见的Binder阻塞。我给的排查思路是先看trace文件定位主线程在哪个方法阻塞再看是不是有死锁比如主线程等子线程释放锁子线程又在等主线程的Binder调用。这种死锁在实际开发中特别常见尤其是用了同步锁又跨进程通信时。我还补充了一种排查经验用adb shell am force-stop先杀掉App进程再通过修改代码在关键方法前后加日志缩小阻塞范围。很多新人对ANR的排查无从下手其实就是因为不会用系统输出的trace日志觉得信息量太大。其实只要抓第一屏的main线程堆栈看它在等什么锁或什么IPC基本就能定位方向。4.4 View绘制流程measure、layout、draw最后一道系统机制题是自定义View的绘制流程。题目给了自定义View的onMeasure实现要你说出存在的问题。这个代码我印象很深它直接用getSuggestedMinimumWidth()作为测量结果忽略了MeasureSpec的specSize和specMode。我在分析时指出了关键问题如果父布局给的是AT_MOST模式也就是wrap_content直接返回最小宽度会导致自定义View占据的内容区域比预期小如果父布局给的是EXACTLY模式也就是match_parent或精确值直接忽略specSize也会导致尺寸不对。正确做法是对EXACTLY模式直接用specSize对AT_MOST模式取specSize和期望宽度中的较小值对UNSPECIFIED模式用期望宽度。这个知识点在自定义View入门时很容易忽略因为大多数人都是直接写一个固定的onMeasure交给框架处理但当你的自定义View需要支持宽高自适应时就必须要理解MeasureSpec的三种模式。5. 开放性设计题网络层、缓存与启动优化5.1 设计一个高性能的网络层开放性设计题只有一道但分值不低10分。题目是如果让你从零设计一个网络层你会怎么做考虑哪些维度这类题的答题思路不是把代码写出来而是展示你的架构思维。我分了五块答接口设计、线程模型、缓存策略、安全性、监控体系。接口设计上我参考了Retrofit的设计理念——用注解声明请求参数把网络请求抽象成接口业务层面向接口编程不关心底层是OkHttp还是别的实现。这样换网络库时业务代码几乎不用改。线程模型方面请求分发放到IO线程池回调切到主线程用协程或者Handler都可以关键是不要在调用方手动切线程。缓存策略我特别强调了两层内存缓存用LRU磁盘缓存用OkHttp的Cache类同时根据接口的幂等性决定缓存策略——GET请求可以加缓存POST请求要老实走网络。安全方面HTTPS证书校验不能只是信任所有证书至少要做证书固定Certificate Pinning避免中间人攻击。监控体系则是要统计请求成功率、耗时分布、错误码分布这块如果笔试题能想到说明你有线上意识。5.2 App启动优化你会怎么优化冷启动速度这道设计题其实很落地给的场景是线上反馈App冷启动慢用户感知明显请给出你的排查和优化思路。我分三步回答第一步先量化用adb shell am start -W拿启动耗时再用Perfetto抓trace确定耗时分布第二步是分模块优化——Application的onCreate里如果有大量SDK初始化就改成懒加载或者并行初始化ContentProvider如果太重可以用ActivityLifecycleCallbacks替代减少启动时的内容提供者开销首帧布局太复杂就做布局异步inflate或者用ConstraintLayout减少层级第三步是兜底方案启动页可以先展示一个简单的占位布局等首帧数据准备好再切换到主界面这样用户感知上启动快了。这类题没有标准答案但出题人想看你有没有系统性思维。面试官最怕的就是只会某个单一技术点、一提到整体优化就抓瞎的候选人。所以答题时宁可答得宽一点也不要在某一个点上钻太深耽误后面做设计题的时间。5.3 设计题答题策略与常见误区设计题最重要的不是写代码而是展示分析框架。我看到有些同学拿到这题就开始写OkHttp的封装源码写了半小时还没写完这就是方向跑偏了。正确的时间分配应该是想清楚架构10分钟画出模块图5分钟然后写清楚每个模块的职责和取舍理由20分钟最后留一点时间补充边界情况和扩展思考。这样答出来的东西既能让阅卷人看到广度又能体现深度。还有一个常见误区是把设计题当成八股文来背。比如问网络层就直接把OkHttp拦截器背一遍而不提为什么需要这些拦截器——连接复用是为了减少TCP三次握手开销超时重试是为了应对弱网环境数据解析需要支持Protobuf和JSON两种格式是因为不同业务线协议不同。如果你不提“为什么”那这段回答就只是知识点的堆砌不是真正的设计能力。6. 高频失分点总结与备考建议6.1 这次笔试大家都在哪里丢分考完走出考场我在楼下碰到好几个一起考试的同学大家交流下来发现几个集中的失分点特别有代表性。第一个是读题不仔细尤其是“下列说法正确的是”“以下哪项不是”这类反向提问。有一个同学说他把双选题做成了单选题就是因为题干里写了“选出所有正确的选项”他扫一眼就以为是单选白白丢了五六分。第二个是概念细节掌握不牢。比如单选里面有一道考Android Studio相关的构建工具版本对应关系问AGP 8.0版本对Gradle版本的要求是多少很多人只记了个大概结果选项给的是含糊的版本号就懵了。这类题考验的不是刷题量而是平时开发中是否关心工程配置。第三个是手写代码时的代码风格问题。有一些同学明明算法思路是对的但没处理空指针、没加注释、变量名起得不好结果被扣了分数。笔试的代码题其实是模拟Code Review的过程阅卷人第一眼看的是“这段代码像不像一个合格工程师写出来的”其次才是正确性。第四个是时间分配不合理。这套卷子120分钟我周围有两位同学在选择题上花了太多时间最后代码题来不及写完。我自己的节奏是选择题控制在35分钟内遇到犹豫的题先标记绝不恋战代码题每道控制在15到20分钟系统分析题控制在10分钟内最后留10分钟检查。6.2 针对后续批次的精准复习建议如果你参加的是后续批次我的建议可以浓缩成三句话刷透LeetCode Top100、精读Handler和Binder源码、自己动手写两个自定义View。LeetCode刷题建议按专题刷数组、字符串、链表、二叉树、动态规划。其中二叉树相关的遍历、重建、路径问题几乎每年春招笔试都会出现。链表题的指针操作和边界处理也是面试官判断你基本功是否扎实的重要参考。Handler和Binder是Android系统机制的重灾区也是选择题和系统分析题的共同重点。Handler要把MessageQueue的enqueueMessage和next方法读一遍理解同步屏障、空闲消息、消息复用这些概念。Binder要把ServiceManager、Binder驱动、mmap机制这条链路摸透最好能自己写一个AIDL的Demo遇到跨进程回调时能讲清楚oneway和同步调用的区别。自定义View则不用贪多写两三个就够了但每个都要写完整一个支持wrap_content的圆角ImageView、一个自带测量逻辑的流式布局、一个带缩放和拖动的图片控件。写完之后多问自己几个“为什么”——为什么onMeasure要处理三种MeasureSpec为什么draw的时候要save和restore这样笔试时遇到相关题目你就不是背答案而是讲自己的实践。6.3 版本兼容与技术演进相关考点我发现今年的笔试已经把Android新版本特性作为一个独立的考察板块了。虽然只考了两道选择题但背后传递的信号很清楚团队需要能跟上技术演进的Android工程师。有一道题考的是Android 14的某些行为变更比如前台服务类型声明、动态广播接收时的导出要求。如果你平时开发的项目targetSdkVersion还停留在28或30那你对Android 14的这些变更肯定没有感知。想补这块最有效的方式是看官方文档的版本行为变更页面尤其是与targetSdkVersion强相关的变更这些都是笔试的高频素材。还有一道题跟R8代码混淆有关。问的是R8和ProGuard的区别以及在开启资源收缩时需要注意什么。这道题对平时不接触构建优化的同学来说有点冷门。结论是R8在ProGuard的基础上还内置了资源压缩、内联、常量折叠等优化但开启资源收缩时要注意keep规则否则会误删反射调用的类。这题恰恰是很多做过马甲包或海外包优化的工程师的日常考到反而能筛出有真实构建经验的人。6.4 工具链与开发环境考点选择题里有道题我记得比较清楚问Android Studio Hedgehog对应哪个AGP版本。这种题目说难不难但就是在考你有没有跟进工具链版本更新的习惯。我当时按记忆选了AGP 8.2因为Hedgehog | 2023.1.1的版本号对应关系在官方Release Notes里写得很清楚。我强烈建议准备笔试的朋友把AGP和Gradle的版本对应关系整理成一份速查表。这不仅是备考实际开发中也很常用——项目升级Android Studio后AGP版本不匹配会直接导致编译失败报错信息就是“Could not load compiled classes for settings file”之类的诡异提示这时候排查就得先看版本对应表。还有一道题问Android SDK的目录结构说到了platform-tools、build-tools、platforms这几个目录的作用。这道题对一直用IDE开发、没自己配置过SDK的人来说可能靠猜但只要你手动配置过环境变量基本就是送分。6.5 车载与跨端方向的新变化我在复盘最后想特别提一下车载和跨端。今年春招Android岗位的描述里明显多了车载相关的方向笔试虽然没有直接考车载系统的题目但有一道选择题考的Phonestatelistener的注册和回调其实就是车载场景里处理电话状态的基础。另外与跨端相关笔试考到了HarmonyOS Next的兼容性。题目问的是一套代码需要适配iOS、Android和HarmonyOS时消息推送和文件存储模块分别有哪些注意点。这其实已经超出了传统Android的范畴我认为出题人的意图是考察候选人能否跳出单一平台思考——文件路径不能硬编码要用平台提供的沙盒目录ContentProvider的Uri对外暴露时要设计权限控制这些都是跨端开发最常见的兼容性问题。如果你投递的岗位描述里带了“车机方向”“跨端方向”这类关键词建议笔试前专门看下对应方向的基础概念。车机方向重点看蓝牙配对、CarService、多屏互动跨端方向重点看统一存储、消息通道、包管理差异。不需要太深但至少不能被选择题问倒。7. 考后复盘这套题传递出来的招聘信号7.1 基础、深度和工程能力三位一体整套卷子做下来我的感受是这是一套很聪明的试卷。它没有出偏题怪题所有题目都是日常开发中真实会遇到的场景但每道题都可以向深处延展。选择题里问SP的apply和commit代码题里让你写LRU设计题里问网络层架构——这三个题覆盖了一个Android工程师的三个层级会用API、懂原理、能设计系统。对于想拿Offer的同学这套题其实就是一份免费的能力体检报告。如果你选择题做得顺说明你的基础不错如果代码题写起来不卡壳说明你有真正的编码量如果系统分析和设计题能答出框架感那你应该有希望进入下一轮面试。7.2 笔试和面试的衔接点笔试结束并不意味着复习结束。按照往年经验笔试里考到的知识点大概率会在三轮面试中再次出现只是形式更灵活——笔试考你选择题面试直接让你“讲一下Handler机制”笔试考你写合并区间面试让你“分析一下这个算法的时间和空间复杂度能否优化”。所以我的建议是考完当天就把错题和不确定的题目整理出来对照源码和官方文档答疑把这些知识点变成自己的表达素材。这样笔试就成了面试的第一轮预习。我见过很多同学笔试过了但挂在技术面复盘时发现原因惊人一致笔试时蒙对的题面试时原形毕露。所以千万别有侥幸心理蒙对的题也要搞明白。7.3 下一批次复习的优先级排序最后再说一下优先级。如果把三批笔试的备考时间分配出来我建议这样安排第一优先级是代码能力占比约四成。每天固定刷2到3道LeetCode重点放在数组、链表、二叉树、动态规划。第二优先级是Android系统机制占比约三成。每天精读一个源码文件优先顺序是MessageQueue、Binder、ActivityThread、ViewRootImpl。第三优先级是工程化和新版本特性占比约两成。关注AGP和Gradle版本对应关系、Android 14的行为变更、R8混淆规则。第四优先级才是八股文背诵占比约一成。背的时候也要结合自己的项目经历去理解不要死记硬背。7.4 写在最后的个人体会我是从秋招一路走到春招的最大的体会有两点。第一点Android开发这个行业现在确实不缺只会写界面的人缺的是能深挖系统原理、能解决线上疑难杂症、能设计稳定架构的工程师。笔试题目再怎么变核心考察的还是这三项能力。第二点备考不只是为了拿到Offer。我在准备这套笔试的过程中重新把Handler的源码、Binder的驱动逻辑、LRU的实现都读了一遍花了不少时间但收获很大——这对后面面试的成长价值比我刷十套题都大。如果你也在准备Android春招希望这份复盘能帮你少走一些弯路。笔试本身不是终点它是你开始系统梳理自己知识体系的契机。祝后面批次的同学都能稳定发挥拿到心仪的Offer。