2022届校招，我把联想集团Android开发岗作为重点目标之一。当时刷了一圈社媒上的面经，发现这个岗位的面试很少直接考“背答案”，更多是借一个项目、一个现象把问题打到源码级别。整场面试走下来，我最大的感受是：联想校招Android不看你简历上堆了多少技术名词，而是看你能不能把一个App从启动到卡顿、从构建到混淆的整条链路讲明白。这篇文章把投递、笔试、一面、二面、HR面里被反复追问的技术点完整复盘一遍，如果你也在准备Android校招，尤其想投联想移动端、系统定制或者车机方向，这篇应该能帮你跳过一些踩过的坑。
1. 投递与笔试：联想校招Android岗的第一道坎
1.1 校招官网选岗：Android并不只是写App
联想校招的Android岗位分散在不同事业部，官网上能看到的方向大致分三类：摩托罗拉移动业务的应用层开发，平板和智能IoT设备的系统应用开发，以及车计算/智能座舱这类偏底层和Framework定制的方向。这里有一个很容易被忽视的细节：同样是Android开发岗，不同部门的面试侧重点差别很大。
- 应用层岗位：重点是Jetpack、性能优化、多线程、网络与存储。
- 系统应用/定制岗位：重点是AMS、WMS、SystemUI、开机启动流程、OTA。
- 车机方向：会加问AAOS（Android Automotive OS）、CarService、外设调试。
我当时第一志愿填的是摩托罗拉移动业务的应用开发，第二志愿选了系统应用方向，结果两轮技术面刚好一条主线一个副线，都被问到了。
简历这一关我想多说一句。校招简历不要写“熟悉Android”“精通Java”这种没有证据链的话，面试官一旦按这个“熟悉”去深挖，招架不住的还是自己。建议每段项目都写成“背景-难点-方案-结果”的结构，尤其是“难点”要具体到技术层面，比如“列表滑动掉帧”“多包混淆后崩溃无法定位”，而不是“提升了用户体验”这种空话。
1.2 在线笔试：基础题的覆盖面比想象中大
笔试是统一在线测评，我走的那场大概是90分钟，题型是选择题加两道编程题。选择题分布在Java基础、数据结构、计算机网络、Android四大组件这几个方向，难度不算高，但覆盖面很宽，比如会问HashMap在JDK 8里链表转红黑树的阈值、TCP挥手时TIME_WAIT的意义、Activity的启动模式区别这类题。
编程题更接近LeetCode的中等偏低难度，用的牛客网在线IDE，需要自己写输入输出。这里提醒一句：平时练习如果习惯了LeetCode那种已经封装好的函数签名，一定要提前去牛客刷几道带输入输出的题，否则笔试现场很容易在Scanner读入和while循环上翻车。我当时就遇到了一道字符串处理题，leetcode式写法十分钟能写完，但在线IDE里调试输入输出格式花了快二十分钟。
另外有一点值得注意，联想的笔试系统会检测切屏，答题时不要习惯性去查资料，踏踏实实做题就好。选择题里不确定的题先标记，最后统一回看，别在单题上卡太久。
2. 一面复盘：从“App是怎么启动的”开始连环追问
2.1 自我介绍定调：别给自己挖坑
一面开头是常规自我介绍。这里我的教训是：自我介绍里提到的每一个技术词，都要做好被追问的准备。我当时顺口说了一句“对Android Framework层比较感兴趣”，面试官眼神一下就亮了，接着就问“那你说说一个App从桌面图标点击到界面显示，系统做了哪些事情”。这句话直接决定了后面整整四十分钟的走向。
所以介绍自己时，与其说“我熟悉Handler机制”“我了解AMS”，不如主动把话题引到做过的东西上，比如“我在项目里用System Trace定位过一次卡顿问题”。面试官后续大概率会顺着这条主线继续深挖，你就可以在自己真正动手做过的领域里发挥。把自我介绍当成“定调”而不是“报菜名”，这个意识应该提早在模拟面试里练起来。
2.2 Handler机制里的连环炮：Looper、同步屏障与消息池
Handler是我一面里被问得最细的一块，也是Android面试的保留项目。面试官一般会从“子线程能不能创建Handler”开始，一路问到“主线程Looper死循环为什么不会卡死”。
先说子线程能不能new Handler的问题。直接new会抛“Can't create handler inside thread that has not called Looper.prepare()”，原因很简单：Handler要通过Looper.myLooper()拿到当前线程的Looper，而子线程默认没创建Looper。子线程要用Handler，必须先Looper.prepare()再Looper.loop()。这个过程在面试里最好能当场画出来，核心是ThreadLocal里存了Looper实例，每个线程各一份。
主线程的Looper是在ActivityThread.main()里通过prepareMainLooper()创建的，随后调用Looper.loop()进入死循环。面试官真正想听的其实是：为什么死循环不卡死？因为MessageQueue在无消息时通过epoll机制让线程休眠，不占用CPU，有消息时再被唤醒，所以循环本身不构成性能问题。顺带补充一句，ANR不是Looper循环卡住，而是某个消息处理超过了系统阈值，导致后续消息无法及时分发，前台输入事件5秒没处理完就会弹ANR。
再深一层，面试官还问过消息池复用和同步屏障。消息池是Message.obtain()从链表复用Message对象的机制，避免高频消息创建造成GC压力，所以在post一个Runnable时，目标消息的what等字段需要重置。同步屏障则是优先执行异步消息的一种手段，常见的应用场景就是UI绘制帧回调——系统插入同步屏障，让VSync信号相关的异步消息插队处理。
还有一个高频变形题：“Handler.postDelayed是怎么实现延迟的？”本质是MessageQueue根据when字段做按时间排序，没到时间的消息就阻塞等待，所以在延迟消息队列里插入一个立即执行的消息，并不会立刻打断前面的延迟。这几个点串起来，Handler基本就稳了。
2.3 Activity启动流程：这道题能串起半部Android
Activity启动流程是我一面面试官最满意的一道题，因为它天然覆盖了Binder、进程、Handler、四大组件、生命周期、窗口机制，一串下来能看出一个人的底层功力。
我当时按这个顺序讲的：
- 调用方进程通过ActivityTaskManager.getService()得到ATMS的Binder代理，调用startActivity发起IPC请求。
- system_server进程中的ActivityTaskManagerService收到请求，做权限校验和Intent解析。
- 如果目标Activity所在进程不存在，就请求Zygote进程fork出新进程。
- 新进程入口是ActivityThread.main()，创建Application和主线程Looper。
- ActivityThread通过Binder向system_server回传ApplicationThread代理，完成双向绑定。
- system_server通过ApplicationThread.scheduleLaunchActivity发起真正启动，主线程Handler收到消息后执行performLaunchActivity。
- 创建Activity实例和PhoneWindow，执行onCreate、onStart、onResume。
- ViewRootImpl.performTraversals完成首帧绘制，界面才真正显示出来。
注意，现在老面经里还在大量写AMS，其实从Android 10开始，Activity任务栈管理已经拆给了ActivityTaskManagerService（ATMS），“AMS启动Activity”这种说法严格来说已经过时了。面试里如果你能主动说出来这个演进，会显得你是读源码追到新版本的，而不是背的旧八股。关于binder的部分，我还用了一个类比：客户端像前台顾客，服务端像后厨，Binder是传菜电梯，一次系统调用就把请求送过去，不用像传统管道那样来回多次拷贝。Binder还带内核鉴权，比共享内存安全，所以Android选它做IPC主力。
3. 项目深挖：面试官为什么揪着你的代码不放
3.1 从“列表卡顿”开始的项目复盘
一面后半段是项目深挖。我当时讲的是一个校园工具类App，列表页展示资讯流，带图片加载和搜索。面试官没有让我把项目背一遍，而是直接问：“这个列表页在什么情况下会觉得卡？你怎么定位？”这个问题看起来开放，实际上是想考察你对自己的代码到底有没有认知。
我当时踩过的真实问题是：图片加载用的是非异步方式进行圆角裁剪，每张图滑动时都会在主线程做一次Bitmap的decode和clipPath，列表自然掉帧。定位方式是先用Android Studio的Layout Inspector看布局层级，发现每个列表项嵌套了五层ViewGroup；再用GPU渲染模式分析看渲染耗时；最后用CPU Profiler的System Trace录了一段滑动操作，火焰图里主线程反复出现自定义View的onDraw耗时。
荧光图这里多说一句，Android Studio的火焰图横轴是时间占比，纵轴是调用栈，顶部越宽说明这个函数在采样里占的时间越长。看到某个宽条长时间停在自己的自定义View上，十有八九就是布局或绘制有问题。改法也简单：圆角图换方案，缩略图统一压缩成RGB_565，减少主线程decode；布局层级用ConstraintLayout重写，砍掉两层嵌套。改完后用Profile在真机上对比，滑动的帧耗时降了一半，肉眼不再有丢帧感。
面试官随后问了一句“你怎么证明这个优化是有效的”，这里一定要有数据支撑，不能只说“感觉流畅了”。我提了三个指标：掉帧数、卡顿率、主线程耗时占比，每个都能从Profiler里导出报告。面试官听完点了点头——证明优化有效，比优化本身更重要。
3.2 MVVM架构：不能只说“我用过”
项目里如果写了MVVM，面试官大概率会追问两个问题：为什么用MVVM，以及ViewModel为什么在屏幕旋转后数据还在。第一个问题回答思路不是“因为它是官方架构”，而要落到实际痛点：业务逻辑和UI强耦合、Activity重建后数据丢失、代码没法单元测试。
ViewModel在旋转后不丢数据，本质是因为ViewModelStore把实例存放在Activity的NonConfigurationInstance中，配置变更重建Activity时会找回同一个store，所以ViewModel实例还活着，里面的LiveData数据和协程任务都得以保留。面试官如果接着问“那Activity什么时候会真的销毁ViewModel”，答案是Activity.finish()，因为这时ViewModelStore被清空，onCleared会触发。
资深一点的面试官还会追一个坑：LiveData的事件粘性问题。比如用LiveData发一个一次性“提示事件”，Activity旋转前已经消费过，旋转重建后新的Observer进来会立刻收到旧事件，导致提示重复弹出。这也是MVVM项目里很典型的坑，解法是引入一次性事件包装类或者用Flow的Channel。能讲到这里，说明你是真的在项目里踩过坑，而不只是照着模板敲了一遍。
3.3 内存泄漏：现场讲LeakCanary的原理
项目深挖的另一个高频方向是内存泄漏。我面试时被问到“你在项目里遇到过泄漏吗”，我讲了一个Handler匿名内部类持有一个大对象导致的泄漏：页面已经销毁了，但Handler里还排着延迟消息，消息持有handler引用，handler持有Activity引用，Activity就永远无法回收。修复就是静态内部类加WeakReference，并在onDestroy把消息remove掉。
面试官不满足于“怎么修”，继续追问“LeakCanary为什么能检测到泄漏”，这是一道很好的原理题。LeakCanary的核心链路是：通过Application注册Activity生命周期监听，在onDestroy后把Activity放进ObjectWatcher，等几秒再触发一次GC，如果对象仍然没有被回收，就导出一份heap dump，然后通过shark库分析引用链，最终展示“Activity被谁持有”的路径。这个监听-检测-堆转储-引用链分析的思路，放在任何内存问题现场都通用。
4. 二面与跨部门：构建工具、系统定制和车机方向的追问
4.1 Android Studio版本和AGP版本的兼容性：一个真实翻车现场
二面面试官来自系统定制方向，没有像一面那样按常规面经出牌，而是先和我聊了一轮工程化问题，其中第一个问题就让我意识到，只知道Android Studio“能用”是不够的。
他问的是：“你项目里Android Studio用的什么版本？AGP对应多少？如果现在把AGP升到8.3，你觉得会不会出问题？”我当时项目用的是Android Studio Hedgehog 2023.1.1 Patch 2，AGP是8.2，我其实没有实际升级过，差点翻车。面试后我专门做了功课，这里直接把结论分享出来：
- Android Studio Hedgehog（2023.1.1）官方兼容的AGP版本上限是8.2。如果settings.gradle里把AGP声明成8.3，Studio大概率会直接报“This version of Android Studio cannot open this project, please retry with Android Studio Iguana or newer”。
- AGP 8.3对应需要Gradle 8.4以上，且JDK必须17。
- AGP版本和Studio版本是强绑定的，Studio通常向后兼容旧AGP，但不能向前兼容更高AGP。
所以面试里遇到“为什么不敢随便升级AGP”，核心原因就是构建链有四层约束：JDK版本、Gradle版本、AGP版本、Android Studio版本，只要有一层不匹配，Sync就是红。多项目开发时，团队还要统一这四者的版本，否则很容易出现张三能跑李四跑不了的问题。我后来把团队的Android构建版本规范整理成一份表，贴在项目文档里，再也没出过类似问题。
这个话题带出一个搜索热词“Android Studio中文设置”。很多新手上来就装汉化包，这没问题，但我建议术语部分还是要习惯看英文界面，因为面试官问的是“System Trace”“Layout Inspector”“Gradle Sync”，你如果一脸茫然只记得中文翻译，现场会很吃亏。工具层面可以汉化，英文术语必须能听懂。
4.2 R8与多包混淆：海外业务App的隐藏考点
联想旗下有moto的海外业务，App上架海外应用商店时要考虑多语言、不同渠道包和代码混淆，所以二面里“R8与混淆”成了一个重要考点。面试官问的问题很有业务味：“你发布一个release包，崩溃日志里全是a.a.a这种看不太懂的方法名，怎么快速定位到原始代码？”
这里要先解释清楚，AGP 3.4之后默认用R8替代了ProGuard，R8不只是混淆，还集成了压缩、优化、脱糖。压缩会移除没有被引用的代码，这也是为什么很多反射调用在release包下会崩的原因——R8认为代码没人引用就直接删掉了。
多包项目的坑更隐蔽。业内经常说的“同源多包”指的是同一套核心代码出多个应用包，只是包名、SDK配置和部分资源不同。这种项目里如果混淆配置没有区分好，会出现A包正常B包崩溃的诡异问题。因为buildTypes和productFlavors的proguard文件需要分别配置，keep规则如果只在主工程写了，某个渠道的consumer rules没带上，这个渠道的反射类就被混淆了。
实践里最稳的方案是：所有会被Gson/反射/注解处理的类，统一用@Keep标注；序列化数据模型同时写keep规则兜底；多包差异化的代码独立放一个模块，各自声明自己的proguard文件。release版的崩溃栈要先拿到build/outputs/mapping/release/mapping.txt，用SDK里的retrace工具还原混淆名，否则你对着a.b.c这种方法名根本无从下手。我在项目里踩过一次Gson解析全字段为null的坑，就是因为JavaBean字段名被混淆乱了，从那以后数据类一律@Keep加keep规则双保险，再没出过问题。
4.3 系统定制方向：从Settings布局到OTA、APEX与底层调试
二面后面半段明显偏系统定制，因为联想除了手机业务，平板、智能IoT和车机方向都会涉及系统级Android开发。这些问题如果你投的是应用层岗，可能只是加分项；但如果投的是系统方向，这就是主菜。
面试官先是让我对比了普通App和系统应用的开发差异。以Settings为例，它本质上也是一个Android应用，只是拥有系统签名和更高权限，里面大量使用PreferenceFragment和PreferenceScreen来组织多级设置页面。要做系统级设置项，通常是改SettingsProvider或者在Settings的布局xml里增加Preference节点，同时适配不同版本的权限管控。
随后聊到了OTA升级。这里有一个很值得展开的点：Android从Android 7开始支持A/B分区，手机里同时存在A和B两个系统分区，升级时往未使用的B分区写入新系统，完成后切换启动槽位，如果新系统启动失败还能自动回滚到A分区。Android 10之后又有了Virtual A/B，不再需要完整镜像占用两块同样大小空间，而是通过合并快照完成。面试官问“如果升级到一半断电了会怎样”，答案就是依靠槽位切换和启动校验来保证系统不会变砖。
APEX是Android 10引入的另一个机制，它把一些系统组件打包成apex格式，可以像普通App一样独立升级，而不需要等整个系统分区OTA。简单理解，APEX就是把原来焊死在system里的模块变成了可替换的零件。面试时能讲出“APEX和APK都能升级，但APEX更新的是系统级模块，挂载机制和签名校验完全不同”，面试官就会觉得你不是只背了名词。
如果投的是更底层的岗位，还会看到i2c-tools和OpenOCD这种工具。i2c-tools在Android上的使用通常是交叉编译出arm64版本，然后adb push到/data/local/tmp，用i2cdetect探测I2C总线上的设备地址，调试触摸屏、电源管理芯片这类外设时非常有用。OpenOCD则是配合JTAG/SWD做板级调试的工具，常见于驱动开发和低功耗分析场景。对应用开发背景的人来说，这块属于“认识不出错”的程度就行，真正深入测试还是驱动工程师的活。
硬件相关方向还有一个高频题目是蓝牙和电话状态监听。普通App开发主要接触BLE，比如GATT连接、MTU协商、动态申请权限；传统电话状态监听用的是PhoneStateListener，通过TelephonyManager注册，可以监听空闲、响铃、通话中等状态。不过新版Android更推荐用TelephonyCallback替代PhoneStateListener，面试时如果说得出这个演进，会加分不少。
4.4 行业横向问题：Android 14、iOS和HarmonyOS NEXT
二面最后聊了几个开放性话题，这类问题没有标准答案，主要看你平时是否关心技术生态。面试官问了两个：Android 14有哪些你关注的变化？如果让你把Android应用迁移到HarmonyOS NEXT，你从哪里入手？
Android 14我当时提到了几个点：前台服务类型限制更严了，后台启动限制继续收紧；动态图标主题（Material You）有了更多可定制选项；部分照片和视频的访问权限通过READ_MEDIA_VISUAL_USER_SELECTED做选了再授权，不再要求一次性授予整个媒体库权限。如果做过主题类应用或者文件类应用，这些变化会直接影响功能设计。
跨端迁移的问题不需要站队，重点是展示迁移思路。我会先梳理原应用里哪些模块依赖Android系统的独有机制，比如各种Manager、ContentProvider、隐式Intent；再对照HarmonyOS NEXT的声明式UI和分布式能力，评估业务层和数据层怎么抽成平台无关的模块。核心思路是“先分层，再迁移”，让面试官看到你平时思考过这类问题就足够了。
5. HR面与Offer选择：技术面之后还有值得较真的细节
5.1 HR面：把这些事问清楚，比纠结薪资更实际
技术面通过后，HR面相对轻松，但信息量很大。除了常规的“你手里还有哪些offer”“为什么选择联想”“能接受工作地点调剂吗”，HR面其实是双向交流的机会，一定要主动问清楚几个直接影响后续体验的问题：具体在哪个城市哪个园区、加班强度怎样、公积金缴纳比例、试用期薪资是否打折扣、入职后部门方向是业务迭代还是做产品创新。
地点这一点特别重要。联想同一个Android岗位可能在北京、深圳都有坑，不同base的团队做的事完全不同。技术面聊的内容偏系统定制的，大概率是深圳或北京的底层团队；偏应用和业务的是摩拖罗拉移动那边。建议在HR面确认清楚，别等到入职才发现岗位方向和自己预期的差异很大。
谈薪的时候有一个实用技巧：不要直接说“这是底线”，而是给出一个基于调研的合理区间，然后强调自己对这个业务方向的兴趣，并提到“我同时也在对比其他家，但更倾向于联想，因为XX”。这样既表达了诚意，又保留了议价空间。校招薪资浮动空间不会太大，但签字费、股票这些非固定结构有时候是可以聊的。
5.2 职业发展：Android这份工作，为什么依然值得做
HR面之后我自己也反复想过一个问题：国产系统和跨端框架都出来了，Android校招还值得投吗？我可以明确说，值得。Android的应用层需求确实在向Flutter、Compose这种声明式UI演进，但底层岗位——系统定制、车机、IoT、多屏交互——对Android原生人才的需求反而在增加。车载座舱现在普遍是AAOS，系统需要有人做Launcher定制、CarService服务、OTA链路、外设适配，这些不是跨端框架能替代的。
联想这类硬件厂商更明显，整机、平板、手机、车机都有Android的实际装机量，一旦涉及到具体机型、传感器、电源、蓝牙配对这类问题，就必须回到系统层的Android开发。应用层更新换代快，但系统层的根基一直很稳。
5.3 给下一届的建议：把“用过”变成“定位过”
二面结束后的等offer阶段，我给自己做了一次系统的复盘，整理出了几个对后续校招同学可能有用的建议。第一，项目深挖能力比堆叠知识点重要，面试官不用你证明学过所有框架，但一定要能证明定位过真实问题；第二，构建链路的坑值得提前踩一遍，从创建工程到打包release、看混淆日志、分析崩溃栈，每一步都亲手走通，这种工程化经验在面试里很值钱；第三，定期写技术复盘，哪怕只是自己的Markdown笔记，把排查链路、火焰图截图、版本兼容表存下来，面试前快速翻一遍，比临时刷八股文有效得多。
准备面试阶段，我还做了一件事：录制了自己的自我介绍，反复听，删掉所有“我觉得”“可能吧”这种语气词，确保两分钟内把亮点讲完，并且每一句话都有后续展开的空间。小技巧是每天对着手机讲两遍，一周后你会明显感觉到语言比第一版流畅很多，人也自信不少。
复盘整轮联想校招，我最大的收获不是某一轮面试结果，而是那些被面试官追问到源码层面的瞬间，逼着我从“这个功能能跑”走向“这个功能为什么能跑”。这种从应用层往下钻的视角，直到现在做Android开发都还在受益。如果你也正在准备校招，别怕被问倒，能把不会的题在面试后变成一篇笔记，这场面试就已经值回来了。
