经历过一些面试，也面过一些同学。

被面试官问到头皮发麻，也把候选人问得面红耳赤。

曾怨恨问题刁钻刻薄，也曾怀疑提问跑题超纲。

经历过攻守的角色转换后，沉下心，回顾过往，不由得发出感叹。如果要将“面试”作类比的话，我愿意将其比作“相亲”。

之所以这样类比，是因为看似客观的技术面试，其实充斥了各种各样的主观判断。“候选人合不合面试官胃口”可能比“候选人有多优秀”更重要一点。

世界这么大，Android 知识体系这么庞杂，我也时不时地怀疑自己，特别是当 pass 一个候选人之后，这种情感愈发强烈。“是不是自己的知识有局限性？”、“我认为关键的问题，真的这么关键吗？”

带着这样的怀疑，我对自己的面试偏好做了一下总结，在此抛砖引玉，欢迎各路大神指点迷津。

ps：本篇仅关注 Android 应用层开发相关面试。

八股文式问题

1. Activity 有几种 launch mode？每一种有什么特点？
2. Service 有几种类型？各有什么应用场景？
3. 广播有几种注册方式？有什么区别？
4. Activity 有哪些生命周期回调？
5. Kotlin 中的扩展函数是什么？
6. JVM 内存模型是怎么样的？
7. GC 回收算法？
8. Java 中有几种引用类型？

这类问题的特点是“只需百度即可立马获得答案”。候选人若做过充足的准备，刷过题，就可以倒背如流。但这些问题也是有价值的，可以快速判断候选人是否了解 Android 的基本概念。

上面的第 6，7 问，我不太喜欢问。原因是“掌握了这个问题对应用层开发能起到什么可见的好处？”

计算机的复杂度高，分层是常用的降低复杂度的方法，层与层之间形成了壁垒，也提高了层内的效率。将单独一层的复杂度吃透，都可能要花去毕生的精力。并不是否定深挖底层的价值，学有余力当然可以打通好几层，但作为 Android 应用层的面试，重点还是要关注应用层的技术细节。（个人愚见，欢迎拍砖~）

但如果面试中全都是八股文式问题，则不太公平，太过偏袒死记硬背者，也可能因此 pass 掉能力很强，但基本问题准备不太充分的候选人。

原理性问题

这类问题旨在考察候选人的技术深度，在会用的技术上，知道为什么用它，及其背后的实现原理。比如：

1. Android 消息机制是怎么实现的？
2. Android 触摸事件如何传递？
3. Android 视图是怎么被绘制出来的？
4. Android 如何在不同组件间通信？（跨进程，跨线程）
5. Activity 启动流程？
6. AMS、PMS、WMS 创建过程？
7. 手写消息入 MessageQueue 的算法。
8. RecyclerView 缓存机制？

原理性问题也可以被百度出来，但可能得多看几篇博客再消化一番，最后用自己的语言组织一下，才能在面试中对答如流。

这类问题不同于八股文的地方不仅在于考察了技术深度，还顺带便考察了理解分析能力和总结表达能力。把原理性的东西用简单精炼的语言表达出来并让人听懂也是一种能力。

我不太喜欢问 5、6 这样的问题，还是之前提到的那个原因，即“回答出这样的问题对应用层开发能起到什么可见的好处？”。若是 Android 系统开发工程的面试，倒是很有必要问。

第 7 问将原理性和算法结合，不是让默写算法，而是在考察理解原理的基础上的算法实现能力。若死记硬背原理，通常都写不出。

项目经历类问题

这类问题旨在考察候选人项目经历是否真实，技术栈情况。也可就某一个使用过的技术栈追问背后的原理。

这类问题对面试官要求最高，若是没有一定的技术广度和深度，很难就候选人的技术栈问出好问题。

场景类问题

场景类问题是指设计一个“待解决的问题”，让候选人当场解决。

所有前面的问题，都可以提前准备，若准备足够充分，全部拿下不是问题。而场景题是无法提前准备的。

1. 如图所示：按住View，移到 View 边界外后松手。这个过程中，哪些触摸事件会被传递，它们是如何传递的？

2. 要做一个 1MB * 10 的帧动画，有什么办法优化内存？
3. 如何防止搜索框过度频繁地发起请求？
4. 如何实现弹幕？
5. 如何设计直播间礼物队列？
6. 设计图片异步加载组件需要注意哪些方面？

第 1 问将原理性问题场景化了，对死记硬背不友好。

这些问题都是应用层开发过程中可能遇到的技术问题，场景类问题是开放性的，没有唯一解，考察候选人的思路、技术积累及综合运用能力，甚至是抗压能力。

但场景类问题也有致命的缺点，受到面试官知识及经验的限制，面试官见过多少世面，就能问出多少问题。若面试官经验恰好和候选人有交集则两情相悦，不然则可能话不投机。所以这类问题也不是公平的，就好像相亲，甲之蜜糖乙之砒霜是有可能出现的。

需求拆解估时问题

即把一个真真切切的迭代需求给到面试者，要求把业务需求拆解成技术步骤，然后为每个步骤精确估时。

不要小看“需求拆解”，首先得深入领会需求，能否把产品想表达的理解到位？，能否意会产品想表达而为表达之意？在实际迭代过程中，产品和研发对需求理解的不一致是屡见不鲜的，候选人会不会和产品成为好朋友？

在深入领会需求的基础上，能否将业务故事拆解成技术步骤？考察候选人掌握的技术栈及其综合运用能力，技术选型及实现方案是否合理？是否将扩展性或性能优化考虑在内？

“估时”可以看出候选人对技术实现细节的熟练程度，假设“用 ViewPager + Fragment 实现分页框架”的估时是 1 天，那说明虽然了解改用什么技术，但并未实践过。但此时的估时是理想化的，因为没有将应用的代码现状考虑在内。

这些问题也是候选者入职之后，在每次迭代时真真切切遇到的问题。“拆解合理，估时准确”不是一件容易的事情，即需要深入领会需求、有丰富的技术栈实战经验，还需要对现有代码框架了然于胸，这是一个成熟研发的标志。

没有找到比需求拆解估时问题更务实的面试题了。若相亲的第一感觉不可靠，那就试着约会一次。

对于一些基础知识点和一些原理性的知识点一定要掌握好，不能含糊，面试时面试官肯定是由浅入深的问，来测试你的技术水平。最后我给大家整理了一些往年的Android 面试题，想参考学习一下的可以点击下方小卡片进行访问查阅。