欢聚时代校招Android笔试题解析：从Handler到性能优化核心考点

每年这个时候，都会有同学翻出往年的校招真题来刷，欢聚时代2018校招的这套Android A卷【成都场】就是被翻牌率很高的一套。我当年也做过这套题，后来带新人、给部门出面试题时，又回头研究过几遍。说实话，这套题放在今天看，技术点并不过时，反而因为它出题思路很“业务导向”，对想进直播、社交、内容型公司的Android开发来说，参考价值一直很高。

这套题覆盖了Java基础、Android四大组件、Handler消息机制、网络与并发、性能优化、自定义View，还有典型的业务设计题，难度梯度做得比较合理。不管你是准备校招的应届生，还是工作经验一两年想查漏补缺的初级开发，认真过一遍这套题，基本能摸清自己在Android这条路上处于什么段位。这篇文章我按当年做题的回忆，结合后来复盘时补全的细节，把整套题的考点、答题思路、容易踩的坑一次讲清楚。

1. 题目整体评估：这家公司想招什么样的人

1.1 业务逻辑决定考核方向

欢聚时代是做YY直播起家的，后来围绕直播、游戏、社交做了不少产品。这类公司的Android端有个共同特点：IM通信模块、音视频播放、列表性能、稳定性治理都是核心命脉。所以你会发现，他们的笔试题不像某些做工具类产品的公司那样热衷于考冷门API，而是把大量分值压在“一个App运行时最核心的那些机制”上。

当年这套A卷给我的第一感觉是：不故意刁难人，但每一题都能筛人。比如Java基础部分，不会直接问你“HashMap和HashTable有什么区别”这种纯背诵题，而是给一段多线程环境下的代码，让你找出问题并改进。这就把“背过八股”和“真写过并发代码”的人区分开了。再比如Handler机制，不是简单问“Handler怎么用”，而是让你分析Looper在子线程中如何创建、MessageQueue空闲时IdleHandler的执行时机，这种深度更贴近实际开发中遇到ANR、卡顿排查时的知识储备。

还有一个值得注意的点：这套题里几乎没有纯粹的项目经历描述题，更多是给场景、给代码片段，让你做判断和设计。这说明公司筛选的是有扎实基本功、能直接上手干活的人，而不是只会罗列项目名词的人。如果你准备类似公司的笔试，复习重心应该放在“原理能讲透、代码能写对”上，而不是背一堆项目话术。

1.2 难度梯度设计与实战定位

从整体结构来看，这套卷子的难度可以分成三个梯队：

• 第一梯队（基础送分题）：Java基本语法、String、集合类、四大组件生命周期、Activity启动模式。这部分大概占30%分值，只要系统学过Android开发，认真准备过，基本都能拿分。但注意，送分不等于白送，题目里经常会埋“小陷阱”，比如问“Activity A启动B，两个页面的生命周期回调顺序”，很多人会答错成先执行B的onCreate再执行A的onPause，实际顺序恰恰相反。
• 第二梯队（进阶拉分题）：Handler异步消息机制、Binder原理、线程池参数设计、内存泄漏场景分析、ANR触发原理。这部分占40%左右，是整张卷子的分水岭。答得好的同学，通常不是靠背，而是真的在项目里排查过相关问题。
• 第三梯队（拔高筛选题）：自定义View绘制流程、性能优化方案设计、系统架构设计题。这类题没有标准答案，考察的是你的技术深度和工程思维。特别是最后那道设计题，我记得是让设计一个直播间的消息收发模块，这几乎是把“我们公司的业务场景”直接摆在台面上考。

这套题的实战定位很清晰：不是为了考倒你，而是为了筛出“在真实项目中能独立解决问题”的人。如果你刷题时发现自己卡在第二梯队，别焦虑，这恰恰说明你的短板在哪里，照着补就行。我从这道题里总结出的复习策略是：基础知识要形成网络，原理要能画图讲给别人听，代码要能手写不依赖IDE，这样无论题目怎么变，你都能稳住基本盘。

2. 考点逐块拆解：从Java基础到性能优化

2.1 Java 与内存管理：校招笔试的“基本功大关”

这套卷子的Java部分，考察重点不在语法糖，而在内存模型、集合类底层、并发工具这三块。先说集合类，当时有一道题是给出一段代码，往HashMap里并发put元素，问会出现什么问题。这题想拿全分，你至少要答出三点：

第一，HashMap在并发put时可能造成数据覆盖，因为它的put操作不是原子的，多个线程同时命中同一个桶位时，后写的会把先写的覆盖掉。第二，在JDK7及以前，并发put还可能触发resize时的死循环，因为头插法在扩容时会形成环状链表，get时就会卡死。第三，JDK8改成了尾插法，解决了死循环问题，但数据覆盖和size计数不准确的问题依然存在。能答到这层深度，说明你是真的理解HashMap而不是单纯背了“线程不安全”这五个字。

再来说String，卷子里有一道很经典的题：String s = new String("abc") 创建了几个对象。这题看着简单，但能完整答对的人不多。正确理解是：如果常量池里已经有"abc"，那只创建一个堆对象；如果常量池里没有，那会先在常量池创建"abc"，再在堆里创建一个引用同一个字符数组的String对象，也就是两个对象。出题人想通过这道题看你对JVM内存区域划分是否清晰，特别是常量池在JDK7之后从方法区挪到了堆里这个变化。

内存管理这部分，最有代表性的一道题是分析一段代码中的内存泄漏点。常见的泄漏场景无非是这几种：静态变量持有Activity引用、Handler持有Activity且消息未移除、匿名内部类持有外部类引用、资源未关闭。但企业考题的高明之处在于，它会把两三个泄漏点藏在看起来挺正常的业务代码里，比如在一个单例类中缓存了Activity的Context、在子线程回调里更新UI却忘了移除回调、一个静态集合往里面add了监听器却从没remove。想答全，靠的不只是背，而是平时写代码的时候有没有这种“随手释放”的肌肉记忆。

2.2 四大组件与消息机制：Android的“运行骨架”

Android部分的重头戏，第一块是Activity和Service。启动模式是必考的，standard、singleTop、singleTask、singleInstance这四种模式，不只是背区别，要能结合场景说清用法。比如推送详情页为什么要用singleTop，因为通知栏可能连续点多次，如果用standard会叠一堆一样的页面；应用主界面为什么要用singleTask，因为从其他App跳回来时要把它上面的页面全部清掉，避免返回时看到一堆残留页面。

还有一道生命周期题我一直印象深刻，题目大致是：Activity A启动了一个全透明的Activity B，问A和B的生命周期怎么走。这个场景平时不多见，但确实会在广告SDK、埋点跳转时遇到。正确答案是：A.onPause -> B.onCreate -> B.onResume -> A.onStop。注意，A不会执行onStop，因为B是全透明的，A虽然不可交互但仍然可见。很多人在这里凭直觉答错，其实就是对“可见”和“可交互”这两个概念区分得不够清楚。

Handler消息机制几乎是所有Android笔试的必考题，这套卷子也不例外。除了常规的“Handler、Looper、MessageQueue三者关系”之外，这里有两道值得好好说的题目。一道是：能否在子线程中直接new Handler？如果不能，应该怎么处理。答案是不能，因为子线程默认没有Looper，会抛RuntimeException。正确做法是先Looper.prepare()再new Handler，最后Looper.loop()。另一道是：MessageQueue中的消息是按什么顺序取出的？这个问题要答到深度，需要说出MessageQueue本质是一个按时间排序的优先级队列，通过next()方法阻塞获取下一条消息，如果没有到时间的消息就计算阻塞时长，如果有空闲就执行IdleHandler。能把这套机制完整讲清楚，再配合“为什么主线程Looper不会退出”、“同步屏障是什么”这两个延伸点，这道题基本就能拿满分。

Activity启动流程也是这套卷子的大题之一，它本质上是考Binder跨进程通信。从startActivity开始，经过Instrumentation、ActivityManagerService（AMS）、ApplicationThread，再到ActivityThread，整条链路很长，但核心要抓住一个点：App进程和AMS进程之间通过Binder通信，AMS负责生命周期决策，App进程负责实际执行。这部分内容如果复习到位，其实也是后面Binder专项题的基础。

2.3 网络、线程与并发：做直播App的基本素养

网络相关题目在这套卷子里占的比重不小，毕竟直播类App对网络依赖极高。有一道题是让你说一次完整的HTTP请求从发出到收到响应经过了哪些过程，这个属于基础题，DNS解析、TCP三次握手、HTTP请求行和头部、服务器处理、响应返回、浏览器渲染或客户端解析，按顺序答完即可。但真正的拉分点在于扩展题：HTTPS和HTTP的区别，以及TLS握手过程。这里建议至少答出对称加密和非对称加密的结合使用方式、CA证书的作用、TLS握手中客户端和服务端如何协商密钥这几层。

线程这块，套路比较固定但很考验细节。卷子里有一道线程池相关的题目：给定一个场景，让你设计一个线程池参数。这类题的关键在于理解核心线程数、最大线程数、阻塞队列、拒绝策略这四个参数之间的关系。比如一个以IO操作为主的直播消息处理模块，核心线程数不宜设得太大，但队列可以稍微长一些来应对突发消息；而一个CPU密集型的图像处理模块，核心线程数最好接近CPU核数，队列不宜太长，否则上下文切换开销会吞掉性能收益。这道题想拿高分，要答出“为什么”，而不是简单套公式。

并发题里还有一道比较经典的：多个线程同时对一个int变量做自增操作，最终结果是否等于预期值。这题想考的是volatile和原子类的区别。volatile只能保证可见性，不能保证原子性，所以自增操作依然会丢数据；正确做法是用AtomicInteger或者加锁。另外，还有个很容易被忽略的细节：volatile在Java 5之后通过内存屏障保证了禁止指令重排，这也是单例双重检查锁为什么需要volatile的原因。这类题目背后考察的是你对JMM（Java内存模型）的理解，而不只是API使用。

2.4 性能优化与自定义View：区分“会写”和“写好”

性能优化这块，试题里有两道题让我印象最深刻。一道是关于ANR的：让你列举几种常见的ANR场景，并且说排查思路。可以简单概括为三类：输入事件5秒无响应、广播前台10秒或后台60秒未完成、Service前台20秒或后台200秒未完成。但仅仅答出这些阈值是不够的，关键在于排查思路。顺着logcat里的ANR日志，找到CPU使用率、内存占用、主线程堆栈，再结合TraceView或CPU Profiler定位卡顿方法，这套流程要能说出来。另一道是布局优化：一个列表项布局嵌套了六七层LinearLayout，滑动时明显卡顿，让你给出优化方案。常规思路是使用ConstraintLayout减少嵌套层级、用include和merge复用布局、用ViewStub延迟加载不常用视图、用RecyclerView的setHasFixedSize和onBindViewHolder复用逻辑，这些答出来基本就过了。

自定义View是很多人的痛点，也是这套卷子的压轴考点之一。题目给了一个自定义控件需求：实现一个带圆角和边框的进度条，要求支持在XML中自定义属性。这道题表面考的是onDraw，但实际想考的是完整流程：构造方法里读取obtainStyledAttributes获取自定义属性、onMeasure里根据MeasureSpec模式处理wrap_content和match_parent的差异、onDraw里用Paint画圆形背景、画进度圆弧、画文字，最后处理invalidate和postInvalidate的区别。想拿高分，还需要补充一句：如果属性变化频繁，要注意用Choreographer或ValueAnimator来做动画刷新，而不是在onDraw里做耗时计算，否则会掉帧。

我还记得最后一道综合题，也是全卷少数没有标准答案的题：设计一个直播间的弹幕消息模块。这题考察的是综合能力，至少要从几个角度回答：消息通道用什么（WebSocket还是长轮询）、消息到达后如何在主线程更新UI保证不卡顿（消息合并批量刷新而不是来一条刷一条）、弹幕数据的存储和复用（对象池避免频繁GC）、消息优先级处理（系统消息要置顶显示，普通弹幕可以丢弃）。这道题几乎把前面所有的知识点都串起来了，能完整答好的人，基本就是他们想要的人。

3. 编程题与设计题实操复盘

3.1 手写代码题：常见的算法与逻辑题

这套卷子的编程题不算难，但很考验手写代码的规范性。我记得有一道是手写单链表反转，这题太经典了，关键是要写对边界条件。很多同学一上来就写迭代法，head为空或只有一个节点时直接返回head，这个边界处理是得分点。

public ListNode reverseList(ListNode head) { ListNode prev = null; ListNode curr = head; while (curr != null) { ListNode nextTemp = curr.next; curr.next = prev; prev = curr; curr = nextTemp; } return prev; }

如果时间充裕，可以再写一个递归版本，并在注释里说明两种方式的时空复杂度，这是加分项：迭代法是O(n)时间、O(1)空间，递归法虽然没有显式用额外空间，但递归调用栈深度为n，空间复杂度是O(n)。这种细节在批卷时非常加分，能看出你的工程素养。

还有一道逻辑题也比较有意思：实现一个只能存5个数的数据结构，超出后自动淘汰最早放入的那个。当年很多人第一反应是用List加remove(0)，但面试官想看到的其实是用队列实现，或者用循环数组实现。用队列很简单，LinkedList天然支持FIFO操作，超出容量时poll头部即可。但如果题目加一个要求——淘汰后要能在O(1)时间内判断某个元素是否存在，那就得用LinkedHashMap或者自己设计HashMap+双向链表的结构了，这个思路其实就是LRU缓存的老底子。能把这道题从简单解法聊到LRU，说明你已经有意识地往中间件、框架设计层面思考了。

3.2 系统设计题：直播场景的架构方案

设计题是这套卷子真正的拉分项，我后续带人时也喜欢拿它来考校招同学。题目范围是直播间消息模块，包含弹幕、礼物、系统公告、点赞这几类消息。这里有一个核心矛盾要先点出来：直播间的消息量是极高的，尤其是大主播开播时，一秒可能进来几千条弹幕，如果每来一条就刷新一次UI，主线程必挂。所以设计的第一原则是批量合并刷新：在消息到达的极短时间窗口内聚合多条消息，统一提交给UI线程做一次刷新。我建议用一个Handler + 定时任务的方案：把消息放入队列，每隔100ms批量取出一次，拼接后在RecyclerView里以notifyItemRangeInserted的形式插入，这样既能保证UI流畅，又不会丢失消息。

第二个设计点是消息通道选型：弹幕场景，业界主流方案是WebSocket长连接，因为HTTP轮询的实时性不够，而且频繁建连消耗太大。但这个选择要回答出WebSocket的心跳机制怎么设计，比如30秒发一次ping保住连接，同时要考虑断线重连策略，比如指数退避算法，避免服务端被打满。

第三个设计点是消息优先级：系统公告必须强制显示，礼物消息可以合并成连击展示，普通弹幕在极端情况下允许丢弃。这个策略需要在客户端做分级处理，不能一股脑全部渲染。我当时的思路是抽象出一个PriorityQueue，按消息类型设定不同优先级，弹出时先处理高优先级消息，低优先级在队列满时直接丢弃并统计丢弃数量。

这道题能答到这个深度，基本就能体现出一个候选人的架构能力和业务敏感度了。我自己在面试别人时，如果有人能主动提到“消息丢弃计数”“对象池复用消息对象”“在子线程解析JSON”这些优化点，我都会在评价里重点标注。

4. 笔试题实战技巧与复盘方法

4.1 答题顺序与时间分配的实操建议

这套卷子的题量不算小，如果按部就班从头做到尾，很容易在最后设计题上时间不够。我当时的策略是先花3分钟把整张卷子扫一遍，把题目按“秒答、需要思考、需要大段时间”分类，然后先做秒答题，再做需要思考的，把最后的编程题和设计题留足40分钟。

具体时间分配上，我建议基础选择题和简答题控制在30分钟以内，知识点解释题控制在40分钟左右，编程题和设计题至少留50分钟。很多同学容易在知识点解释题上写太多，一题写一两百字，结果后面编程题没时间做，这是性价比极低的做法。

还有一个容易丢分的点是写代码时忘记考虑边界条件。比如反转链表那道题，如果连空链表和单节点都没处理，至少丢一半分。我的习惯是：手写代码时，先把边界条件写在最前面，然后再写主逻辑，最后补注释说明时空复杂度。这种习惯在笔试和面试手写代码时都非常加分，因为它体现了工程思维。

4.2 做完题后的复盘应该看什么

笔试不是考完就结束了，复盘才是提升自己的关键环节。我见过太多同学刷完题对完答案就扔一边，下次遇到类似题目还是不会。正确的复盘方式，是对着每道错题问自己三个问题：这道题考察的知识点是什么、我为什么没答上来、这个知识点在项目里对应什么场景。

比如Handler源码那道题，如果你能回忆起之前在项目里遇到过自定义Looper线程处理耗时任务，那这个知识点就不只是背下来的概念，而是和实际工作绑定在一起的技能。同理，Binder那题如果你做过跨进程通信或者了解过AIDL的生成代码，理解起来会顺畅得多。所以我的建议是：准备一个错题本，把每道错题对应到自己的项目经验上，哪怕只是“之前遇到过类似的bug但没有深挖”，也把它写下来。

4.3 复习路线的拓展建议

如果你准备的是欢聚时代或者类似直播、社交业务的公司，参考这套题之外，我还建议把复习范围再扩大一圈。一个是插件化与热修复基础原理，ClassLoader机制怎么实现加载外部dex，这些是很多大型App在用的技术，笔试偶尔会出现。另一个是Kotlin协程与Java线程的对比，现在很多公司的新项目都已经切到Kotlin了，协程的挂起和恢复原理、Dispatchers的调度逻辑，都是高频考点。

还有一个点容易被忽视，就是版本适配和新技术跟进。Android 8.0的Notification渠道、Android 10的分区存储、Android 12的SplashScreen，这些如果题目里给一个“在Android P上遇到某个问题”的场景，你至少要知道对应版本的关键变化点在哪里。复习的时候不用把所有版本都背一遍，重点是近两三年的版本变化，因为公司更关心你在新系统上排查问题的能力。

我个人在实际操作中的体会是，整套题做下来，得分高低倒在其次，最有价值的其实是暴露出来的知识盲区。我第一次做这套卷子的时候，自定义View和并发编程两道题基本是懵的，后来花了两个月时间专门补这部分，不仅笔试过了，后面做项目时处理复杂列表和线程问题也明显更有底气。所以说，校招笔试题其实是给你画了一幅技术地图，按着地图补短板，比漫无目的地刷题效率高得多。最后再分享一个小技巧：做题的时候凡是遇到让你“说思路”的题，尽量用“是什么、为什么、怎么做”三段式结构来组织答案，这个习惯在笔试和面试中，都能让你显得逻辑清晰，远超那些想到哪写到哪的竞争者。