30、AMS 面试高频题：Activity启动流程、进程保活、ANR分析、LaunchMode区别
好，终于到了最后一章。说实话，能把AMS系列坚持看到这里，你已经具备了相当扎实的功底。这一章我们不聊新概念，而是把面试中最常被问到的四个硬骨头——启动流程、保活、ANR、LaunchMode——串起来讲一遍。
我个人习惯在面试别人时，先问一个简单的LaunchMode区别，然后顺着启动流程往下挖，最后冷不丁抛出一个ANR场景。为什么？因为这几个点看似独立，其实底层都绕不开AMS那套调度逻辑。你想想看，启动流程走的是ActivityRecord的创建与栈管理，保活拼的是进程优先级与Binder心跳，ANR本质上是超时检测机制在某个环节触发了。它们共用同一套进程模型和消息队列机制。
Activity启动流程：从startActivity到onResume
启动流程我建议你记住两个关键阶段：跨进程通信阶段和生命周期调度阶段。面试官通常不会让你背源码行号，但希望你讲清楚谁调了谁，以及Binder在其中扮演的角色。
核心链路（简化版）
- App进程通过Binder调用AMS的startActivity
- AMS解析Intent，检查目标Activity是否存在、权限是否通过
- AMS计算目标Activity所在的进程（如果进程未启动，则先fork新进程）
- AMS通过ApplicationThread（也是Binder）通知App进程创建Activity
- App进程内部通过ActivityThread的handleLaunchActivity完成onCreate、onStart、onResume
我在项目中遇到过一个问题：冷启动时Activity黑屏时间过长。排查后发现是AMS在第三步做了大量PackageManager查询，加上Intent Filter匹配耗时。后来我们用了预创建ActivityRecord缓存，把启动时间压了30%。
这里有个细节很多人会忽略：AMS与App进程之间的通信是异步的。AMS发完创建指令后不会傻等，而是通过scheduleLaunchActivity把任务丢给App主线程的Handler。所以启动流程的耗时大头其实在App进程内部——onCreate里做太多事，才是启动慢的元凶。
进程保活：不是技术狂欢，是系统博弈
进程保活这个话题，说实话有点灰色。我见过不少开发者为了保活，用上了双进程守护、前台Service、JobScheduler轮询，甚至监听系统广播拉起自己。但Android系统从6.0开始就一直在收紧这些口子。
保活的核心逻辑其实很简单：让系统认为你的进程值得保留。AMS内部维护了一个进程优先级列表，从前台进程到空进程一共五级。优先级越高，被杀的几率越低。
| 优先级等级 | 典型场景 | 被杀概率 |
|---|---|---|
| 前台进程 | 用户正在交互的Activity、前台Service | 几乎不会 |
| 可见进程 | Activity处于onPause但依然可见 | 低 |
| 服务进程 | 后台Service（startService启动） | 中等 |
| 后台进程 | Activity已onStop，不可见 | 高 |
| 空进程 | 没有任何组件运行 | 最高 |
我曾经踩过一个坑：为了保活，在Service的onStartCommand里返回START_STICKY，以为这样系统会重启Service。结果发现Android 8.0之后，后台Service启动限制加上省电策略，START_STICKY基本失效。后来改用WorkManager配合前台通知，才勉强达到预期。
说白了，保活这件事要跟系统做朋友，而不是做敌人。合理使用前台Service（带通知）、利用JobScheduler做周期性任务、在onTrimMemory里释放资源让系统觉得你“懂事”，这些才是正道。
ANR分析：别慌，先看traces
ANR（Application Not Responding）是面试高频题，也是线上问题的常客。AMS检测ANR的机制其实很简单：超时+无响应。具体来说，AMS在发送关键消息（如广播、输入事件、Service启动）时会设置一个定时器，如果在规定时间内没有收到App的完成信号，就判定ANR。
常见的ANR类型和超时时间：
- 输入事件无响应：5秒
- 广播接收器未完成：前台广播10秒，后台广播60秒
- Service启动超时：20秒
- ContentProvider超时：10秒
分析ANR时，我建议你按以下步骤来：
- 先看
/data/anr/traces.txt文件，找到主线程堆栈 - 确认主线程是否在等锁（比如等一个被子线程持有的锁）
- 检查主线程是否有耗时操作（网络请求、大文件读写、Bitmap解码）
- 看CPU负载和IO情况——有时候不是你的代码慢，是系统整体卡顿
我个人习惯：在线上环境中，我会在Application里注册一个自定义的ANR监控，利用FileObserver监听traces文件变化，或者用消息队列的IdleHandler检测主线程卡顿。这样能比系统ANR弹窗更早发现问题。
嗯，这里要注意：ANR不一定是主线程阻塞。有时候是CPU被其他进程占满，你的线程根本抢不到时间片。这种情况在低端机上特别常见。我曾经遇到一个案例，用户手机装了上百个App，后台进程疯狂跑，我们的App主线程明明只做了个简单的setText，却触发了ANR。最后定位到是系统整体负载过高，跟我们的代码关系不大。
LaunchMode区别：栈管理是门艺术
LaunchMode是面试的入门题，但能讲深的人不多。标准模式、SingleTop、SingleTask、SingleInstance，这四种模式的区别，说白了就是Activity在栈里的复用策略。
| 模式 | 行为 | 典型场景 |
|---|---|---|
| Standard | 每次启动都创建新实例，压入当前栈 | 普通页面，如列表页 |
| SingleTop | 如果栈顶已经是该Activity，复用并回调onNewIntent；否则创建新实例 | 推送通知跳转，避免重复创建 |
| SingleTask | 如果栈中存在该Activity，将其上方的Activity全部出栈，复用并回调onNewIntent | 主页面、首页 |
| SingleInstance | 该Activity独占一个独立的任务栈，且栈中只有它自己 | 来电界面、系统级弹窗 |
面试官如果继续追问，通常会问taskAffinity和allowTaskReparenting。这两个属性配合LaunchMode，能玩出很多花样。比如你希望一个Activity从浏览器启动时在浏览器栈里，但从桌面启动时回到自己的栈——这就是allowTaskReparenting干的事。
我在项目中遇到过一个问题：使用SingleTask的Activity在onNewIntent里没有更新UI，导致用户从通知栏跳转后看到的还是旧数据。排查后发现onNewIntent确实被调用了，但setIntent没有执行，导致getIntent返回的还是旧Intent。解决方案是在onNewIntent里手动调用setIntent，然后刷新页面。
避坑指南：
- SingleTask配合
FLAG_ACTIVITY_CLEAR_TOP使用时，注意onNewIntent的调用时机 - SingleInstance的Activity无法启动其他非SingleInstance的Activity，除非指定新任务栈
- Standard模式在ApplicationContext中启动会报错，因为缺少任务栈——需要加FLAG_ACTIVITY_NEW_TASK
一张图串起所有知识点
下面这张SVG图，我把启动流程、进程保活、ANR检测、LaunchMode栈管理放在了一起。你可以把它当作AMS面试的“思维导图”。
你看，这四个考点其实是一个闭环。启动流程是入口，保活是生存保障，ANR是异常检测，LaunchMode是栈管理策略。面试官问任何一个点，你都可以往其他三个方向延伸，展示你的知识广度。
最后说一句：AMS的源码确实庞大，但不要被吓到。抓住几个核心类——ActivityRecord、TaskRecord、ActivityStack、ProcessRecord——然后顺着Binder调用链路往下读，你会发现其实逻辑很清晰。我当年啃AMS源码时，就是先画了一张调用时序图，然后一行一行跟代码，花了大概两周时间才理清楚。嗯，这个过程很痛苦，但值得。
面试小技巧：当被问到“Activity启动流程”时，不要一上来就背源码。先问面试官：“您想听完整版还是精简版？” 然后根据对方反应调整深度。如果对方说精简版，你就讲三段式：AMS校验→进程创建→生命周期。如果对方说完整版，你再把Binder调用细节、Intent Flag影响、栈管理逻辑都铺开讲。
好了，AMS系列到这里就结束了。希望这些内容能帮你在面试中游刃有余，也能在实际开发中少踩一些坑。记住，理解原理比背代码更重要——因为需求会变，但底层逻辑不会。