小红书2020校招Android笔试题二卷考点深度拆解

最近帮一个学弟整理校招复习资料，翻出了当年小红书2020校招Android方向笔试题卷二，这份卷子覆盖面很扎实，既有Java基础，又有Android系统机制，还有框架源码和开放题，可以说把校招的高频考点一网打尽了。虽然试卷叫“卷二”，但题目本身的含金量并不低，很多知识点直到现在依然是面试官喜欢追问的方向，非常值得认真做一遍。

这篇文章我就以这套题为主线，把每类题目的考点、答题思路、容易忽略的细节全部拆开聊一遍。不管你现在是在准备校招，还是已经工作一段时间想查漏补缺，都可以把这份复盘当作一份线索图，顺着它去梳理自己的知识体系。

1. 卷面全景：2020年校招Android笔试题二卷到底考什么

1.1 题型分布与分值逻辑

先看整体结构。这份卷子的题型大致分为四类：选择题、简答题、代码题和开放题。从我接触到的回忆版来看，题目数量不算特别多，但单题分值高，尤其是简答题和代码题，基本决定了你能不能拿到面试机会。

我根据自己的记忆和当时其他同学反馈的版本，整理了一个大致的题型分布表：

这个分值分布透露了一个重要信息：校招笔试不是单纯考你“背了多少概念”，而是看你能不能把原理讲清楚、把代码写对、把方案落地。尤其是简答题和代码题，占了大头，纯靠刷选择题库很难拿高分。

1.2 考点地图：从Java基础到框架源码的高频区域

把整张卷子的考点摊开看，大概是四个梯度，每个梯度的复习优先级和投入产出比都不一样：

第一梯度是Java基础，主要包括JVM内存区域、垃圾回收、集合源码、并发编程。这一块的考查方式以选择题和简答题为主，难度中等，但出现频率极高，几乎可以说是送分题，前提是你真的理解而不是死记。

第二梯度是Android系统机制，重点集中在Handler消息机制、Activity启动模式、Service生命周期、BroadcastReceiver和ContentProvider这类四大组件相关的题目。这一块是区分度最大的区域，基础好的同学能答得比较完整，基础不牢的同学会卡在“底层原理”层面。

第三梯度是UI与性能优化，包括自定义View的测量流程、事件分发机制、内存泄漏、卡顿优化、ANR产生原因等。这个方向的技术栈和小红书这类内容型App的实际业务贴合度很高——图片列表、瀑布流、大图加载，都是高频使用场景。

第四梯度是三方框架源码和开放题，比如Glide的缓存机制、OkHttp的拦截器链、EventBus的原理，以及“如何优化冷启动速度”这类方案题。这部分能看出一个人到底有没有真正读过源码、有没有项目经验，也是最容易拉开分数的地方。

2. 基础题拆解：Java与Android底层逻辑

2.1 JVM内存划分与GC回收题

这套卷子的选择题里，有一类高频题目是“关于JVM内存区域，下列说法正确的是”，选项通常会混入“方法区是堆的一部分”“栈内存是线程共享的”“Java堆可以细分为新生代和老年代”“程序计数器可能抛出OutOfMemoryError”这类说法，稍微对概念模糊就会选错。

这道题背后的考察点其实很清晰：校招生刚入职，公司不会指望你马上写业务代码，但希望你具备排查线上OOM问题的能力，而这一切的基础就是理解JVM内存模型。

答题时要抓住几点：

• 程序计数器是线程私有的，且是唯一不会抛出OutOfMemoryError的区域。
• Java虚拟机栈也是线程私有的，方法执行时创建的栈帧在这里，栈深度不够时抛出StackOverflowError，动态扩展时可能抛出OutOfMemoryError。
• Java堆是线程共享的，对象实例和数组在这里分配，也是GC管理的主要区域，可以细分为新生代（Eden、From Survivor、To Survivor）和老年代。
• 方法区在JDK 8之后被元空间取代，不再是JVM堆的一部分，存放类元信息、常量、静态变量等。

关于GC回收，题目会让判断“可达性分析算法中，可以作为GC Roots的对象有哪些”。常见的GC Roots包括：虚拟机栈中引用的对象、方法区中静态属性引用的对象、方法区中常量引用的对象、JNI中引用的对象。很多人只知道堆和栈，忽略方法区里的静态引用，这一题的区分度就在这里。

答题的时候不能只给概念，最好补充一句自己的理解。比如我会加上：GC Roots本质上是“当前肯定存活的对象集合”，垃圾回收器从这些根出发做可达性分析，扫不到的对象就可以回收。这比干巴巴背定义要生动得多。

2.2 并发编程与集合源码题

卷二里有一类代码题大纲外的隐藏考点：synchronized和volatile的区别。它可能以选择题出现，也可能在简答题里让你结合单例模式说明volatile的必要性。

这两个关键字的区别是校招高频题，标准答法是这样几条：

• volatile保证可见性和有序性，但不保证原子性；synchronized可以保证原子性、可见性和有序性。
• volatile只能修饰变量，synchronized可以修饰方法和代码块。
• volatile不会阻塞线程，synchronized会导致线程阻塞和上下文切换。
• volatile本质是告诉JVM这个变量在所有线程的缓存中是不安全的，每次使用都要到主内存读取；synchronized是通过锁机制让多个线程互斥访问共享资源。

还需要补充一点：volatile还可以禁止指令重排序，这在单例双重检查锁中非常关键。我见过很多候选人在这一步翻车，他们知道DCL单例要加volatile，但说不清为什么。原因是：instance = new Singleton()不是一个原子操作，它会经历“分配内存、初始化对象、把引用指向内存”三个步骤，如果指令重排序导致引用先指向了未初始化的内存，另一个线程就可能拿到一个半初始化的对象，volatile就是为了禁止这种重排序。

集合源码里，HashMap是必考项。2020年面试时的标准答案应该是：JDK 7的HashMap使用数组加链表，JDK 8之后改成了数组加链表加红黑树；当链表长度超过8且数组长度大于等于64时，链表会转成红黑树；扩容时JDK 7是头插法，可能产生循环链表，JDK 8改成了尾插法。

这里我建议答题时多说一层：HashMap为什么线程不安全。因为多线程同时put，可能触发数据覆盖；多线程同时扩容，可能形成环形链表，导致死循环。实际业务中很少直接用HashMap做并发容器，一般用ConcurrentHashMap，它的核心优化是分段锁或CAS加synchronized，JDK 8里锁的粒度已经细化到了桶级别。

3. Android高频考点逐题分析

3.1 Handler消息机制：为什么这道题是“必考题”

在所有Android校招面试题里，Handler绝对是出场率最高的一道，没有之一。这份卷二也毫不意外地出了一道简答题：请描述Handler消息机制的工作原理，并说明Handler.post和View.post有什么区别。

这道题乍看简单，但想拿高分，关键在于从“使用层”深入到“原理层”。基本回答要覆盖五个角色：

Looper负责消息循环，每个线程只能有一个Looper，通过Looper.prepare创建，通过Looper.loop启动循环，从消息队列中不断取出消息交给Handler处理。

MessageQueue是消息队列，内部用单链表数据结构维护消息，按时间先后排序。它的enqueueMessage方法和next方法配合实现消息的插入和取出。

Message是消息载体，创建时尽量用Message.obtain来复用对象，避免频繁创建导致内存抖动。

Handler是消息的发送者和处理者，发送消息时调用sendMessage或post，最终都会进入enqueueMessage，把Message放入MessageQueue，然后再由Looper取出来回调handleMessage。

ThreadLocal用于保证每个线程都有自己的Looper实例，Looper.myLooper就是通过ThreadLocal获取当前线程绑定的Looper。

除了链条本身，面试官还喜欢追问：主线程的Looper是怎么创建的。答案是：应用启动时在ActivityThread的main方法里调用Looper.prepareMainLooper和Looper.loop，所以主线程不需要手动创建Looper。如果让你在子线程创建Handler，就必须先调用Looper.prepare，否则会抛“Can't create handler inside thread that has not called Looper.prepare”的异常。

追问再深一点：MessageQueue没有消息时，主线程会卡住吗？不会，因为next方法会调用nativePollOnce进入阻塞状态，此时主线程不会消耗CPU；当有新消息入队时，通过nativeWake唤醒。底层机制是通过epoll监听事件，存在没有消息就进入休眠的机制，这也是Android能实现高性能消息调度的核心原因。

进阶部分还可以提到同步屏障、IdleHandler、Handler.post的延迟任务准时性问题。尤其是同步屏障，在系统源码里用得很多，比如UI绘制消息优先级高于普通消息，就是通过同步屏障实现的。这一块如果答出来，基本就是加分项了。

至于Handler.post和View.post的区别，核心在“View.post会判断当前是否在主线程”：如果当前是主线程，直接执行；如果不在主线程，会通过内部Handler把任务post到主线程，并且保证在View被attach到窗口时执行。它的一个隐藏特性是，可以在onCreate里通过View.post拿到View的宽高，因为此时消息已经在布局流程之后执行了。

3.2 Activity启动模式与任务栈：两种常考变形题

Activity的启动模式是简答题里的另一道常客。这道题的常规答法是把四种模式背一遍：

• standard：标准模式，每次启动都会创建新的Activity实例，压入启动者的任务栈。
• singleTop：栈顶复用，如果Activity已经在栈顶，不会创建新实例，会回调onNewIntent。
• singleTask：栈内复用，如果栈中已存在该Activity实例，会把其上面的Activity全部出栈，并回调onNewIntent。
• singleInstance：单实例模式，Activity所在的任务栈只允许存在这一个Activity，常用于来电界面等系统级页面。

光背定义还不够，我建议每答一种模式就补一个使用场景，这样答案会丰满很多：

• singleTop适合接收推送通知跳转的页面，防止多次点击产生重复页面。
• singleTask适合App的主页或WebView容器页面，保证只存在一个实例。
• singleInstance适合需要与主界面完全独立的页面，比如来电、闹钟。

这道题还有一个常见变形：A启动B，B的launchMode是singleTask，那么A和B各在哪个任务栈？这个问题比较绕，答案取决于是否设置了taskAffinity。如果B设置了taskAffinity为其他任务栈名称，那么系统会先查找对应任务栈是否存在，存在则复用它，不存在则创建新栈；如果没有设置taskAffinity，默认使用包名任务栈，可能直接复用当前栈。很多候选人在这里卡住，因为只背了四种模式，没有理解taskAffinity和任务栈的关系。

我自己的答题思路是先讲清楚“任务栈”是什么，再讲四种模式，最后补充onNewIntent、taskAffinity、Intent的FLAG_ACTIVITY_NEW_TASK和FLAG_ACTIVITY_CLEAR_TOP这几个相关的知识点。这样既有层次，又能表现你确实理解了这个机制，而不是背了一堆名词。

3.3 自定义View测量与事件分发：一道题串起两大知识块

自定义View的题目几乎在校招笔试里不会缺席。这套卷子里的考法是给一个场景：让你自定义一个类似小红书信息流图片比例的View，要求宽高比固定为3:4，手写onMeasure的关键代码。

这道题表面考代码，实际上考的是你有没有真正理解MeasureSpec。MeasureSpec是测量规格，由size和mode组成，mode有三种：

• EXACTLY：父View给定了精确尺寸，对应match_parent和精确dp，此时View的测量结果就是MeasureSpec的size。
• AT_MOST：父View提供了最大尺寸，对应wrap_content，子View需要自己根据内容计算期望尺寸，但不能超过这个最大值。
• UNSPECIFIED：父View没有限制，子View想多大就多大，一般出现在ScrollView、RecyclerView的测量流程中。

要写固定宽高比的View，核心就是在onMeasure里修改测量结果：当宽度确定后，高度根据宽度的3/4重新计算，然后调用setMeasuredDimension设置最终测量尺寸。代码大致是这样：

@Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { int widthSize = MeasureSpec.getSize(widthMeasureSpec); int widthMode = MeasureSpec.getMode(widthMeasureSpec); int heightSize = MeasureSpec.getSize(heightMeasureSpec); int heightMode = MeasureSpec.getMode(heightMeasureSpec); if (widthMode == MeasureSpec.EXACTLY) { // 父View已经给出了精确宽度，高度按比例计算 int height = (int) (widthSize * 3f / 4f); setMeasuredDimension(widthSize, height); } else if (heightMode == MeasureSpec.EXACTLY) { // 父View给出了精确高度，宽度按比例计算 int width = (int) (heightSize * 4f / 3f); setMeasuredDimension(width, heightSize); } else { super.onMeasure(widthMeasureSpec, heightMeasureSpec); } }

一个容易忽略的坑是：如果宽高都设置了wrap_content，mode是AT_MOST，此时不能直接按widthMode或heightMode的EXACTLY分支处理，否则测量结果就是父容器的最大尺寸，View会变形。我一般会加一个默认尺寸兜底，再按比例计算。

事件分发题目则完全不需要写代码，更多是让你描述事件流的传递机制。标准答法是三大方法加一条主线：

• dispatchTouchEvent负责分发，是事件处理的入口。
• onInterceptTouchEvent只存在于ViewGroup，负责拦截，返回true表示拦截。
• onTouchEvent负责处理，返回true表示消费事件。

事件从Activity的dispatchTouchEvent开始，依次向下传递给ViewGroup的dispatchTouchEvent、View的dispatchTouchEvent，这就是“自上而下”的分发阶段；如果没有任何View消费事件，事件会沿原路“自下而上”返回，最终由Activity处理。点击事件的传递顺序本质是：Activity -> Window -> ViewGroup -> View，处理顺序反过来：View -> ViewGroup -> Window -> Activity。

另一个高频追问是：如何解决滑动冲突。常见的场景是：垂直滑动的ScrollView里嵌套了一个水平滑动的RecyclerView，或者一个ViewPager里嵌套了横向ListView。解决思路有外部拦截法和内部拦截法，我推荐先掌握外部拦截法：在父View的onInterceptTouchEvent中，通过“移动方向来判断是否拦截”：

• 如果父View是垂直滚动，子View是水平滚动，那么当水平位移大于垂直位移时，父View不拦截，把事件交给子View；反之父View拦截。
• 判断位移时注意使用Math.abs计算绝对值，不要直接用坐标差，否则方向判断会出错。

答题时如果能把下面这句话带上，会显得很有经验：不要在onTouchEvent里处理滑动冲突，真正的拦截决策点应该放在onInterceptTouchEvent，因为子View有机会通过requestDisallowInterceptTouchEvent在分发前阻止父View拦截。

4. 代码题与开放题的答题思路

4.1 单例模式代码题：手写之外还要答什么

卷二里有一道几乎所有Android校招都会出现的代码题：手写单例模式。这道题表面上是送分题，但很多同学只写了懒汉式，而面试官真正想看到的是你掌握了哪几种写法、能不能说清每种写法的优缺点。

我当时在答题时写的是双重检查锁，这也是网上最推荐的一种。代码大概这样：

public class Singleton { private static volatile Singleton instance; private Singleton() {} public static Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; } }

除了代码本身，还要解释三个细节：

• 为什么要加volatile：防止指令重排序导致拿到半初始化对象。
• 为什么要双重判断：外层判断避免每次都进入同步代码块，提升性能；内层判断保证实例只创建一次。
• 为什么锁Singleton.class：静态方法中不能用this锁，所以要用类的Class对象当锁。

如果面试官继续追问“单例怎么防止反序列化破坏”，可以补充枚举单例。枚举单例是Effective Java里推荐的写法，它天然支持序列化，而且是线程安全的：

public enum SingletonEnum { INSTANCE; public void doSomething() {} }

这种写法在Android项目里其实很少用，因为枚举在旧版本上会增加包体积，但在笔试里写出来能展示你对不同方案的理解深度。如果怕枚举有争议，也可以提静态内部类单例，它是利用类加载机制保证线程安全，同时实现了懒加载：

public class SingletonHolder { private SingletonHolder() {} private static class Holder { private static final SingletonHolder instance = new SingletonHolder(); } public static SingletonHolder getInstance() { return Holder.instance; } }

关于静态内部类，有一个容易出错的理解：它并不是“在getInstance时才创建实例”，而是在“第一次访问Holder类时”才触发类初始化过程，所以能保证懒加载且线程安全。这一点答题时可以主动讲清楚，面试官很吃这种细节。

4.2 启动优化开放题：从“背答案”到“讲方案”

开放题是这套卷子比较有区分度的地方。2020年的题目问法是：你负责的App冷启动速度偏慢，请给出定位方法和优化方案。这道题没有标准答案，但答得好不好，一眼就能看出你有没有真正做过性能优化。

我建议把答案分成三步：定位、优化、验证。

定位部分要讲清楚冷启动流程。冷启动指的是进程不存在，系统从零开始创建进程并启动App的过程。时间消耗主要包括：Application的attachBaseContext和onCreate、ContentProvider的初始化、Activity的onCreate和onResume、首帧绘制。定位时可以分阶段打点：用adb命令看一下启动时间，再用Android Studio自带的Profiler或自定义的埋点统计每个阶段的耗时，找到瓶颈到底在Application、首屏Activity还是竞品SDK。

优化部分可以分几个方向：主线程做了什么耗时任务、有没有不必要的SDK初始化、有没有重复的View层级。常用的手段有：把不需要立即执行的初始化任务放到子线程、延迟到空闲时再执行、通过启动器框架来实现异步化和依赖管理、使用启动红黑树或者启动器拓扑排序来控制任务顺序。另外一个很容易忽略的点是：SharedPreferences的初始化尽量放到主线程懒加载，避免首次读取时阻塞。

验证部分必须带上数据意识，不要说“感觉快了很多”，而是要给出优化前后具体的启动时间对比。我用adb命令举例：

adb shell am start -W -n com.example.app/.MainActivity

这个命令会输出TotalTime和WaitTime，可以用来量化冷启动耗时。优化前可能是1200ms，优化后可能是780ms，这个数字比任何空泛的描述都有说服力。

这道题的加分项是提醒模块化按需加载和启动器方案。比如常见思路是：通过Jetpack Startup库或者自研的启动框架，把任务分为“必须主线程同步”“可以主线程异步”“必须子线程”三种，并且支持任务之间的等待关系。如果你在笔试里能把这些方案说清楚，同时强调不能为了速度牺牲稳定性，那这道题基本稳了。

5. 备考策略与时间分配

5.1 针对这套真题的复习节奏建议

如果你现在距离校招笔试还有两到三周，我的建议是不要眉毛胡子一把抓，而是要围绕类似这套题的高频考点，做三遍式复习。

第一遍用一周时间，把基础概念全部过一遍：JVM内存模型、Java集合、并发、Android四大组件、Handler、自定义View、事件分发。这个阶段不需要刷太多题，重点是建立完整的知识地图，知道自己哪里薄弱。

第二遍用一周时间，专题突破。把每类题目的“为什么”挖透，尤其是Handler、启动模式、事件分发这三块。方法很简单：对着题目，不看资料，用给自己的话把答案讲出来，能连续讲满三分钟不出错，基本就过关了；如果卡壳了，说明这个点还没真正掌握。

第三遍用剩下时间，全真模拟。找一套完整的真题，按考试时间计时做一遍，重点练手写代码的规范性和答题的速度。代码题一定要手写在纸上或白板上，不要在IDE里敲，因为笔试往往不允许用编译器提示，平时用IDE写代码习惯了，真上手写很容易漏掉import、漏掉分号。

我还整理了一张优先级表，给参考：

5.2 面试官视角：什么样的答案能拿高分

我在几次模拟评审里发现，候选人的答案可以分为三个档次，分差的来源不是知识点本身，而是组织方式。

低分答案的特点是：概念堆砌但缺乏逻辑。比如问“请解释Handler机制”，回答是“Looper是一个消息循环，MessageQueue是消息队列，Handler用来发送和处理消息”，每个名词都对，但每个名词之间没有建立联系，面试官无法判断你是真的理解了，还是背了一堆术语。

中等答案的特点是：能完整描述主链路，但缺少边界条件和异常情况。比如Handler机制，能说到Looper-MessageQueue-Handler的关系，但没有提到ThreadLocal、epoll机制，没有回答“主线程为什么不会因消息队列为空而退出”。

高分答案的特点是：结论先行、结构清晰、有边界条件、有使用场景。我的答题套路是四句话：

• 先给出结论：Handler的核心是“通过消息队列实现线程间通信”，主线程维护一个消息循环，子线程通过Handler向主线程发消息，主线程在loop中取出消息并处理。
• 再展开细节：按Looper、MessageQueue、Message、Handler四个角色逐一说明，每个角色一句话功能加一句话实现原理。
• 再补边界：说明“一个线程只能有一个Looper”、MessageQueue没有消息时通过nativePollOnce阻塞、postDelayed消息不是定时发送而是到时间才取出。
• 最后延展场景：实际项目中可以用Handler做子线程切换到主线程更新UI，也可以用HandlerThread做串行任务队列。

这种答题方式既保证了知识点的完整度，又让面试官很容易跟着你的思路走，不会觉得你在背课文。

6. 常见刷题误区与复盘技巧

6.1 三个高频踩坑点

第一，只背概念不追源码。很多同学能说出来“Handler是线程间通信机制”，但你问他ContextImpl和Activity是什么时候关联的，他就答不上来。校招笔试越来越看重源码理解，尤其是Handler、ActivityThread、View这些核心类。我的建议是：不要求全读源码，但至少要把主流程的关键方法看一遍，比如ActivityThread的main方法、ActivityThread的handleLaunchActivity、Handler的enqueueMessage。

第二，只看答案不做题。真题的数量本身不多，很多同学习惯一边看答案一边点头，感觉自己都会了，等到合上文档再写，才发现自己连单例模式的volatile都忘了写。这个方法我强烈不推荐。做题最大的价值在于暴露你“以为自己懂但实际不懂”的地方，不要浪费这个发现问题的机会。

第三，忽略手写代码的规范性。校招笔试的手写代码题，不要求你写出能一次运行通过的无瑕疵代码，但基本规范还是要守住：类名要首字母大写，方法名要驼峰，变量名要有意义。我用一个常见问题举例：写单例模式时，有人把方法名写成getinstance，把静态字段写成INSTANCE，这类细节都容易被扣分。平时练习时就要认真对待，养成肌肉记忆。

6.2 真题复盘的正确打开方式

最后聊一聊复盘。做完一套真题，千万不要对完答案就扔到一边，那样做十套题也不会有明显提升。我自己的复盘流程是三步：

第一步，把做错的题按知识点分类，找出自己的薄弱区域。比如这套卷子里，如果你错的是JVM内存题和GC题，那就说明Java基础要补，而不是只把错题记住。

第二步，每道错题至少做三件延伸：问自己为什么错、正确的思路是什么、这一类题还有什么变形。我用Handler那道题举例：如果你只是记住了MessageQueue的数据结构，那你还能回答“MessageQueue如何保证按时间排序”“同步屏障是什么”“IdleHandler是什么时候执行的”吗。能延伸答出这些，错误才真正变成了收获。

第三步，建立自己的错题本。错题本不需要太长，一张表格就够了：

这套方法看上去很慢，但在实际备考过程中，它的效率远高于快速刷完十套题却什么都没有留下的做法。

回过头来看，这份2020年的小红书校招Android笔试题卷二，虽然已经过去几年了，其中很多题目的技术栈也发生了一些变化，但底层考察的几大能力——Java基础、Android系统机制、UI渲染、性能优化——至今仍然是Android面试的核心主线。与其焦虑题目难不难，不如从这份卷子里提取出可以迁移的考点，把整个知识体系补扎实。技术栈会变，但底层的原理和思维方式不会过时。