1. 这套笔试题的定位：别被“B卷”两个字骗了
先说一个比较直接的判断：欢聚时代2018校招的Android笔试题B卷，放在当年的环境下属于“基础扎实型”出题思路，和今天很多大厂上来就甩一堆源码分析、算法手撕的风格不太一样。这套卷子的核心意图不是考你写过多少花哨的Demo，而是考你在学习Android的过程中有没有把地基打牢——Java基础、内存与并发、四大组件、Handler与Binder、View绘制、网络与存储、性能优化，基本覆盖了Android开发者日常工作的主干。
如果你现在准备Android校招或实习面试，拿这套题来当复习提纲是挺合适的。因为2018年前后出题人还很老实，题目没有那么多脑筋急转弯，不会拿一个极端冷门API来刁难你，反而更像是在检查你“有没有认真读过源码、有没有真的动手调过Bug”。这一点其实比做十套LeetCode对Android方向的帮助更直接。
我当时做这套卷子的感受是：选择题部分不难，但有几个选项如果不看源码真的会选错；简答题部分考察的是“能不能把原理讲清楚”；最后一道设计题是开放性的，没有标准答案，评审看的是你的思路是否完整。所以这篇博文我打算按卷面结构来复盘，同时把每道题背后的知识点往深挖一层，再把答题时候容易踩的坑点出来。如果你正在准备Android校招，可以直接把这篇文章当成一份复习索引来用。
另外要说明的是，我拿到的回忆版本没有完整保留所有题目原文，所以下文中的题目描述是基于记忆和同类高频考题的还原，涉及到的核心考点和参考答案是完整的，可以放心按这个方向去准备。
2. Java基础与并发考点：这套卷子最喜欢在这里埋坑
2.1 集合框架的选择题陷阱：ArrayList、LinkedList与HashMap
B卷选择题第一梯队一定会出现集合类相关题目。常见考法是：给出几个操作场景，让你选择最合适的集合类型，比如“频繁在列表头部插入元素，应该用ArrayList还是LinkedList”，或者“HashMap在并发环境下会有什么问题”。
先说ArrayList和LinkedList。ArrayList底层是动态数组，查询快，按下标访问是O(1)；但头部插入或删除会触发System.arraycopy整体搬迁，代价是O(n)。LinkedList底层是双向链表，头尾增删是O(1)，但按下标访问需要遍历，是O(n)。所以答案是后者，但这里有个容易忽略的细节：如果你用LinkedList做“按下标插入”，它内部也会先遍历到对应位置再插入，复杂度并非O(1)。很多人在笔试里只记了“链表插入快”，却没说清前提，这种答案会被扣分。
HashMap这题就更值得展开。面试官问“HashMap为什么不是线程安全的”时，要从三个方面答：一是多线程put时可能发生数据覆盖；二是扩容时并发put可能使链表形成环，在JDK 7及以前会导致get死循环；三是size等字段不是原子更新，存在脏读。JDK 8改成了尾插法，环的问题解决了，但数据覆盖和脏读依然存在。所以并发场景首选ConcurrentHashMap，它通过CAS配合synchronized锁桶节点，把锁粒度降到最小。
2.2 线程与锁：Synchronized、volatile和ThreadLocal
关于线程的题目，B卷几乎是必考的。常见格式是：“下列哪个关键字能保证线程安全”“volatile能否替代synchronized”这类选择题或简答题。
volatile这个考点要特别注意。volatile保证可见性和有序性，但不保证原子性。很多人把它和原子性搞混，一提到多线程就想到volatile，这是大忌。这里的标准例子是i++操作：即使变量被volatile修饰，i++这个“读-改-写”三步操作依然不是原子的，多个线程同时执行还是有并发问题。只有对变量的单个读或单个写操作，volatile的可见性才够用，典型场景是状态标志位。
Synchronized则从JDK 6之后引入了偏向锁、轻量级锁、重量级锁的升级过程。笔试如果考到“synchronized做了什么”，不能只回答“加锁”，要说出monitorenter和monitorexit字节码指令、可重入性，以及锁升级的大致流程。能说出“锁消除”“锁粗化”是加分项，说明你真的看过JVM层优化。
ThreadLocal也是一个容易被小看的考点。它并不是为了解决并发访问共享变量的线程安全问题，而是为每个线程维护一份独立的变量副本。重点要理解它的实现结构：每个Thread内部有一个ThreadLocalMap，key是ThreadLocal对象本身（实际是弱引用），value是线程私有数据。所以使用完必须调用remove()，否则在线程池场景下，线程复用会导致上一个任务的数据残留到下一个任务，产生严重Bug。
3. Android 四大组件考点：Activity启动模式与ContentProvider的协议
3.1 Activity启动模式与onNewIntent
四大组件里考得最密集的是Activity。2018年校招笔试题基本绕不开启动模式这道题，而且不仅要你写出standard、singleTop、singleTask、singleInstance四种模式的区别，还要结合具体场景。比如：通知栏点击跳转详情页应该用什么模式？如果详情页已经在栈顶，再次点击通知栏应该走哪个生命周期？
正确答案是singleTop，因为要避免重复创建详情页，而singleTop恰好能在栈顶复用已有实例，并回调onNewIntent。这里有个很关键的细节：复用的时候，旧实例的onNewIntent会先于onResume被调用，所以新数据要在onNewIntent里更新，而不是在onCreate里判断。很多人在实际项目中把逻辑全写在onCreate，导致从通知栏二次进入页面时数据不刷新，就是这个原因。
singleTask和singleInstance的区分也要注意。singleTask是栈内复用，它在启动时会先把位于它之上的其他Activity清掉，再把这个实例调到栈顶，通常用于App主页面或首页。singleInstance则更特殊，它所在的Activity会独占一个任务栈，适合来电页面这类需要全局唯一的场景。笔试里如果给一个“从A启动B再启动A”的启动顺序问题，要能准确判断最终返回栈的排列。
另外值得一提的还有taskAffinity、allowTaskReparenting这些flag。虽然选择题不常考，但一旦考到，很多人会懵。它们本质上是更改Activity与任务栈默认归属关系的机制。taskAffinity用来指定Activity希望归属的任务栈名，默认是包名；allowTaskReparenting用于Activity从A任务栈切到与它affinity一致的任务栈。理解这两个概念，才能真正把握任务栈模型，而不是死记四种模式。
3.2 Service的两种启动方式与生命周期纠缠
Service也是B卷的高频考点。最容易错的是startService和bindService在生命周期上的组合关系：startService启动的Service会一直运行到stopService或stopSelf；bindService启动的Service在最后一个绑定者解绑后，如果之前没有被startService启动过，就会自动销毁；如果既有startService又有bindService，则必须先stopService再unbindService，才能让Service进入onDestroy。
这里有一个经典的追问：onStartCommand的返回值有什么意义？回START_STICKY、START_NOT_STICKY还是START_REDELIVER_INTENT？这个知识点放在2018年可能是加分项，放到现在面试基本必问。START_STICKY表示进程被系统杀死后，系统会重新创建Service并回调onStartCommand，但Intent为null；START_NOT_STICKY则不会重建；START_REDELIVER_INTENT会重建并且重新传递最后一条Intent。比较稳妥的做法是：需要长期后台任务且任务可以被重新执行时用START_REDELIVER_INTENT；普通音乐播放这类场景用START_STICKY或START_NOT_STICKY，要结合实际业务判断。
3.3 ContentProvider与fileprovider路径暴露问题
热词里出现了“content://com.baidu.searchbox.fileprovider”和“content://com.ss.android.uri.key”这类字符串，这正好对应到ContentProvider和FileProvider的考点。2018年Android校招笔试里就有类似的选择题：从Android 7.0开始，App之间传递File Uri会被抛FileUriExposedException，你需要改用FileProvider生成的content://URI。这里的核心机制是FileProvider作为ContentProvider的子类，把本地文件的访问权限通过grantUriPermission临时授权给其他应用。
笔试怎么考？最常见的考法是：file://和content://有什么区别？为什么Android 7.0以后要禁止file://隐式共享？答案要点有三个：
- file://是直接暴露文件路径，不经过授权校验，任何知道路径的应用都可以尝试访问
- content://通过ContentProvider封装，拥有完整的权限控制和URI权限授予机制
- FileProvider.generateUri里会把真实路径映射为cache-path或files-path下的虚拟路径，对客户端隐藏真实目录结构
这个知识点之所以重要，是因为它不仅是笔试考点，更是实际开发中必踩的坑。如果你做过Android 7.0以上的应用分享、调用相机拍照、安装APK等功能，一定遇到过uri权限问题。我当时就因为这个在项目里调试了半天，后来才反应过来是targetSdkVersion升到24以后FileProvider的适配没做。
3.4 BroadcastReceiver的注册方式与限制
广播也是四大组件里容易被忽略的一个，但B卷的选择题偶尔会出。核心考点有两个：静态注册和动态注册的区别，以及Android 8.0对隐式广播的限制。
静态注册是指在AndroidManifest.xml里声明，能接收App未启动时的广播；动态注册需要在代码里registerReceiver，并且必须在onDestroy或onStop里unregisterReceiver，否则会内存泄漏。Android 8.0以后，大部分隐式广播（没有明确指定包名的广播）不能再通过静态注册接收，但系统广播（比如开机完成、网络变化、电量低）例外。这个变化对很多应用是致命打击，所以考题通常考的是：哪些广播可以静态注册？哪些不能？这类题只要记住“云消息推送SDK内部都是用动态注册或显式广播”就能避开坑。
4. 消息机制与Binder原理：Handler、Looper、MessageQueue全链路
4.1 Handler机制的四个关键角色
Handler题目在B卷的简答题里几乎是大题级别的存在。一般考法是：“请描述Handler机制的运行原理”或者“Handler为什么不会导致ANR”。前者是背诵题，后者是理解题。
先理清四个角色：Handler负责发送和处理消息，Looper负责循环取出消息，MessageQueue是消息队列，Message就是载体。核心关键在于Looper.loop()是一个死循环，它不断从MessageQueue中取出Message，然后分发给对应的Handler的dispatchMessage处理。
“Handler为什么不会导致ANR”是一个高频追问。回答要点是：主线程的Looper.loop()死循环正是Android消息驱动的根本，它不是阻塞，而是让主线程随时准备好处理新消息。ANR的本质是事件处理超时，而不是loop存在本身。如果在主线程执行耗时操作，事件得不到及时处理，才会触发ANR。所以不是Handler导致ANR，而是主线程里的耗时任务导致ANR。
4.2 线程切换的核心逻辑与内存泄漏
Handler还有一个必考点就是线程切换。子线程通过handler.post(Runnable)发送消息到主线程去执行，本质上是把消息塞进了主线程的MessageQueue。这里的关键是Handler在哪个线程创建，就绑定哪个线程的Looper。这就是为什么在主线程直接new Handler()能用，在子线程new Handler()会抛RuntimeException——“Can't create handler inside thread that has not called Looper.prepare()”。
很多人会忘记主线程的Looper是ActivityThread里已经通过Looper.prepareMainLooper()初始化好的，所以主线程new Handler不需要手动prepare。这一点如果笔试考到，一定要说清。
Handler导致内存泄漏的问题也是面试高频。非静态内部类Handler默认持有外部Activity的引用，如果MessageQueue里还有未处理的消息，就会导致Activity无法被回收。推荐的解决方案是：使用静态内部类继承Handler，配合WeakReference持有Activity，同时在onDestroy里移除所有消息和回调。
4.3 Binder的机制定位
Binder是Android进程间通信的核心，B卷简答题中有一定概率出现。考法通常是“为什么Android要选择Binder而不是传统IPC”。回答要往三个角度展开：性能、安全、易用性。
性能上，Binder只需要一次内存拷贝，而传统管道、Socket需要两次拷贝。安全上，Binder在内核空间为每个进程分配了UID，可以校验对方身份，而传统IPC没有这种机制。易用性上，Binder把跨进程调用封装得像本地调用一样，开发者只需要定义AIDL接口，不需要关心底层传输细节。
这里我建议准备一个AIDL的小例子，笔试不一定考，但面试时派得上用场。比如定义一个IBookManager接口，里面有addBook和getBookList两个方法，服务端通过Service的onBind返回Binder对象，客户端通过bindService拿到代理对象。能把这个流程讲清楚，说明你真的理解Binder的服务端、客户端、代理和Stub这四个要素。
5. View体系与绘制流程：onDraw不要丢的那几个关键点
5.1 View的测量、布局、绘制三步曲
View体系在B卷里一般占两个题目左右，一个是自定义View的流程，一个是事件分发机制。
MeasureSpec是View测量的关键。它由specMode和specSize组成，三种模式要记牢：UNSPECIFIED表示父容器不对子View施加任何约束，可以随便多大；EXACTLY表示精确模式，对应match_parent和具体数值；AT_MOST表示最多不超过某个值，对应wrap_content。
这里有个经典Bug：自定义View如果直接使用getMeasuredWidth()和getMeasuredHeight()没处理wrap_content，会导致设置wrap_content时表现成match_parent的效果。原因就是默认的onMeasure在AT_MOST模式下没有对wrap_content做处理。解决方案是在onMeasure里给一个默认值，并通过setMeasuredDimension重新设置。
Layout阶段一般不是笔试重点，但你要知道ViewGroup会根据自己的LayoutParams规则来调用每个子View的layout方法，从而确定它们在父容器中的位置。绘制阶段则是走onDraw，这里最容易被问的是：onDraw里能不能做耗时操作？答案是不能，因为它运行在主线程，任何耗时操作都会直接掉帧。
5.2 事件分发机制与滑动冲突
事件分发机制是自定义View题目之后的常规延伸。面试经典问法是：“事件分发机制是怎样的？如何解决滑动冲突？”
需要分清三个方法：dispatchTouchEvent负责分发，onInterceptTouchEvent负责拦截（仅ViewGroup有），onTouchEvent负责消费。事件的传递顺序是Activity -> ViewGroup -> View，一层层往下分发，如果子View不消费，会回溯向上传递给父View。
在此基础上，滑动冲突的解决方案通常是外部拦截法或内部拦截法。外部拦截法就是重写父容器的onInterceptTouchEvent，在ACTION_MOVE中判断是否拦截；内部拦截法是要求子View在ACTION_DOWN时请求父容器不要拦截，然后在ACTION_MOVE需要父容器处理时再调用getParent().requestDisallowInterceptTouchEvent(false)。能够把这两套方案都讲清楚，事件分发这关才算过。
5.3 布局渲染优化相关的热词呼应
热词里出现了“android中协调布局+banner”以及“android动态图标主题”，这其实是布局与视觉效果层面的高阶点。CoordinatorLayout配合AppBarLayout的behavior机制是Material Design中常用的联动方案。Behavior本质上是通过监听依赖View的状态变化来响应联动，比如图片标题栏上滑时收缩、Banner跟随滚动等。笔试如果考到，大概率是选择题形式，问“CoordinatorLayout中AppBarLayout的滚动标志位有哪些”，比如scroll、enterAlways、exitUntilCollapsed、snap。这个不用背太深，理解标志位的组合效果即可。
动态图标主题则涉及代码替换桌面图标、使用Activity-alias切换图标的能力。在Android 12以后还加入了monochrome主题图标的概念。这块作为普通开发可以了解，笔试很少深挖，但面试时如果你能主动提起“主题图标适配”，会显得知识面比较新。
6. 网络协议与数据存储：从HTTP到Room的考点覆盖
6.1 HTTP与HTTPS的报文结构和状态码
网络模块在B卷中几乎必考。最简单的是状态码题：200是成功，301是永久重定向，302是临时重定向，304是未修改走缓存，400是客户端请求错误，401是未认证，403是禁止访问，404是资源不存在，500是服务器内部错误，502是网关错误，503是服务不可用。
笔试如果考到“304 Not Modified”通常会和缓存策略结合起来。服务器通过ETag或Last-Modified判断资源是否变化，如果没有变化就返回304，客户端继续使用本地缓存。这个考点在面试里同样常见，尤其是让你设计一个HTTP缓存策略时，必须说清楚强制缓存和协商缓存的区别。
HTTPS的握手流程也可以准备一下。核心要点是：客户端先发ClientHello，服务端返回ServerHello和证书，客户端验证证书并生成预主密钥，之后通过非对称加密传输预主密钥，双方各自计算出对称会话密钥，后续通信改用对称加密。记住“非对称加密传输密钥，对称加密传输数据”这句话，基本能应付大部分题目。
6.2 JSON解析与网络请求封装思路
网络题里还有一种是给你一段JSON让你分析数据结构，或者问Gson解析时TypeToken的原理。后者更容易成为一个拉分题，因为TypeToken的实现涉及Java泛型擦除。
Gson在解析List 时需要通过TypeToken拿到具体的泛型类型，因为运行时无法直接知道T是什么类型。TypeToken通过反射获取Type接口的泛型参数，从而绕过类型擦除。如果直接用Gson().fromJson(json, List.class)，解析出来的是List edtreemap> 而不是List ，后面用起来会各种坑。这个点笔试里虽然不常直接考，但代码题里暗含的几率不低。
网络请求封装思路则是开放题。从Retrofit + OkHttp + 拦截器的组合，到统一处理错误码、Token刷新、日志打印、缓存策略，每一个环节都能展开。一个比较完整的回答结构是：Retrofit负责接口代理，OkHttp负责底层请求，拦截器链用于添加公共参数和签名，日志拦截器用于调试，缓存拦截器用于网络缓存，然后通过自定义Converter把响应体转成统一的数据模型。这套架构直到今天依然是主流方案。
6.3 数据存储方式的选择与Room
数据存储题在B卷里常以选择题出现：SharedPreferences、File、SQLite、ContentProvider分别适合什么场景？最容易踩坑的是SharedPreferences，它看起来简单，但在跨进程场景下不可靠，而且commit是同步写磁盘，可能阻塞主线程，apply虽然异步但依然不建议高频写入。如果想追求稳定性，可以用DataStore替代SharedPreferences，不过这是近年来才纳入主流面试的。
数据库方面，SQLite是底层，Room是官方推荐的上层封装。Room的三大组件：Entity对应表结构，Dao提供数据操作接口，Database是数据库持有者。Room能在编译期验证SQL语句正确性、支持LiveData和协程、能自动做线程切换。笔试如果面到数据库，答出“为什么用Room而不是裸写SQLite”的时候，可以强调编译期检查和与生命周期组件的集成这两个特色。
7. 性能优化与内存泄漏：选择题里隐藏的实战经验
7.1 内存泄漏的常见场景与排查手段
性能优化是2018年校招笔试的重点方向之一，放到今天只会更重要。B卷在这部分的典型考法是情景题：给你一段代码，问它是否会导致内存泄漏？
高频泄漏场景可以列一个清单：
- 非静态内部类持有外部Activity引用，比如Handler、Thread、AsyncTask
- 匿名内部类Runnable被延迟执行
- 单例模式持有Activity的Context
- 未反注册的BroadcastReceiver
- 未关闭的Cursor、IO流
- 静态集合保存Activity或View
- WebView没有调用destroy
排查手段的回答思路也要准备：先通过Memory Profiler或LeakCanary定位泄漏的对象，再分析引用链，看是谁持有它的引用，然后根据引用链修复。热词里的“android studio 火焰图”就对应到了性能分析方向，火焰图能直观展示CPU时间和函数调用栈的关系，在定位耗时方法时很有效。如果你在面试中提到用过火焰图分析主线程卡顿，是妥妥的加分项。
7.2 ANR的类型与定位策略
ANR也是一个必背考点。三种类型的ANR要清楚：输入事件（按键、触摸）5秒未处理、BroadcastReceiver前台10秒或后台60秒未处理、Service前台20秒或后台200秒未处理。
笔试如果考“如何避免ANR”，基础答案是不要在主线程做耗时操作。但如果能加上“用StrictMode在开发阶段检测主线程磁盘IO和网络访问”，或者“通过ANR日志中的main线程栈定位卡顿点”，这种经验型的回答会明显区别于背课本的答案。
7.3 启动优化与布局优化
启动优化的核心是减少主线程工作量。冷启动过程从Application到Activity的onResume，每一步耗时都要被审视。常见优化手段包括：启动页面不做复杂初始化、延迟初始化第三方SDK、使用启动器框架对任务排序和异步处理、用trace工具查看方法耗时。这些是Android开发者的必修课。
布局优化的要点相对固定：减少嵌套层级、使用ConstraintLayout、避免不必要的measure和layout、用include和merge减少重复布局、ViewStub做延迟加载。笔试如果问到布局卡顿，能够说清“onDraw里不要创建对象、不要做耗时计算，因为会触发GC导致掉帧”这个逻辑，比单纯背优化清单要深刻得多。
7.4 综合题里的最佳实践：用网络热点关键词来串联
我把热词中的“android phonestatelistener”“android 蓝牙”“android ota”“android r8”放到这里一起说，因为这几个点经常在校招笔试的拓展题或面试追问里出现，作为Android开发的知识广度体现。
PhoneStateListener用于监听电话状态变化，包括空闲、响铃、接通，这和通话录音、来电识别类App相关。要注意的是Android 6.0以后需要动态申请READ_PHONE_STATE权限，Android 10以后对电话状态权限限制更严格，这类监听在后台会受到很大约束。
蓝牙权限在Android 12以后也发生了重大变化。BLUETOOTH和BLUETOOTH_ADMIN被拆分成了BLUETOOTH_CONNECT、BLUETOOTH_SCAN、BLUETOOTH_ADVERTISE等细分权限，并且需要配合neverForLocation声明或说明不使用定位信息。很多做IoT和智能硬件开发的同事都在这里踩过坑。校招如果问到你蓝牙开发，能说出这个版本差异，说明你确实关注了最新变化。
OTA升级则是系统级App开发才涉及的领域，通常包括全量包升级和增量包升级两种方式。增量包升级会用到一个差分算法，比如bsdiff/bspatch，把旧版本和新版本的差异生成patch，在设备端合并。这个方向比较垂直，校招笔试不太会深考，但热词里既然出现了“android ota”，你至少要知道它和系统升级、Recovery模式的关系。
R8是ProGuard的替代品，负责代码压缩、资源压缩、混淆和优化。编译期把java字节码优化成更精简的dex代码。笔试如果考到“混淆后如何生成mapping文件”，要能说清mapping文件的作用是在Bugly等崩溃平台上还原堆栈。如果应用没有保留mapping文件并上传，线上崩溃日志会变成a.b.c.d这种无法阅读的状态，排查问题非常痛苦。
7.5 图片加载框架的选择与内存缓存设计
图片加载框架在2018年正是Glide和Fresco大战的时候，笔试常考选择题：Glide和Picasso有什么区别？Glide的优势是什么？重点要答出：Glide默认使用RGB_565格式（现在版本有调整），内存占用更小；Glide与Activity和Fragment生命周期绑定，可以在页面销毁时自动取消加载；Glide的多级缓存包括活动资源、内存缓存、磁盘缓存、网络源。这些点足以应付大多数选择题和简答题。
另外LruCache的原理也是高频题。LruCache内部用LinkedHashMap实现，通过accessOrder=true实现按访问顺序排序，当缓存满时淘汰最久未使用的条目。计算图片内存占用时使用公式“图片宽度 × 图片高度 × 每像素字节数”，其中ARGB_8888每个像素4字节，RGB_565每个像素2字节。这个公式一定要记牢，面试官非常喜欢用这个来追问。
8. 开放设计题：给出你的架构思路，而不是一个结论
8.1 一道典型的“设计一个图片加载库”应如何回答
B卷最后一般有一道开放设计题，常见的有“设计一个图片加载库”“设计一个网络请求框架”“设计一个本地缓存方案”。这类题没有标准答案，但评卷人有一套潜在的评分逻辑：是否考虑到内存、线程、缓存、生命周期、扩展性、边界条件。
以“设计图片加载库”为例，一个完整回答应该包含：
- 加载流程：传入URL，先查内存缓存，再查磁盘缓存，都没有则发起网络请求
- 异步机制：使用线程池或协程管理网络请求，主线程切回通过Handler
- 内存缓存：LruCache，按图片字节数计算
- 磁盘缓存：DiskLruCache，以URL的MD5为文件名
- 生命周期绑定：页面销毁时暂停或取消请求
- 图片压缩：根据ImageView尺寸对Bitmap做采样压缩
- 复用与回收：inBitmap复用内存，避免频繁GC
这套思路今天依然成立，如果你在校招或面试中能把这些点全部答到，基本已经合格。若能加上“Glide里还用了BitmapPool来复用Bitmap内存”“请求去重可以合并相同URL的请求”这类细节，就是加分项。
8.2 如何避免“回答得像背书”
开放题最怕的是只列出结论，没有自己的理解。哪怕答案是对的，也没有区分度。我的经验是：在每一项后面加一句“为什么这样做”的补充说明。比如不说“要加内存缓存”，而是说“要加内存缓存，因为图片解码后的Bitmap对象比较大，从网络重新加载一张图片要经历网络传输、解码、显示三个阶段，而复用内存Bitmap可以避免频繁GC带来的掉帧”。这个“为什么”就是让答案区别于其他人的地方。
8.3 从笔试到面试的延伸准备
笔试题只能考察静态知识，面试才是真正的筛选环节。欢聚时代2018年这套B卷涉及的考点，实际上就是一张“Android面试知识地图”：Java基础与并发、四大组件、Handler与Binder、View体系与事件分发、网络与存储、性能优化与架构设计。拿到这张地图，按章节去复习，是最高效的路径。
面试追问通常比笔试深一个层次。笔试考了startActivity的启动模式，面试就会追问onNewIntent和launchMode叠加多个flag会有什么表现；笔试考了Handler机制，面试就会让你手写一个Handler简化版；笔试考了LruCache，面试就会问你如何实现一个DiskLruCache。所以平时在学习中要多问一个“为什么”，而不是停留在“能跑就行”的层面。
8.4 关于这份试卷的实战复盘总结
回到热词里那些高频搜索词身上：“android 面试题”“android framework”“android ams”“android studio配置问题”——这其实也代表了校招备考者最真实的焦虑：不知道重点在哪，不知道从哪入手，又害怕掉进工具配置的坑里出不来。
我的建议是：先把这套笔试题的知识点逐个过一遍，确保选择题不丢分，简答题能写出50%以上的原理，设计题能搭出完整框架。然后对照我上面说的延伸点，挑自己最薄弱的方向深入复习。Android开发这个领域，知识点永远不可能全部背完，但主干和底层逻辑是有限的，把主干吃透，再往分支延伸，比毫无章法地刷十套题有效得多。
最后再分享一个我后来带新人时发现的现象：很多同学能把Binder原理背得很流利，但让他用AIDL写一个跨进程通信的Demo却无从下手；能把Activity启动模式倒背如流，但让他解释“为什么有时候singleTask启动会回调onNewIntent”又说不清楚。这说明“会背”和“会用”之间还有一道巨大的鸿沟。真正扎实的Android基础，不应该只停留在笔试卷面上，而是要在你看源码、写Demo、调Bug的过程中一点一点沉淀下来。这套B卷只是一个起点，之后的每一次排查和每一次重构，才是你真正成长的时刻。
