商汤Android校招笔试复盘：从Binder到图片加载库的考点全解析

开头

2018年秋天，我坐在商汤科技校招笔试的考场里，面对那张Android开发工程师的试卷，第一反应是“这公司的笔试怎么一股算法味儿”。说实话，当时很多同学是冲着AI公司的光环去的，以为Android岗就是考四大组件、写个界面，结果一拿到卷子就发现，商汤考的东西比想象中深得多。这场笔试虽然过去几年了，但直到现在，我依然觉得它是我参加过的最有代表性的AI公司Android校招笔试之一，也成了我后来面试其他大厂时反复复盘的一份材料。

这篇内容适合两类人看：一类是准备投递AI公司、图像类App团队Android岗位的应届生，另一类是已经工作一两年、想补一补底层原理短板的Android开发。我会把这场笔试的题型构成、核心考点、答题思路、现场踩坑全部拆开讲，不是单纯回忆题目，而是告诉你每一类题背后面试官到底在考察什么，以及你现在该往哪个方向准备。哪怕你拿到的不是商汤的卷子，这套分析思路也完全能用。

1. 商汤校招笔试的定位与整体设计思路

1.1 AI公司招Android工程师，到底想招什么人

先聊一个很多人没想明白的问题：商汤这种以计算机视觉算法为核心的公司，为什么要大规模招Android开发？

2018年正好是移动端AI开始落地的关键节点。人脸识别解锁、AR特效、智能相册、端侧检测这些能力，都需要跑在手机App里，而App的载体就是Android和iOS。算法团队写出模型，不能只放在服务器上，还得有一个专门的Android工程师把模型封装成SDK、集成进App、处理相机流、优化推理速度、解决各种机型适配问题。这就决定了商汤对Android工程师的画像不是“会写界面就行”，而是“能理解系统底层、能对接算法SDK、有性能优化意识、能独立解决疑难问题”。

这个定位直接反映在笔试题型上。我在那场笔试里明显感觉到，选择题和简答题覆盖的知识面特别广，Java、数据结构、网络、Android Framework、多线程并发全都有，而且难度不是均匀分布的，有些题明显是拿来筛掉基础不牢的人，有些题则是拉开差距的。编程题不是纯LeetCode风格，反而带了点工程味道，给的场景往往需要你综合考虑时间复杂度和代码可读性。设计题更是直白，直接就让你设计一个在实际业务中会遇到的模块。

1.2 第一场笔试题型结构与时间分配复盘

商汤的笔试第一场，我记得是线上笔试，总时长大概120分钟，题量不小，题型大致分为四块：

这个时间分配是个理想模型，实际操作中很多人会翻车，因为选择题里藏着几道很刁钻的题目，一纠结就五分钟过去了。我复盘时总结出的策略是：选择题遇到没把握的，先标记跳过，不要恋战，把时间留给后面的简答和编程题；编程题就算不能完全AC，也要写出能跑通大部分用例的代码，不要一句“不会”就空着。

另外还有一个容易被忽略的点：商汤的笔试系统是支持本地IDE写完再贴上去的，不像某些平台只有网页编辑器。这个细节很重要，意味着你完全可以用自己熟悉的Android Studio或者IDEA把代码跑通再提交，比纯手写代码的容错率高很多。

1.3 2018年的技术背景决定了题目风格

2018年Android技术栈正处在一个分水岭上。Kotlin刚发布1.2版本不久，虽然Google已经宣布Kotlin First，但大部分学校课程和企业项目还在用Java，所以笔试选择题里Java语法和并发仍然是主流，Kotlin几乎没怎么出现。Jetpack那一套（LiveData、ViewModel、Room）虽然已经推出了，但普及率还没有现在这么高，笔试里也很少直接考Jetpack组件，更多是考最原始的Android组件机制。

但有一个趋势是明显的：开源库原理开始成为笔试的高频考点。2018年Retrofit、OkHttp、Glide、RxJava这些库已经成了项目标配，所以笔试简答题里经常出现“Retrofit的原理是什么”、“Glide的缓存机制了解吗”这类题目。这其实是面试官的一种考察策略——你简历上写了用过这些库，那就得知道它们内部是怎么实现的，否则只是停留在调用层面的“使用工程师”，而不是他们想要的“解决工程师”。

顺便说一句，那时候商汤已经开始在移动端做深度学习框架相关的工作了，所以笔试里偶尔会出现一些跟NDK、JNI、性能优化相关的考察点。你不需要会写C++，但至少得知道Java层和Native层之间是怎么通信的，这在后面的简答题或设计题里会成为一个加分项。

2. 核心知识点拆解：从Java基础到Android Framework

2.1 Java基础与并发：选择题里的“送分题”和“送命题”

Java基础这部分，表面上看是送分题，实际上藏着很多坑。我记得有一道题是问HashMap在Java 8中的数据结构，选项里包含了“数组加链表”、“数组加红黑树”、“链表加红黑树”这些排列组合，如果你只背过“数组加链表”这个口诀，就会掉进坑里。正确答案是数组加链表，但当链表长度超过8且数组长度大于等于64时，链表会转成红黑树。这种题考的是对细节的掌握程度，而非概念性的了解。

更狠的是并发相关的题目。volatile和synchronized的区别、ConcurrentHashMap在Java 7和Java 8中的实现差异、线程池的核心参数和执行流程、CAS和AQS的基本原理、ThreadLocal的内存泄漏问题，这些几乎是商汤这类技术型公司笔试的固定组合。我当时复习的时候总结过一套口诀：volatile保证可见性不保证原子性，synchronized是可重入的独占锁，ConcurrentHashMap读不加锁写加锁并且锁粒度细化到桶。这套口诀能帮你快速解70%的并发选择题，但剩下30%会考得更细，比如“ThreadLocal的key为什么用WeakReference”以及“内存泄漏发生在什么场景下”。

我建议大家复习Java并发时不要只看结论，要把执行流程画出来。比如线程池执行一个任务时，是先判断核心线程数，还是先往队列里丢，还是先判断最大线程数？这个顺序如果弄反了，遇到那种“核心线程数为2、最大线程数为4、队列容量为10，同时来了15个任务”这种题就直接蒙圈。正确顺序是：先判断核心线程是否已满，没满就创建核心线程执行；满了就尝试放入阻塞队列；队列也满了再判断是否达到最大线程数，没达到就创建非核心线程执行；达到就执行拒绝策略。这个流程在简答题里也经常出现，值得画下来贴桌子上。

2.2 Android四大组件与Binder机制：必考但容易丢分的重灾区

四大组件属于Android开发的基本盘，但商汤笔试考得比一般公司深入。Activity会问启动模式（standard、singleTop、singleTask、singleInstance）各自的使用场景，以及onSaveInstanceState和onRestoreInstanceState的调用时机。Service会问startService和bindService的区别，以及混用时生命周期怎么走。BroadcastReceiver在2018年是个热点，因为Android 8.0对隐式广播做了限制，静态注册很多场景下收不到广播了，这个知识点当年很多人不知道，答不上来就会丢分。ContentProvider相对考得少一些，但如果是做跨进程数据共享的场景，也会考到它和Binder的关系。

Binder是整张试卷里最硬核的一部分。选择题可能会问“Binder通信中数据拷贝了几次”，答案是1次，因为Binder利用mmap把内核空间和用户空间做了映射，避免了传统IPC的两次拷贝。简答题里更常见的是让你描述Binder的完整通信流程：客户端通过ServiceManager获取远程服务代理，调用代理方法时数据被序列化后写入共享内存，驱动层完成数据传递，服务端收到请求后执行方法并通过同一个通道返回结果。这个流程要说清楚并不是靠背模板，而是要有自己的理解。

我当时吃透Binder用的方法是自己写了一篇笔记，把整个调用链路用文字一行一行地描述清楚，比如“client调用remote.transact()，然后陷入内核态，binder_thread_write把数据写入，binder_thread_read等待返回值，驱动唤醒server端的binder线程，server执行onTransact，返回结果”。写完这个流程之后，再去看那些选择题，你会觉得出题人已经没什么花样可玩了。这里提醒一下，Binder只考Android原生IPC那套，不要扯到AIDL之外的什么神秘技术，AIDL只是Binder的上层封装，考的还是Binder本身。

2.3 自定义View与事件分发：商汤特别爱考的内容

为什么说商汤特别爱考自定义View？因为他们的业务场景里大量涉及相机预览、人脸框绘制、图像特效渲染，这些功能在Android上实现，基本绕不开自定义View和SurfaceView/TextureView的选择。所以笔试里出现一道“onMeasure、onLayout、onDraw的调用顺序”或“invalidate和requestLayout的区别”这种题，太正常了。

onMeasure和onLayout是很多校招生的弱点，因为平时写界面都是XML里套用现成控件，很少自己实现测量逻辑。笔试里如果考“自定义View支持wrap_content需要注意什么”，你就得知道：不重写onMeasure的话，wrap_content会被当成match_parent处理，因为父类默认的测量模式是AT_MOST时直接使用了父容器剩余空间作为测量结果。正确的做法是在onMeasure里根据MeasureSpec的mode做判断，如果是AT_MOST，指定一个默认值。

事件分发这块，核心就是dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent三个方法的职责划分，以及事件从Activity到ViewGroup再到View的传递顺序。选择题经常给一个场景，比如“一个Button嵌套在LinearLayout里，两者都设置了OnTouchListener和onTouchEvent，点按钮时方法调用顺序是什么”，这题如果不画一张事件分发链路图，很容易记混。我的记忆技巧是：事件总是先给最外层的ViewGroup做拦截判断，如果ViewGroup不拦截，就传递给子View；子View如果消费了事件，那父ViewGroup的onTouchEvent就不会被调用，反之则逐级向上传递。父View拦截后子View收不到事件，但父View自己可以收到后续事件。

2.4 数据持久化与网络层：不会直接考，但设计题绕不开

数据持久化在2018年笔试里通常不会单独出简答题，而是出现在设计题或者场景题里。比如“让你设计一个图片加载库，缓存策略你怎么做”，这就涉及到内存缓存（LruCache）和磁盘缓存（DiskLruCache）的配合使用，本质上是数据持久化方案设计。数据库也是如此，如果考“设计一个聊天消息存储模块”，你就要考虑SQLiteOpenHelper的使用、版本升级、索引优化、事务处理等细节，这些知识点虽然不直接出现在选择题里，但你在设计题中的思考深度直接决定面试官对你的评价。

网络层在选择题里考得比较基础，主要是一个HTTP请求从发起到返回的完整过程、TCP的三次握手和四次挥手、HTTPS和HTTP的区别、HTTP/2的新特性等。这些内容在大二计算机网络课上都学过，但很多人忘得差不多了，考前一定要重新过一遍。我记得有一道选择题问“TCP连接建立时，前两次握手的标志位是什么”，答案是SYN和SYN+ACK，难度不大，但如果你只记得确认号序号的概念，忘了标志位，就容易选错。

到了设计题阶段，网络层就重要了。比如“设计一个App的崩溃日志上报系统”，如果你能想到日志先存本地数据库、在合适的时机批量上报、失败要重试、上报时携带设备信息和App版本号、考虑网络状态和流量消耗、用WorkManager或JobScheduler做任务调度，那这道设计题你就已经稳稳拿到80%的分数了。不过2018年WorkManager还没推出，当时更合理的答案是IntentService加网络状态监听，这些细节在答题时要结合当年技术栈。

3. 实操复盘：当年真题的思路推演与答题模板

3.1 一道典型算法题：最大连续子数组和的完整推演

算法题在商汤笔试里通常不会出偏难怪题，更偏向在LeetCode上常见但稍加改动的真题。我印象深的一道是最大连续子数组和，题目描述是给定一个整数数组，找到一个具有最大和的连续子数组，返回其最大和。这道题的原型是LeetCode 53题，难度属于中等偏低，但它有一个要求很关键：代码里不能使用额外空间，也就是空间复杂度要为O(1)。

解题思路用到的是动态规划。我们可以定义一个变量cur表示以当前元素结尾的最大子数组和，另一个变量max表示全局最大子数组和。遍历数组时，cur的更新方式是“cur = Math.max(num, cur + num)”，这行的含义是：如果当前元素本身比加上之前的累加和还大，说明之前的累加和是负收益，直接舍弃，从当前元素重新开始。然后用max = Math.max(max, cur)更新全局最大值。这样一轮循环就解决了问题，时间复杂度O(n)，空间复杂度O(1)。

这道题的易错点在于初始化。我第一次写的时候把cur初始化成了0，结果是如果数组里全是负数，答案就会错误地返回0而不是最大的那个负数。正确做法是cur = nums[0]，max = nums[0]，然后从第2个元素开始遍历。这个边界细节，笔试时一定要写清楚，因为出题人很喜欢在测试用例里放全负数的情况。

如果题目进一步扩展，让你同时输出最大子数组的起始位置和结束位置，那就要在更新cur的时候记录起点和终点下标。遇到cur = Math.max(num, cur + num)且选择了num这一侧时，就把临时起点设置为当前下标；当max被更新时，把最终起点和终点同步过去。这种“一题多问”的情况在笔试里也出现过，所以我建议大家复习算法题时不要只背题解，要理解每个变量的含义，学会在同一个思路上做扩展。

3.2 一道Android架构题：设计图片加载库的答题框架

图片加载库这道题在2018年出现频率极高，因为Glide当时已经非常流行，但很多人只懂用不懂原理，面试官正好拿这个来筛选。设计题通常是“如果让你自己实现一个类似Glide的图片加载库，你会怎么设计，需要考虑哪些模块”，这道题没有标准答案，但有一个公认的答题框架。

第一步是明确核心模块划分。至少要有三个模块：图片请求模块、缓存模块、显示模块。图片请求模块负责接收外部传入的URL和ImageView，把加载任务封装成一个Runnable丢给线程池；缓存模块负责判断内存缓存、磁盘缓存、网络加载的优先级；显示模块负责在主线程将Bitmap设置到ImageView上，同时处理图片的裁剪、缩放、圆角等变换操作。

第二步是讲清楚缓存策略。我当时的回答是先检查LruCache内存缓存，命中就直接返回；没命中再检查DiskLruCache磁盘缓存，命中就加载磁盘图片并回填内存缓存；都没命中才走网络请求，请求成功后按顺序写入磁盘缓存和内存缓存。这里有一个加分项：三级缓存机制不是简单的“内存-磁盘-网络”，而是每一级缓存都要设置合适的容量和淘汰策略，例如LruCache的容量要考虑App可用内存的大小，具体可以用ActivityManager.getMemoryClass()来估算，避免占用过多内存。

第三步是考虑生命周期管理。如果Activity销毁了，图片加载任务还在执行，就会导致内存泄漏和崩溃。所以设计库里必须有一个机制，可以监听Activity/Fragment的生命周期，在销毁时取消正在执行的任务。2018年最流行的方案是给Activity注册一个不可见的Fragment，利用Fragment的生命周期回调来感知宿主销毁，这也是Glide早期的实现思路。能对着这道设计题说到这个层面，面试官基本就会认为你真正理解图片加载库，而不是只会用。

3.3 开放性简答题：不会的题怎么答才能拿分

笔试里总会有一些你不太会的题目，比如有一道问“Android中为什么主线程不会因为Looper.loop()里的死循环而卡死”，这题看着简单，但真正想答完整也不容易。我当时的思路分三层：第一层说明Looper.loop()确实是一个死循环，会不断从MessageQueue中取消息；第二层说明这个循环是主线程唯一的活路，因为一旦循环退出，主线程就结束了，App也就挂了；第三层是核心，说明主线程之所以没有被这个死循环卡死，是因为当MessageQueue为空时，主线程会调用epoll机制进入休眠状态，释放CPU，而不是忙等，所以不会造成CPU占用过高。

这种回答方式有一个通用模板，我觉得对后来的面试非常有用，叫做“是什么、为什么、底层怎么做”三步法。第一步回答“是什么”，直接给出题目中概念的定义或结论；第二步回答“为什么”，解释这个设计的原因和背景；第三步回答“底层怎么做”，从源码或机制层面展开细节。用这个模板答题，就算你源码细节记得不全，也能给面试官留下“这个学生有系统的认知框架”的印象，拿到大部分步骤分。

还有个技巧是关于填空题和简答题的写法。线上笔试的简答题通常不是选ABCD，而是直接在一个文本框中输入回答，所以你的文字排版很重要。我当时会分点作答，每一点单独一行，关键术语加粗。不要写一大段文字让阅卷人找重点，阅卷人在屏幕上快速扫答案时，分点作答的识别效率远高于大段文字。这套技巧在任何一家公司的线上笔试里都能用上。

4. 常见问题与避坑实录：笔试现场的教训

4.1 时间分配错误：最容易犯的错，几乎没有例外

我发现身边所有参加商汤笔试的同学，出来后吐槽最多的问题都是“时间不够”。选择题里纠结太久，编程题写到一半没时间优化，设计题草草写了两行就交卷，这种情况非常普遍。

我自己的策略是“30分钟死线法”。每道选择题最多给自己2分钟，超过2分钟还没头绪，就随便选一个直觉答案并标记“待检查”，等所有题目做完再回来看。编程题如果15分钟还没思路，先把暴力解法写出来，确保能过一些基础用例，然后如果还有时间再优化成更高效的解法。设计题一定要留足20分钟，因为这道题是拉开差距的关键，哪怕你前面选择题有几道拿不准，只要设计题答得有逻辑，整体分数都不会低。

另外要特别提醒：编程题提交之前一定要自己造几个测试用例跑一遍。我当时就吃过亏，代码逻辑看着没问题，但漏了空数组的边界情况，结果在LeetCode风格平台上得分减半。笔试题的测试用例往往不给你提示，所以你要主动考虑空数组、全负数、只有一个元素、超大数溢出这些场景。

4.2 遇到不会的题，千万别空着不写

笔试和面试有个很大的区别：面试的时候如果你完全不会，强行编可能会留下负面印象；但笔试里空着不写，等于主动放弃了得分机会。尤其是主观简答题和设计题，只要你写的内容沾边，就有可能拿到步骤分。

举个例子，去年我一个学弟也在准备AI公司笔试，他遇到一道“如何优化App启动速度”的简答题，完全没复习过这个知识点，但他按照自己的理解写了：减少Application里不必要的初始化、用懒加载延迟初始化、把耗时操作放到子线程、启动页不要加载过多图片资源。这些答案虽然不完整，但每一条都是正确的优化方向，阅卷人看了就知道这个人是懂Android的。

还有一点：编程题的代码即使报错，也一定要贴上去。我判断阅卷人的批改逻辑是“先看思路是否正确，再看代码是否可运行”。如果你能把思路写清楚，哪怕代码有语法错误，分数也不会全扣。反过来，如果你只写了一个“不会”，那这道题就是0分。

4.3 被忽略的加分项：代码规范与命名习惯

笔试虽然是机器判卷和人工review结合，但你的代码质量在人工review阶段会直接影响主观评价。我当时就因为用了清晰的方法命名和注释，在编程题上拿到了不错的印象分。具体来说，方法名不要叫fun1、fun2，要用能够描述功能的动词加名词，比如findMaxSubarraySum；变量名不要用a、b、c，要用curSum、maxSum这种有语义的命名；关键逻辑处加上一行简短注释，让阅卷人快速理解你的思路。

还有一个容易被忽略的细节是缩进和空行。很多在线笔试平台的代码编辑器不会自动格式化代码，你粘贴上去的代码如果挤成一团，阅卷人看起来非常痛苦。提交前一定要花10秒钟手动整理好代码的缩进和空行，这个动作本身就会让人觉得你是一个注重工程规范的开发者。

4.4 常见丢分点速查表

5. 从2018到当下：这份笔试的参考价值在哪里

这套笔试过去这么多年了，里面很多技术细节已经被Android生态的演进覆盖掉了。比如Kotlin在2019年成为Android开发的主流语言，协程取代了很大一部分线程池和回调的写法，Jetpack Compose从2021年开始逐步替代传统的XML布局体系，现在的Android校招笔试风格和2018年已经有挺大差异。

但我要说的是，底层原理永远是那套东西。Binder还是那个Binder，Handler的消息循环机制没有本质变化，Activity的启动流程也只是加了更多的生命周期状态和兼容性分支。你去看现在大厂的Android面试题，问的最多的依然是“Handler为什么不会卡死主线程”、“Binder为什么比Socket高效”、“App启动流程是怎样的”，这些问题在2018年就被问烂了，现在还在问。

所以我把这场笔试拿出来复盘，重点不是让你去背2018年的真题，而是让你理解一份高质量的Android笔试到底在考什么。它会考你对系统底层的理解，会考你的工程思维，会考你在遇到不熟悉的问题时如何拆解和组织答案。这些能力永远不过时。

另外，2018年商汤笔试里的AI方向内容，在今天已经变得更重要了。现在Android工程师如果懂得对接端侧推理框架、了解模型量化、会做相机流和帧数据的处理，在职场上会非常有竞争力。笔试里如果出现相关场景题，你哪怕只是提到“移动端深度学习模型需要转换为轻量级格式才能在端侧运行”，也能显示出你对公司核心业务的了解，这种“业务匹配度”在筛选过程中会起到关键作用。

6. 给现在准备校招的同学一些实用建议

如果你正在准备Android开发相关的校招笔试，我结合这次复盘和后来几年带新人的经验，给你几条实在建议。

第一，系统梳理底层原理，至少看完Handler、Binder、AMS、WMS这四大源码专题。不需要逐行记住源码，但要能说出关键流程和关键类名。比如聊到Handler，你要能说出Loop、MessageQueue、Message、Handler这几个类的关系，以及epoll机制为什么能让主线程休眠。聊到Binder，你要知道一次拷贝怎么实现的，以及驱动层和用户空间的关系。这部分知识是Android面试的基本盘，学校和培训一般不会讲这么深，但笔试面试一定会考。

第二，把常用的开源库原理搞明白。Retrofit的动态代理和注解解析、OkHttp的拦截器链和连接池复用、Glide的三级缓存和生命周期绑定，这三个是最高频的考点。不要停留在“我会用”的程度，至少要知道它们各自解决什么痛点、核心实现思路是什么。

第三，刷题不能停，但刷法要有重点。校招笔试的算法题不会超纲到竞赛难度，一般就是LeetCode的简单和中等题。你不需要刷完500题，但要把高频题型的套路吃透，比如双指针、滑动窗口、动态规划基础、二叉树遍历、链表操作、排序和二分查找。LeetCode上按“频率”排序刷前100道，基本覆盖了大部分场景。

第四，想清楚自己的定位。如果你目标就是AI公司或者大厂的Android岗，一定要在简历和笔试答案中体现出对业务的了解。比如商汤做视觉，你可以在回答性能优化题时提到“相机预览帧数据处理”、“YUV转RGB”、“内存复用”这些与图像相关的关键词，这会让你在一堆只会Java语法的人里面瞬间被注意到。

最后再说一句关于心态的话。笔试没通过不代表你不适合做Android，有时候就是时间没分配好、某类题型恰好没复习到。我当年也栽过好几家公司的笔试，后来每次复盘都发现自己其实离通过只差一点点。把这个过程当成打怪升级，每一场笔试都会让你离offer更近一步。