当前位置：首页 > news >正文

货拉拉2018秋招Android笔试复盘：知识底盘与高频考点拆解

news 2026/9/1 2:37:58

我拿到手的第一感受是：这份卷子出题人没打算让任何人提前交卷。三十分钟选择题连蒙带猜还能填满，到了简答和编程部分，基本就是现原形的时候。虽然标题写的是2018年秋招，但这套卷子覆盖的知识底盘，直到今天依然是Android笔试的主流方向。

当时我是在秋招群里看到别人分享这份“货拉拉2018秋招Android工程师笔试题卷三（A）”的。作为经历过那个阶段的人，我后来又专门把它找出来认真做了一遍，不是为找工作，而是想看看一家业务快速扩张的互联网公司，到底想通过一张卷子筛出什么样的Android工程师。

这篇文章不打算逐题给出标准答案，那没有意义，而且试卷版本之间也可能存在差异。我更想拆解的是：这套卷子的出题逻辑是什么、每个模块在考察什么能力、哪些题是送分题、哪些题是拉分题，以及如果你要准备同级别的Android笔试，最值得投入时间的知识方向是什么。

1. 这套2018年的卷子，考的是整个Android知识底盘

1.1 为什么一份几年前的卷子，现在还有复盘价值

2018年对移动端招聘来说是个比较微妙的节点。那一年“移动互联网下半场”的说法已经传了很久，App从快速增长期进入精细化运营期，招聘方对Android工程师的要求也悄悄发生了变化：会调接口、能写页面的人越来越难进面试，必须懂原理、能优化、能解决线上疑难杂症。货拉拉的这套卷三（A），恰好踩在了这个转折点上。

看一眼整套卷子的知识覆盖范围，基本就是一份完整的能力清单。Java层面要会集合与并发，Android层面要懂四大组件、Handler、Binder、View体系、消息机制，工程层面要理解Gradle、混淆、ANR和OOM的排查手段，再加上一到两道手写代码题。这些内容放在今天的Android笔试里，依然是绝对的主流。所以哪怕你眼下并不是在准备秋招，只是想把Android基础补扎实一点，这套卷子对应的知识地图都值得拿来当自测清单：哪些题能一眼出答案，哪些题要停下来想很久，哪些题完全没思路，做完一遍你对自己的水平就心里有数了。

1.2 卷面结构：从选择题到编程题的考核坡度

这类笔试卷子通常在90分钟到120分钟之间，题量安排是有讲究的。选择题放在最前面，考察的是“你知不知道”；简答题居中，考察的是“你理不理解”；编程题压轴，考察的是“你能不能做出来”。三层之间是层层递进的筛选漏斗。

以这套卷子的常见安排来看，选择题占了最大的比重，覆盖Java、Android机制、工程工具三块；简答题通常只出两到四道，但每道都要求“描述完整流程”或者“分析原因”，背结论的人在这儿会被直接刷掉；编程题虽然只有一道，但往往决定你能不能进入下一轮。真正的排序不是按题目的难易，而是按阅卷人想从哪个维度淘汰人：选择题淘汰知识面不达标的，简答题淘汰只会用不会想的，编程题淘汰代码能力不行的。

答题节奏上我自己的经验是：选择题每道控制在40秒以内，不会的先标记跳过，不要恋战；简答题每题留出8到10分钟，先写结论再展开流程；编程题至少要留30分钟，如果超过10分钟没有思路，果断先写一个暴力解，把分数拿到手再说。时间分配本身也是笔试考察的一部分，很多人并不是不会，而是前面磨太久导致后面编程题没时间写，非常可惜。

2. 选择题里的高频陷阱：都是“看似会、一选就错”的基础题

2.1 Java核心与并发：笔试里最容易被扣分的知识点

Java部分的选择题，围绕的无非是集合、并发、内存这几个大方向，但出题人很会设计干扰项。

HashMap是必考项。2018年那会儿正好是Java 8普及的时期，所以题目经常问“HashMap在什么情况下会从链表转为红黑树”，答案是链表长度达到8且数组长度不小于64。很多人的记忆只到“链表长度到8”，丢掉了“数组长度至少64”这个前置条件，选项里只要出现类似表述，大概率就是在坑你。还有一个高频考点是HashMap为什么线程不安全，典型原因是多个线程同时put触发扩容时可能形成循环链表，JDK 8以后虽然用尾插法解决了这个循环问题，但并发场景下仍然会丢数据，所以面试官喜欢用“是不是JDK 8就线程安全了”来制造陷阱，答案当然不是。

线程池也是一道送分但也容易送命的题。核心参数五个：corePoolSize、maximumPoolSize、keepAliveTime、workQueue、threadFactory与handler。出题方式通常是“核心线程数为2，最大线程数为4，阻塞队列容量为10，此时提交第13个任务会发生什么”。计算逻辑是：先让核心线程跑满，再往队列里塞任务，队列塞满后再创建非核心线程直到最大线程数，还不够才走拒绝策略。很多人会把“先创建非核心线程”和“先塞队列”的顺序搞反，这是选择题里非常经典的干扰点。

volatile和synchronized的区别也几乎没缺席过。一个关键考点是volatile只保证可见性，不保证原子性，所以i++这种复合操作用了volatile依然不是线程安全的。出题人常构造的场景是“两个线程同时对volatile变量执行i++，最终结果是否一定是20000”，答案是否，因为i++是读改写三步操作，volatile管不住中间的窗口期。synchronized则同时保证可见性与原子性，代价是重量级锁带来的性能损耗。这个知识点的本质是让候选人区分“内存可见性”和“操作原子性”两件不同的事。

2.2 Android机制类题目：Handler、Binder、四大组件怎么出题

到了Android核心机制，选择题的出题风格会从“记忆检验”变成“小场景判断”。

Handler是躲不开的。典型出题方式是给出一个场景：在子线程里new Handler会发生什么。答案是会抛RuntimeException，因为子线程默认没有Looper；正确的做法是调用Looper.prepare()创建Looper，再通过Looper.loop()开启循环。更深一层的考法是问Handler.post的Runnable运行在哪个线程，记住结论是运行在Handler关联的Looper所在线程，而主线程的Looper是在ActivityThread.main里通过Looper.prepareMainLooper()创建的。还有一类题目会问MessageQueue里message是如何排序的，答案是按照when时间戳升序排列，不是按插入顺序，这个细节在涉及延迟消息的题目里特别常用。

Binder在选择题里通常考“几大优势”和“一次拷贝”。Binder相对于传统IPC的优势在于性能与安全：一次数据拷贝，并且内核可以为每个进程建立UID/PID身份标识。选择题经常用“为什么Binder比Socket快”来设问，原因就是Binder只需从用户空间拷贝到内核空间一次，接收方通过内存映射直接读取，不需要两次拷贝。至于AIDL生成的Proxy和Stub结构，笔试阶段一般只要求知道本质是Binder驱动在两端做了代理解耦，把调用方和实现方隔离开。

四大组件的启动模式属于能拿分也容易丢分的部分。singleTask和singleTop的区别大家都能背，但一旦结合onNewIntent回调就乱套。常考场景是：A启动B，B是singleTask，然后在B里再启动A，问A和B各自生命周期的回调顺序。答案不是简单的onPause/onResume，而是会穿插onNewIntent，B会先onPause，A回到前台走onRestart、onStart、onResume，B随后onStop甚至onDestroy（取决于返回栈关系）。这类题考生必须把“栈里是否已有实例”和“是否复用已有实例”两件事同时想清楚，光背结论很容易选错。

2.3 工程与工具类：Gradle、混淆、ANR与OOM

工程化内容的占比在2018年已经明显提升，因为公司招人越来越注重“能不能在真实项目里干活”。

Gradle依赖冲突是选择题里的常客。典型场景是同一个库的两个版本同时出现在依赖树里，问你Gradle会采用哪个版本。答案是默认采用最高版本，但这里有个前提，如果项目里显式配置了force或者使用了resolutionStrategy，那结果会不一样。出题人喜欢把“最高版本”和“最先声明的版本”混在一起，后者是Maven的原则，放在Gradle题里就是干扰项。

ProGuard和R8混淆规则也是工程类选择题的一个考点。2018年那会儿主流还是ProGuard，现在新项目基本都用R8。常考的细节包括：keep规则的作用范围、为什么要keep住被反射调用的类、混淆后崩溃日志里的类名方法名都变成了短名，需要借助mapping文件还原。选择题通常拿一个keep规则让你判断是否生效，这类题的实际意义是要确认候选人有没有在生产环境里处理过混淆问题。

ANR的触发条件也值得单独背一遍：输入事件（按键、触摸）5秒内没处理完、BroadcastReceiver的onReceive前台10秒后台60秒没执行完、前台Service 20秒后台200秒没完成启动。选择题经常把“输入事件5秒”改写成“CPU占用率超过多少”之类的伪条件来迷惑人。OOM相关题则集中在内存泄漏场景识别上：静态变量持有Activity、Handler持有Activity、长期运行的线程持有Context、资源未关闭，这些都是标准答案，但要把每一个场景和对应的修复方案对应上，才算真的掌握。

3. 简答题真正的筛选点：源码级理解能不能落到纸面

3.1 Activity启动流程与启动模式：不是背结论而是讲链路

简答题里最喜欢问“简述Activity的启动流程”。这个题几乎人人都会写几句，但阅卷人真正在看的是你有没有把关键节点串起来的能力。

一个完整的回答至少要覆盖：调用方通过startActivity发起请求，经过Instrumentation的execStartActivity封装，通过Binder跨进程到达AMS；AMS检查调用者的权限、Intent匹配的目标Activity，再通过Socket或ApplicationThread通道通知应用进程创建Activity；应用进程侧由ActivityThread的ApplicationThread接收消息，在UI线程通过Instrumentation.newActivity反射创建Activity实例，再走onCreate、onStart、onResume，最后通过handleResumeActivity把DecorView添加到WindowManager完成显示。这中间涉及ActivityRecord、TaskRecord和返回栈的概念，答得越具体越能证明你真正读过源码。

启动模式如果出现在简答题里，通常会结合场景：比如“想要一个全局只有一个实例并且在独立任务栈中打开的页面，该选哪种launchMode”，答案是singleInstance，但要用一句话解释为什么，单独任务栈意味着它可以被其他应用复用，你可以多答一层：如果同时设置了Intent的FLAG_ACTIVITY_NEW_TASK，flag的优先级高于manifest中的launchMode，因为这个细节能把“背过结论”和“理解设计”区分开。答题时先把结论放在第一句，然后分步骤描述，最后补一句“如果由我来做会更倾向用哪种方案”，这样的结构最讨喜。

3.2 View绘制与事件分发：三个方法的关系要能讲清楚

“简述View的绘制流程”和“简述事件分发机制”是2018年简答题的两个重灾区。很多人能背出measure、layout、draw三个方法名，但描述不出它们之间的顺序关系、触发条件和协作方式。

绘制流程要从ViewRootImpl.performTraversals说起，它会在屏幕需要刷新时被调用，内部依次执行performMeasure、performLayout、performDraw三个阶段。测量阶段，View的measure方法会先读取LayoutParams得到宽高约束，再调用onMeasure计算具体尺寸，ViewGroup还要层层遍历子View；布局阶段决定每个子View在父容器内的位置，由LayoutParams和子View的测量尺寸共同决定；绘制阶段在ViewGroup里会先绘制背景，再通过dispatchDraw遍历子View的draw方法，最后由onDraw绘制自身内容。关键区别在于requestLayout和invalidate：requestLayout会从测量阶段重新开始，可能触发整棵View树的重新测量和布局，而invalidate只是发出一个绘制标志，只走draw阶段，这也是很多性能优化文章反复强调不要把高频刷新写成requestLayout的原因。

事件分发则要把dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent三者关系说清。分发顺序是Activity到ViewGroup再到View，先从外到内，再从内到外。ViewGroup的onInterceptTouchEvent决定是否拦截；如果拦截，事件会直接交给ViewGroup自己的onTouchEvent处理，子View收不到；如果不拦截，事件继续向下分发到子View。子View的onTouchEvent返回true表示消费，返回false会回溯给父容器处理。简答题想拿高分，可以补一句“在ACTION_DOWN返回false，后续的ACTION_MOVE和ACTION_UP都不会再收到”，这一句能体现你真的处理过实际分发逻辑，而不仅仅是背了方法名。

3.3 性能优化类简答：怎么回答才不显得像背八股

性能优化如果出现在简答题，常见问法是“如何分析并解决App启动卡顿”或“如何定位内存泄漏”。这种题目没有标准答案，但回答的结构直接反映候选人有没有真实排障经验。

比较好的回答框架是“先复现，再定量，后定位，最后修复验证”。复现阶段用Profiler或Systrace抓取一段时间内的CPU与主线程耗时，确认是CPU密集型问题还是主线程执行了耗时任务；定量阶段用Traceview或CPU Profiler找方法热点，或者用Systrace看关键帧的渲染耗时是否超过16.6ms；定位阶段把问题收敛到具体模块，比如启动时主线程调了数据库查询、SharedPreferences首次加载了超大文件、Application里做了大量初始化；修复阶段再讨论线程切换、懒加载、异步初始化、延迟初始化，最后用同样的工具验证效果。把这个逻辑讲清楚，比单纯罗列“用LeakCanary、用MAT、用Systrace”这些工具名要有说服力得多。

内存泄漏问题也一样，不要一上来就报工具名。先把泄漏的本质说清楚：长生命周期对象持有了短生命周期对象的引用，导致垃圾回收无法回收短生命周期对象。然后再分场景：handler导致的泄漏是因为非静态内部类持有外部Activity引用，修复方式是静态内部类加弱引用，在onDestroy时removeCallbacks；单例泄漏是因为单例持有Context，修复方式是使用ApplicationContext；匿名线程持有Activity是因为线程生命周期比Activity长，修复方式是在生命周期结束前中断线程。有工具、有分析、有修复方案的完整链路才是阅卷人想看到的。

4. 编程题不只是考算法：代码规范与工程思维同样占分

4.1 常考的算法题型与答题节奏

Android岗位的编程题通常不会出到ACM难度，更多是手写常见数据结构和简单的算法题。链表反转、判断括号匹配、二叉树前中后序遍历、最长回文子串、二分查找边界、快排手写，这些是出现频率最高的几类。

答题节奏上有个建议：不要一上来就追求最优解，先把一个能跑通的版本写出来，再讨论优化空间。比如链表反转，先写迭代版本的prev/curr/next三步法，在注释里说明循环不变式；如果时间充裕，再补一个递归版本并解释递归过程中next指针的断裂与重连。笔试阅卷人通常会看你最终提交的完整度，而不是只盯着有没有写出最优解。一个有时间复杂度注释、边界判断完整的暴力解，往往比一个没写完的“高级优化解”得分更高。

还有一个容易被忽略的考点：判空。很多Android开发平时写业务代码IDE都帮忙处理了空指针，但手写代码时最容易暴露习惯问题。方法入口对输入参数判空、循环里对集合判空、递归里对终止条件判空，这些细节看起来不起眼，但阅卷人一眼就能看出这个候选人有没有处理过真实线上问题。

4.2 手写设计题：图片加载框架、缓存策略、线程模型

除了纯算法题，有些公司喜欢在编程题环节出一两道“小型设计题”，考察你的工程组织能力。货拉拉的App业务和地图、配送强相关，这种公司尤其看重候选人拆解复杂模块的能力。

以经典的“设计一个图片加载库”为例，考点至少包括三层。第一层是接口设计：对外暴露load(url, imageView, callback)，但内部要有request对象封装URL和回调，避免方法参数膨胀。第二层是缓存策略：内存缓存用LruCache，磁盘缓存用DiskLruCache，加载顺序是内存、磁盘、网络三级，网络图片需要压缩采样避免OOM。第三层是线程模型：网络请求放到线程池，图片解码放到单独的线程池或复用同一个线程池，UI回调切回主线程，线程池要有饱和策略和统一命名方便排查。如果你能答出“为什么用LruCache而不是普通HashMap”，因为LruCache基于LinkedHashMap实现了LRU淘汰，并且支持线程安全的accessOrder，这就是加分项。

手写LRU缓存本身也是常见题。可以用LinkedHashMap实现，构造时设置accessOrder为true，重写removeEldestEntry判断size是否超过容量；也可以自己用HashMap加双向链表实现，后者更能展示对LRU原理的理解。两种写法都可以，但一定要把get和put的时间复杂度都降到O(1)这件事写明白，这是设计合理性的关键。

4.3 工程类笔试题：线程安全单例、生产者消费者、AIDL流程

还有一种编程题是“手写线程安全的单例”，这道题在Android笔试里出现的频率非常高，因为大部分候选人只会背一种写法，但出题人会要求你解释为什么这样写是安全的。

推荐直接写静态内部类实现：Holder类里持有static final的INSTANCE，利用类加载机制保证初始化一次，天然线程安全且不需要同步锁。也可以写典型的双重检查锁：加volatile修饰INSTANCE，在getInstance里先判空再进入synchronized块，块内再判空一次，三个要点缺一不可。要用一句话解释volatile在这里的作用，禁止指令重排导致拿到未完全初始化的对象，这是比“为什么要判两次空”更细的考点。

生产者消费者模型也常在Android笔试里出现，因为它和Handler、线程池的工作模式非常一致。用ReentrantLock加Condition实现，或者用BlockingQueue实现都可以。要主动描述出“队列为空时消费者等待、队列满时生产者等待”这个核心逻辑，并说明这种等待-通知机制是如何避免忙等的。如果你能进一步联系Android场景，说BlockingQueue的思路和Handler的MessageQueue类似，只是Handler还加入了时间戳排序和同步屏障，那这个题会答得非常漂亮。

AIDL流程如果出现在笔试题里，一般会要求写出关键步骤：先创建一个.aidl文件声明接口，然后由构建工具自动生成Stub与Proxy，服务端继承Stub实现具体方法，客户端通过bindService拿到IBinder再调用asInterface转换为接口引用。多写一句“AIDL的底层是Binder驱动，Proxy端把参数写入Parcel后通过transact发送到服务端，Stub端在onTransact里还原参数并调用真实方法”会更显功力，因为这说明你理解的不只是步骤，而是整个Binder通信闭环。

5. 复盘后的能力短板分析：错题不会骗人

5.1 错题集中区与背后的学习方式问题

我把整套卷子做完之后，对了一遍自己当年的答题记录，发现一个很有意思的规律：错得最多的不是最难的题，而是那些“觉得自己会但实际没学透”的题。Java并发、Handler机制、View绘制这三块，几乎就是Android笔试的三大失分黑洞。

这三块的共同特点是什么？都是“结论好背、细节复杂”的知识。比如ThreadLocal，很多人知道它能让每个线程有独立副本，但问“ThreadLocal在Thread里的存储结构是什么”就答不上来，答案是每个Thread内部都有一个ThreadLocalMap，key是ThreadLocal实例的弱引用。再比如View绘制，知道有measure和onMeasure，但问“onMeasure的默认实现和自定义View时应该重写哪个方法”就混乱了。这些知识靠看博客是记不牢的，必须自己翻开源码或者手写demo验证一次，理解才会从“结论”变成“场景记忆”。