企业官网建设流程全解析

B站这套2020校招Android笔试卷（二），我在准备面试的时候反复刷过好几遍。说实话，它不算特别难，但覆盖面很广，基础题、源码题、场景题都有，而且有几个题放在今天来看依然是高频考点。比起单纯背答案，我更建议大家把这套卷子当成一份“Android知识地图”来用，把每个考点对应的知识树铺开，这样无论面试官怎么换着花样问，你都能接得住。这篇文章我就以这套卷子为线索，把核心考点、答题思路、常见丢分点一次讲透，适合正在准备Android校招或者社招的朋友参考。

1. 笔试卷整体拆解：这套卷子到底在考什么

1.1 从岗位JD反推考察维度

B站的Android开发岗位，在业务上主要承担的是主站客户端、直播、播放器等模块的开发。这类业务型客户端岗位，对候选人的要求集中在四个维度：第一，Java和Android基础是否扎实，能不能直接上手写业务；第二，对系统关键机制的理解深度，比如Handler、Binder、事件分发，这决定了你能不能排查疑难问题；第三，工程化能力，包括网络层封装、性能优化、崩溃治理这些实战技能；第四，设计能力，给一个需求能不能给出合理的技术方案。

这套笔试卷就是围绕这四个维度出的。我印象比较深的是，卷子里很多题目不是单独考一个知识点，而是把知识点串起来考。比如一道关于图片加载的题，可能同时涉及内存缓存、磁盘缓存、线程池、LRU算法，这就是在模拟真实开发中“一个功能背后挂着一整套知识体系”的场景。

1.2 笔试卷的典型结构与时间分配

从题型分布来看，这套卷子主要分为客观题（选择题、判断题）和主观题（简答题、编程题、设计题）两大部分。客观题考察的是知识面的广度，主观题考察的是思维深度和表达能力。

这里要特别提醒一下时间分配的问题。我当初模拟这套卷子时，客观题大概花40%的时间，主观题花60%的时间。很多同学容易在客观题上纠结太久，碰到一个模糊选项就反复琢磨，结果留给后面编程题的时间就不够了。客观题遇到拿不准的，先凭第一印象选一个，标记一下，等主观题写完了再回头检查。

主观题里最忌讳的是“只写结论不写过程”。比如问你“Handler机制的原理是什么”，只写“Handler用于子线程更新UI”这种一句话答案，基本拿不到分。面试官想看到的是你对MessageQueue、Looper、Handler三者关系的完整描述，最好还能画出消息从发送到执行的时序流程，再补充一下主线程Looper的启动时机。写得越完整，越能体现你真的理解而不是背过。

2. 核心基础考点：Java 与 Android 的底层功底

2.1 语言基础：泛型、反射、注解与并发

这套卷子的Java部分，泛型和反射基本是必考的。泛型常考的是类型擦除、泛型边界、PECS原则（生产者使用extends，消费者使用super）。我建议大家不要只背结论，要能说清楚为什么会有类型擦除，以及擦除之后对重载、对性能有什么影响。

反射这块，常考的是反射的三种获取Class的方式、反射的性能损耗、以及反射在框架中的典型应用，比如Retrofit的动态代理、EventBus的注解解析。我复习的时候习惯把“反射+注解+动态代理”放在一起看，因为这三个东西在主流框架里经常一起出现，是理解很多开源库底层原理的钥匙。

并发题也是重头戏。volatile和synchronized的区别、ConcurrentHashMap的实现原理、线程池参数的含义和拒绝策略，这些都是高频中的高频。特别是线程池，我建议大家把七大参数（核心线程数、最大线程数、空闲存活时间、时间单位、任务队列、线程工厂、拒绝策略）全部背熟，然后能结合实际场景说清楚“核心线程数设置为多少比较合理”这个问题。

2.2 Android 核心机制：Handler、Activity 启动模式与四大组件

Handler机制是Android面试的“钉子户”，几乎任何一家公司的Android岗都会问。这套卷子里也出现了相关题目，而且问得比较细。要答好这道题，我建议从六个层面来组织答案：一是Handler的构造过程，二是Handler.sendMessage如何将消息放入MessageQueue，三是Looper.loop()如何循环取出消息并分发，四是Handler.handleMessage在哪个线程执行，五是主线程Looper在哪里启动，六是ThreadLocal在其中的作用。

Activity的启动模式也是必考内容。standard、singleTop、singleTask、singleInstance这四种模式的区别要能脱口而出，还要能结合具体场景说明“什么情况下用singleTask”。我在回答这类问题时会补充一个细节：同一个Activity在不同任务栈中出现时，onNewIntent的调用时机和参数处理，这是很多面试官喜欢追问的切入点。

四大组件里，ContentProvider和BroadcastReceiver经常被认为“用得少所以不重要”，但这套卷子偏偏考了。其实ContentProvider的底层是Binder，它的onCreate时机要早于Application的onCreate，这两个点都是加分项。BroadcastReceiver要注意动态注册和静态注册的区别，尤其是Android 8.0之后静态注册隐式广播的限制，以及Android 14对前台服务类型的新要求，这些是体现你关注系统版本演进的加分点。

2.3 高频源码题：事件分发与 Binder

事件分发是另一道“必背大题”。MotionEvent从Down到Up的完整流动过程，Activity、ViewGroup、View三者之间的dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent的调用顺序，要能画出来、说清楚。这里有个容易混淆的点：down事件和后续move/up事件在分发路径上的差异。ViewGroup在down事件中可能决定不拦截，但在move事件中突然拦截，这时候子View会收到一个CANCEL事件，这个细节很多人答不上来。

Binder机制属于进阶题，但B站这套卷子也确实涉及了。说实话，Binder的完整流程非常复杂，对于校招生来说，我建议重点掌握这几个层次：第一，为什么需要Binder，对比Socket、共享内存、管道的优缺点；第二，Binder通信的整体架构，Client、Server、ServiceManager、Binder驱动四者的关系；第三，一次完整的Binder调用中数据是如何从用户空间拷贝到内核空间、再从内核空间拷贝到目标进程的；第四，oneway机制和普通调用的区别。把这些讲清楚，已经能超过大多数候选人了。

3. 进阶实战考点：工程能力与性能调优

3.1 自定义 View 与绘制原理

自定义View是校招笔试中的“分水岭”题目，基础好的同学在这里能拉开很大差距。这套卷子里的相关题目，核心还是考察对View绘制流程的熟悉程度，也就是measure、layout、draw这三个阶段的执行顺序和各自的作用。

我建议复习时先理清这几个关键问题：MeasureSpec的三种模式（UNSPECIFIED、EXACTLY、AT_MOST）分别是什么意思，自定义View时onMeasure里调用setMeasuredDimension的时机，wrap_content和match_parent在测量时的区别。很多人在自定义View时忘记处理wrap_content，导致实际效果和预期不符，这个坑在笔试和面试中都能成为考点。

另一个高频方向是View动画和属性动画的区别。ObjectAnimator改变的是属性值，会真正触发onDraw更新；View动画只是视觉上的平移缩放，不改变属性本身。从Android 3.0开始官方推荐属性动画，这个知识点虽然基础，但能引出一大串后续问题，比如插值器和估值器的区别、动画监听器的回调时机，准备的时候可以顺带复习。

3.2 性能优化：内存、卡顿、启动与包体积

性能优化题在这套卷子里占比不低，而且出题方式很灵活。内存泄漏是必考中的必考，Handler造成的内存泄漏、静态Context引用、单例持有Activity、流未关闭，这四大经典场景要能说出原因和解决方案。我每次都会重点强调Handler的泄漏原理：内部类Handler持有外部Activity的隐式引用，异步消息在队列中排队导致Activity无法被回收。解决方案是用静态内部类+弱引用，或者在onDestroy时移除所有消息和回调。

卡顿优化是另一个高频方向。从布局优化说起，include、merge、ViewStub这三种标签的使用场景要分清；渲染层面要理解16ms原则，知道掉帧是怎么产生的；工具层面要会用systrace和Profile GPU Rendering。回答这类问题时，我会按照“发现卡顿—定位帧率—分析trace—优化布局/减少主线程耗时—验证效果”这个思路来组织，体现完整的排查能力。

启动优化在近年面试中越来越常考。冷启动、热启动、温启动的区别，以及Application的onCreate里不能做太多耗时操作这个结论背后的原因，都需要理解到位。懒加载、异步初始化、启动器框架（比如阿里的Alpha启动器）这些方案，可以在回答时作为加分项提一下。

3.3 网络层与数据持久化方案

网络相关的题目，OkHttp和Retrofit是核心考点。OkHttp要重点掌握它的请求流程：拦截器链式调用机制、连接池复用、缓存策略。Retrofit要理解它如何通过动态代理将接口方法转换成Http请求，以及如何与OkHttp配合。这套卷子如果出现网络题，大概率会围绕这些框架展开，因为它们是Android开发中真正每天都在用的基础组件。

数据持久化方面，SQLite、SharedPreferences、文件存储、Room这几种方式各有适用场景。我特别提醒一下SharedPreferences的坑：commit是同步写盘，apply是异步写盘，但apply在Activity生命周期回调时会有等待锁的风险，这在ANR问题排查中偶尔会碰到。Room作为官方ORM框架，在编译期就做了SQL正确性校验，还能返回LiveData自动监听数据变化，面试时提到这些优势是加分项。

3.4 Jetpack 与组件化架构

Jetpack在近年面试中的存在感越来越强，这套2020年的卷子里可能涉及不多，但放到现在必须准备。ViewModel和LiveData是重点中的重点。ViewModel为什么在屏幕旋转时不会销毁？因为它存储在ViewModelStore中，而ViewModelStore由Activity的NonConfigurationInstances持有，旋转后新的Activity会从旧的实例中恢复数据。LiveData的粘性事件特性、observe和observeForever的区别、数据倒灌问题如何避免，这些都是高频追问点。

组件化架构也是大厂面试的常客。模块化、组件化、插件化的区别，路由框架的原理（ARouter如何通过APT生成映射表）、模块间通信方式（接口下沉、事件总线、路由），这些概念在简历上写了就要能展开讲。如果你在项目里做过模块拆分，一定要把“为什么拆、怎么拆、拆完怎么通信、怎么解决重复依赖”这四件事想清楚。

4. 实操思路示范：典型题这样答才能拿高分

4.1 场景题：如何设计一个图片加载框架

这类设计题是主观题中的“大分值题”，题干通常很简单，比如“如果让你自己实现一个图片加载库，你会怎么设计”。很多同学一听就懵，其实这题有固定的答题框架。

我建议按五个模块来答：第一，网络请求模块，负责下载图片字节流，可以用OkHttp作为底层；第二，缓存模块，L1是内存缓存，用LRU算法管理，L2是磁盘缓存，L3是自定义缓存策略；第三，解码模块，根据ImageView的实际尺寸对图片进行采样压缩，避免大图直接加载到内存；第四，线程调度模块，网络请求放到IO线程池，解码放到CPU线程池，主线程只做UI更新；第五，生命周期管理模块，监听Activity或Fragment的销毁时机，及时取消加载任务和清理缓存。

按这个结构答，再补充几个关键细节：内存缓存为什么用LRU而不是LFU、图片压缩时inSampleSize怎么计算、Glide的生命周期绑定是如何实现的。这样整道题就被拆解得非常完整，面试官想追问也有抓手。

4.2 排查题：线上App出现卡顿，如何定位

这类题考察的是性能优化的综合能力，难点在于“没有标准答案”，但你可以用一套标准的排查思路来框架化回答。

第一步，确认卡顿范围，是冷启动卡还是页面切换卡，是特定机型还是全机型，是特定版本还是全版本，先缩小排查范围；第二步，通过APM工具采集卡顿现场，包括CPU占用率、主线程堆栈、内存状态、磁盘IO情况；第三步，复现问题并抓取trace，本机开发可以用systrace或Perfetto，线上可以用Matrix的卡顿监控模块；第四步，根据trace定位到耗时的具体方法，可能是主线程IO、过度绘制、大图解码、锁竞争等；第五步，给出优化方案，并设置埋点验证优化效果。

这套思路的价值在于展示了你的“排查方法论”，而不是碰运气瞎猜。答题时如果能提到“先用工具定位、再动手改代码”这个顺序，已经赢了一半。

4.3 设计题：IM类的消息列表如何保证滑动流畅

这种题目把性能和业务场景结合在了一起，很考验综合能力。我的回答会从四个层面展开：

数据层，消息列表要用分页加载和预加载，避免一次性拉取大量数据；缓存层要做到内存+数据库两级，滑动时优先读内存缓存，减少数据库查询次数。UI层，ViewHolder要复用，列表项的布局要扁平化，减少嵌套层级，头像加载要做圆角处理和占位图替换；如果消息类型多，还可以用多种ViewType来区分，避免一根布局塞满所有元素。渲染层，避免在getView或onBindViewHolder中做耗时操作，包括图片加载、文本测量、动画启动，这些都要延迟到空闲时处理。最后还有一个杀手锏——ItemAnimator，如果你的列表不需要动画效果，关闭默认动画能显著提升滑动流畅度。

按这个思路答，每一步都有据可依，还能根据面试官的兴趣深入讲解，整道题的完成度会非常高。

5. 避坑清单：应届生最容易丢分的五个细节

5.1 只记结论、不记原理

我在前面反复强调原理理解，是因为太多次看到有人“知道”有很多种启动模式，却说不清singleTask具体返回栈是怎么处理的。面试官只要追问一个“为什么”，就露馅了。所以每一项技术点，至少要准备两层的“为什么”：为什么这么设计，为什么有这个问题。比如Handler机制，不仅要答出“子线程不能更新UI”，还要说出为什么子线程不能更新UI，以及如果子线程一定要更新UI，有哪些安全的处理方式。

5.2 项目经验没有数据佐证

很多同学在简历上写“优化了冷启动速度”，但问到“优化了多少”就答不出来了。这是非常常见的问题。我建议大家必须自己亲自压测过数据再写进简历，比如优化前冷启动耗时1.8秒，优化后1.2秒，优化了33%，这些数字比任何形容词都有说服力。如果没有数据，赶紧自己造一个合理的场景去测试，这比临时背诵项目细节更有价值。

5.3 算法题基础不牢

B站的笔试卷有算法题，大部分公司的校招笔试也都有算法题。LeetCode的热题100和剑指Offer是基本盘，刷两遍才算合格。我个人觉得，比起追求刷题数量，更重要的是把每个题型的模板总结出来，比如二分法的边界处理、双指针的移动条件、动态规划的转移方程写法。笔试时间有限，能用模板快速写出的题目，就是稳定拿分的题目。

5.4 时间分配不合理

这道题其实在第一部分提过：主观题分值大，一定要留足时间。客观题不会的不要恋战，先把会的做完，再回来蒙。编程题不要一上来就写代码，先在草稿纸上把思路和边界条件列清楚，再动手写，这样既能减少写错回改的时间，也能让面试官看到你的思维过程。

5.5 忽视沟通表达

笔试虽然是写答案，但主观题的文字表达也是“代码”。我看到过很多技术能力不错、但答题逻辑混乱的答案，看了半天不知道要说什么。我建议主观题采用“先结论、再展开、最后总结”的方式作答，每个要点分条列出，关键术语和参数写全。这样即使内容没有100%完善，阅读体验也会好很多，容易拿高分。

6. 一点实在的备考建议

这套卷子刷完之后，我最大的感受是：B站的面试风格偏重基础和源码理解，不喜欢“背题家”，也不喜欢“只会调API的搬运工”。大家备考时要有意识地培养“源码视角”，平时用到的每一个框架、每一条API，多想一想底层是怎么实现的。比如你用Glide加载图片，可以顺手看看它的缓存键是怎么生成的；你用Retrofit定义接口，可以想想动态代理是怎么把注解转换成请求参数的。这种习惯会不知不觉地拉开你和其他候选人的差距。

如果时间有限，我建议优先把Handler机制、Activity启动模式、事件分发、绘制流程、网络框架原理这五个专题吃透，它们覆盖了大多数Android面试的80%高频考点。然后再花时间把自己项目里最有亮点的部分往深了打磨，确保每一个写在简历上的技术点都能经得起三轮追问。

最后再说一个细节：笔试过程中如果遇到完全没思路的题，不要空着。写一些自己相关的理解，比如相关概念、可能的解决方向、排查步骤，这些都能让面试官看到你的思考痕迹，比空白的答案强得多。这套B站笔试卷可以当作一面镜子，先测出知识盲区，再有针对性地补，比盲目刷题高效得多。祝大家都能拿到心仪的offer。