共计 2493 个字符，预计需要花费 7 分钟才能阅读完成。
经验过一些面试，也面过一些同学。
被面试官问到头皮发麻，也把候选人问得面红耳赤。
曾恼恨问题刁钻刻薄，也曾狐疑发问跑题超纲。
经验过攻守的角色转换后，沉下心，回顾过往，不由得收回感叹。如果要将“面试”作类比的话，我违心将其比作“相亲”。
之所以这样类比，是因为看似主观的技术面试，其实充斥了各种各样的主观判断。“候选人合不合面试官胃口”可能比“候选人有多优良”更重要一点。
世界这么大，Android 常识体系这么庞杂，我也时不时地狐疑本人，特地是当 pass 一个候选人之后，这种情感愈发强烈。“是不是本人的常识有局限性？”、“我认为要害的问题，真的这么要害吗？”
带着这样的狐疑，我对本人的面试偏好做了一下总结，在此抛砖引玉，欢送各路大神指点迷津。
ps：本篇仅关注 Android 应用层开发相干面试。
八股文式问题
- Activity 有几种 launch mode？每一种有什么特点？
- Service 有几种类型？各有什么利用场景？
- 播送有几种注册形式？有什么区别？
- Activity 有哪些生命周期回调？
- Kotlin 中的扩大函数是什么？
- JVM 内存模型是怎么样的？
- GC 回收算法？
- Java 中有几种援用类型？
这类问题的特点是“只需百度即可立马取得答案”。候选人若做过短缺的筹备，刷过题，就能够滚瓜烂熟。但这些问题也是有价值的，能够疾速判断候选人是否理解 Android 的基本概念。
下面的第 6，7 问，我不太喜爱问。起因是“把握了这个问题对应用层开发能起到什么可见的益处？”
计算机的复杂度高，分层是罕用的升高复杂度的办法，层与层之间造成了壁垒，也进步了层内的效率。将独自一层的复杂度吃透，都可能要花去毕生的精力。并不是否定深挖底层的价值，学有余力当然能够买通好几层，但作为 Android 应用层的面试，重点还是要关注应用层的技术细节。（集体愚见，欢送拍砖~）
但如果面试中全都是八股文式问题，则不太偏心，太过偏袒死记硬背者，也可能因而 pass 掉能力很强，但根本问题筹备不太充沛的候选人。
原理性问题
这类问题旨在考查候选人的技术深度，在会用的技术上，晓得为什么用它，及其背地的实现原理。比方：
- Android 音讯机制是怎么实现的？
- Android 触摸事件如何传递？
- Android 视图是怎么被绘制进去的？
- Android 如何在不同组件间通信？（跨过程，跨线程）
- Activity 启动流程？
- AMS、PMS、WMS 创立过程？
- 手写音讯入 MessageQueue 的算法。
- RecyclerView 缓存机制？
原理性问题也能够被百度进去，但可能得多看几篇博客再消化一番，最初用本人的语言组织一下，能力在面试中对答如流。
这类问题不同于八股文的中央不仅在于考查了技术深度，还顺带便考查了了解剖析能力和总结表达能力 。把原理性的货色用简略精炼的语言表达进去并让人听懂也是一种能力。
我不太喜爱问 5、6 这样的问题，还是之前提到的那个起因，即“答复出这样的问题对应用层开发能起到什么可见的益处？”。若是 Android 零碎开发工程的面试，倒是很有必要问。
第 7 问将原理性和算法联合，不是让默写算法，而是在考查了解原理的根底上的算法实现能力。若死记硬背原理，通常都写不出。
我的项目经验类问题
这类问题旨在考查候选人我的项目经验是否实在，技术栈状况。也可就某一个应用过的技术栈诘问背地的原理。
这类问题对面试官要求最高，若是没有肯定的技术广度和深度，很难就候选人的技术栈问出好问题。
场景类问题
场景类问题是指设计一个“待解决的问题”，让候选人当场解决。
所有后面的问题，都能够提前准备，若筹备足够充沛，全副拿下不是问题。而场景题是无奈提前准备的。
- 如图所示：按住 View，移到 View 边界外后松手。这个过程中，哪些触摸事件会被传递，它们是如何传递的？
- 要做一个 1MB * 10 的帧动画，有什么方法优化内存？
- 如何避免搜寻框适度频繁地发动申请？
- 如何实现弹幕？
- 如何设计直播间礼物队列？
- 设计图片异步加载组件须要留神哪些方面？
第 1 问将原理性问题场景化了，对死记硬背不敌对。
这些问题都是应用层开发过程中可能遇到的技术问题， 场景类问题是开放性的，没有惟一解，考查候选人的思路、技术积攒及综合使用能力，甚至是抗压能力。
但场景类问题也有致命的毛病，受到面试官常识及教训的限度，面试官见过多少世面，就能问出多少问题。若面试官教训恰好和候选人有交加则两情相悦，不然则可能话不投机。所以这类问题也不是偏心的，就如同相亲，甲之蜜糖乙之砒霜是有可能呈现的。
需要拆解估时问题
即把一个真真切切的迭代需要给到面试者，要求把业务需要拆解成技术步骤，而后为每个步骤准确估时。
不要小看“需要拆解”，首先得深刻体会需要，是否把产品想表白的了解到位？，是否意会产品想表白而为表白之意？在理论迭代过程中，产品和研发对需要了解的不统一是不足为奇的，候选人会不会和产品成为好敌人？
在深刻体会需要的根底上，是否将业务故事拆解成技术步骤？考查候选人把握的技术栈及其综合使用能力，技术选型及实现计划是否正当？是否将扩展性或性能优化思考在内？
“估时”能够看出候选人对技术实现细节的熟练程度，假如“用 ViewPager + Fragment 实现分页框架”的估时是 1 天，那阐明尽管理解改用什么技术，但并未实际过。但此时的估时是理想化的，因为没有将利用的代码现状思考在内。
这些问题也是候选者入职之后，在每次迭代时真真切切遇到的问题。“拆解正当，估时精确”不是一件容易的事件，即须要深刻体会需要、有丰盛的技术栈实战经验，还须要对现有代码框架了然于胸，这是一个成熟研发的标记。
没有找到比需要拆解估时问题更求实的面试题了。若相亲的第一感觉不牢靠，那就试着约会一次。
总结
我对面试的偏好是按列举程序递进的，但程度无限，教训局限，对 Android 应用层的面试也只能停留在这个阶段。还望大神点拨~
视频：
资深架构师带你逐题详解 Android 大厂精选高频面试题
Android 程序员备战 2022FrameWork 必问全套教程
BAT 一线大厂高频面试题具体解析
Android 源码流程篇：Glide 图片框架原理解析及面试题解析
原文：https://juejin.cn/post/702350…
