聊 Android 面试这件事我踩过的坑大概比很多人想象得要多。前几年我自己跳槽那阵子简历投出去石沉大海复盘时才发现问题根本不在题背得够不够多而在我讲不清楚一件很朴素的事——这个方案当初为什么选它。后来我陆续帮几个学弟学妹做过模拟面试去年秋天一个准备转 Android 方向的学妹拿到了心仪的大厂 offer把她三个多月整理的复习笔记丢给我看我才意识到真正有效的 Android 面试准备是一套能力映射的工程而不是一份题目清单。这份笔记加上我自己这些年做技术面试官的经验基本覆盖了一个 Android 岗位从简历筛选到终面的大部分考察面。不管你是刚学完 Android Studio 环境搭建、能跑通一个增删改查的 App还是已经写了两三年业务代码想更进一步下面这些内容都能直接拿去对照补漏。我不会给你一份必背一百题而是按面试官到底在听什么这个角度把每一块该讲的深度都拆开。1. 先别急着背题Android 面试真正筛的是什么能力1.1 面试官手里那张看不见的评分表绝大多数人准备面试的方式是打开一个题库文档从第一题开始往下刷。这个方式不是没用但效率极低因为它假设了问题和能力是一一对应的。实际上面试官手里通常是一张相对模糊的评分表大致分成四栏基础扎实度、工程判断力、表达与沟通、成长潜力。同一道说说 Handler 机制的题不同的人答出来落点可能完全不同——有人背出了 MessageQueue 和 Looper有人能讲清楚主线程为什么阻塞在 native 层的 epoll 上却不触发 ANR还有人能顺带说出自己在项目里怎么用 IdleHandler 做延迟初始化。这三个答案在评分表上的位置是递增的。我后来跟那位学妹聊她面试中的实际感受她说最有用的一个转变是把我要答对这道题改成我要让面试官相信我能独立负责一个模块。这个转变听起来虚但落地方式很具体每讲一个知识点尽量带上三个东西——它解决什么问题、它内部大致怎么实现、我在真实项目里用它踩过什么坑。前两个靠读第三个只能靠做和复盘。如果你没有足够的项目经历去支撑第三点那就用我读源码时发现的或者我在一个小 demo 里验证过的来替代至少证明你是动手验证过的人而不是复述文档的人。1.2 三类问题的时间配比与准备顺序我把 Android 岗位的面试问题粗分成三类它们对应完全不同的准备方式混在一起准备是最容易浪费时间的。问题类型典型形式考察重点建议投入精力基础原理类Java/Kotlin 语法、Handler、Binder、View 绘制概念是否成体系有没有自相矛盾40%工程实践类性能优化、崩溃排查、架构选型有没有量化意识和取舍能力40%场景与手撕算法题、设计题、现场写代码编码基本功、思维清晰度20%很多人把 80% 的时间砸在第一类上结果被问到你那个启动优化到底省了多少毫秒、怎么测的就哑了。反过来说工程实践类是最能拉开差距的地方因为它很难临时背出来。我的建议顺序是先用一两周把基础原理的骨架搭起来然后立刻转到自己项目里找两三个真实问题深挖最后临考前两周集中刷手撕题保持手感。1.3 我见过的两种典型错误准备方式第一种是只背结论不留推导。比如你背下Android 的 GC 是并发复制收集器面试官追问一句那它和 HotSpot 的分代收集有什么区别为什么要这么设计你就卡住了。结论是可以查到的推导过程才能证明你理解。第二种是过度追求广度。有人会去翻一大堆冷门 API觉得覆盖面广就稳。但面试官通常只在他自己熟悉的领域深挖你把十个方向都讲得浮在表面不如把三四个方向讲到能画图、能写代码、能说出边界条件。我个人的经验是准备二十个能讲五分钟的话题比准备两百个能讲三十秒的话题要有效得多。2. Java 与 Kotlin从能用讲到为什么这么设计2.1 Android 上的运行时和标准 JVM 不是一回事这是被低估的一个话题。你如果只说Java 靠 JVM 跑有垃圾回收那基本等于没说。Android 从 4.4 之后逐步切到 ART运行方式在 AOT 和 JIT 之间做过好几轮调整理解这条演进线很多性能问题就自然解释得通了。最早 Dalvik 是解释执行加 JIT安装快、运行慢所以早期 Android 手机装个 App 要等很久的优化中其实是在做 dexopt。ART 上来之后改成安装时全量 AOT运行快但安装慢、占空间大。再往后引入 profile 引导的混合编译先解释执行把热点方法记录下来设备空闲时后台编译这些热点这样就兼顾了安装速度和运行效率。你如果能把这几个阶段和为什么要这么改讲清楚面试官对你的评价会立刻不一样。GC 也是同理。早期是标记清除加标记整理容易产生碎片和长时间停顿后来换成并发复制的方案把内存分成多个区域并行回收停顿时间明显缩短再后面引入分代思路针对大部分对象朝生夕死这个特点做优化。这背后其实就是一句话移动端的 GC 目标不是吞吐量而是尽可能短的卡顿。你把这句话讲出来比背一堆参数有用。2.2 线程池参数到底怎么算线程池几乎是必问题但多数人停在核心线程数、最大线程数、队列、拒绝策略这四个名词上。面试官真正想听的是你凭什么定这组参数。先说参数含义。任务进来时如果当前线程数小于核心线程数直接开新线程否则丢进阻塞队列队列满了再尝试把线程数扩到最大值还是满了就走拒绝策略。这里面最关键、也最容易出问题的是队列的选择。用无界队列的话最大线程数这个参数基本是废的因为队列永远不 Android面试准备：从背题到能力映射的系统复习指南
聊 Android 面试这件事我踩过的坑大概比很多人想象得要多。前几年我自己跳槽那阵子简历投出去石沉大海复盘时才发现问题根本不在题背得够不够多而在我讲不清楚一件很朴素的事——这个方案当初为什么选它。后来我陆续帮几个学弟学妹做过模拟面试去年秋天一个准备转 Android 方向的学妹拿到了心仪的大厂 offer把她三个多月整理的复习笔记丢给我看我才意识到真正有效的 Android 面试准备是一套能力映射的工程而不是一份题目清单。这份笔记加上我自己这些年做技术面试官的经验基本覆盖了一个 Android 岗位从简历筛选到终面的大部分考察面。不管你是刚学完 Android Studio 环境搭建、能跑通一个增删改查的 App还是已经写了两三年业务代码想更进一步下面这些内容都能直接拿去对照补漏。我不会给你一份必背一百题而是按面试官到底在听什么这个角度把每一块该讲的深度都拆开。1. 先别急着背题Android 面试真正筛的是什么能力1.1 面试官手里那张看不见的评分表绝大多数人准备面试的方式是打开一个题库文档从第一题开始往下刷。这个方式不是没用但效率极低因为它假设了问题和能力是一一对应的。实际上面试官手里通常是一张相对模糊的评分表大致分成四栏基础扎实度、工程判断力、表达与沟通、成长潜力。同一道说说 Handler 机制的题不同的人答出来落点可能完全不同——有人背出了 MessageQueue 和 Looper有人能讲清楚主线程为什么阻塞在 native 层的 epoll 上却不触发 ANR还有人能顺带说出自己在项目里怎么用 IdleHandler 做延迟初始化。这三个答案在评分表上的位置是递增的。我后来跟那位学妹聊她面试中的实际感受她说最有用的一个转变是把我要答对这道题改成我要让面试官相信我能独立负责一个模块。这个转变听起来虚但落地方式很具体每讲一个知识点尽量带上三个东西——它解决什么问题、它内部大致怎么实现、我在真实项目里用它踩过什么坑。前两个靠读第三个只能靠做和复盘。如果你没有足够的项目经历去支撑第三点那就用我读源码时发现的或者我在一个小 demo 里验证过的来替代至少证明你是动手验证过的人而不是复述文档的人。1.2 三类问题的时间配比与准备顺序我把 Android 岗位的面试问题粗分成三类它们对应完全不同的准备方式混在一起准备是最容易浪费时间的。问题类型典型形式考察重点建议投入精力基础原理类Java/Kotlin 语法、Handler、Binder、View 绘制概念是否成体系有没有自相矛盾40%工程实践类性能优化、崩溃排查、架构选型有没有量化意识和取舍能力40%场景与手撕算法题、设计题、现场写代码编码基本功、思维清晰度20%很多人把 80% 的时间砸在第一类上结果被问到你那个启动优化到底省了多少毫秒、怎么测的就哑了。反过来说工程实践类是最能拉开差距的地方因为它很难临时背出来。我的建议顺序是先用一两周把基础原理的骨架搭起来然后立刻转到自己项目里找两三个真实问题深挖最后临考前两周集中刷手撕题保持手感。1.3 我见过的两种典型错误准备方式第一种是只背结论不留推导。比如你背下Android 的 GC 是并发复制收集器面试官追问一句那它和 HotSpot 的分代收集有什么区别为什么要这么设计你就卡住了。结论是可以查到的推导过程才能证明你理解。第二种是过度追求广度。有人会去翻一大堆冷门 API觉得覆盖面广就稳。但面试官通常只在他自己熟悉的领域深挖你把十个方向都讲得浮在表面不如把三四个方向讲到能画图、能写代码、能说出边界条件。我个人的经验是准备二十个能讲五分钟的话题比准备两百个能讲三十秒的话题要有效得多。2. Java 与 Kotlin从能用讲到为什么这么设计2.1 Android 上的运行时和标准 JVM 不是一回事这是被低估的一个话题。你如果只说Java 靠 JVM 跑有垃圾回收那基本等于没说。Android 从 4.4 之后逐步切到 ART运行方式在 AOT 和 JIT 之间做过好几轮调整理解这条演进线很多性能问题就自然解释得通了。最早 Dalvik 是解释执行加 JIT安装快、运行慢所以早期 Android 手机装个 App 要等很久的优化中其实是在做 dexopt。ART 上来之后改成安装时全量 AOT运行快但安装慢、占空间大。再往后引入 profile 引导的混合编译先解释执行把热点方法记录下来设备空闲时后台编译这些热点这样就兼顾了安装速度和运行效率。你如果能把这几个阶段和为什么要这么改讲清楚面试官对你的评价会立刻不一样。GC 也是同理。早期是标记清除加标记整理容易产生碎片和长时间停顿后来换成并发复制的方案把内存分成多个区域并行回收停顿时间明显缩短再后面引入分代思路针对大部分对象朝生夕死这个特点做优化。这背后其实就是一句话移动端的 GC 目标不是吞吐量而是尽可能短的卡顿。你把这句话讲出来比背一堆参数有用。2.2 线程池参数到底怎么算线程池几乎是必问题但多数人停在核心线程数、最大线程数、队列、拒绝策略这四个名词上。面试官真正想听的是你凭什么定这组参数。先说参数含义。任务进来时如果当前线程数小于核心线程数直接开新线程否则丢进阻塞队列队列满了再尝试把线程数扩到最大值还是满了就走拒绝策略。这里面最关键、也最容易出问题的是队列的选择。用无界队列的话最大线程数这个参数基本是废的因为队列永远不