性能排障：统一检查链与常见场景

前七章把性能与稳定性拆开讲完了。这一章把它们串成一条可执行的检查链：遇到 ANR、卡顿、 闪退、OOM，按什么顺序查、看什么证据、怎么定位。

统一流程不是给所有问题抓同一组数据，而是先分类再选择证据。修复结论必须能解释原时间线， 并在同设备、同场景和同指标下完成回归，否则只能说明现象暂时没有出现。

证据不足时不要直接归因

常见误解	正确理解
性能问题都要“重新写一遍”	多数问题可以定位到具体线程、锁、I/O 或绘制
logcat 与 trace 二选一	它们互补：logcat 给事件，trace 给时间线
修好一次就结束了	要回到同一场景复现，确认根因被消除

核心结论

1. 五步检查链：分类 → 时间线 → 证据 → 根因 → 回归。
2. 证据三件套：logcat（事件）、Perfetto（时间线）、dumpsys/文件（状态）。
3. 常见根因池：主线程阻塞、锁竞争、GC/内存、I/O、调度、渲染超预算。
4. 复现是前提：不能复现的问题先造环境，别靠猜。
5. 修复后必须回归：同场景对比，确认数据改善。

五步检查链

逐步解释：

1. 分类：确定是超时、掉帧、崩溃还是资源耗尽。
2. 时间线：用 Perfetto 还原故障前后。
3. 证据：线程状态、帧时间、内存占用与堆栈。
4. 根因：落到具体线程、锁、I/O 或渲染环节。
5. 回归：同场景复现，对比修复前后。

常用命令与证据

环境：开发设备或模拟器；部分命令需要 root。

adb logcat -v threadtime -d | grep -E "ANR|FATAL|OutOfMemory|lmkd|am_kill"
adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto-trace \
  -t 10s sched freq idle atrace am wm view input gfx
adb shell dumpsys gfxinfo <包名>
adb shell dumpsys meminfo <包名>
adb shell ls /data/anr/ /data/tombstones/ 2>/dev/null

证据	回答的问题
logcat 关键字	发生了什么事件、何时发生
Perfetto 时间线	哪个线程卡住、卡了多久、在等什么
gfxinfo	帧是否超预算、掉帧比例
meminfo	内存是否异常增长
ANR/tombstone 文件	超时与崩溃的现场堆栈

常见场景与定位思路

场景一：偶发卡顿

先确认是不是掉帧（gfxinfo），再用 Perfetto 找掉帧瞬间的线程状态。偶发卡顿多为 GC、调度抢占或瞬时 I/O，看“那一次”时间线最有效。

场景二：持续卡顿

持续掉帧查绘制复杂度与布局层级，配合 Profile GPU Rendering 与帧时间线。 持续卡顿的根因通常在代码结构，而不是偶发资源竞争。

场景三：ANR

先读 ANR 文件确认类型与主线程栈，再看锁持有者与 Binder 状态，最后用时间线还原。 不要只看栈顶，要看“谁在等谁”。

场景四：闪退

区分 Java 与 native：FATAL EXCEPTION 还是 tombstone。闪退先收集现场，再关联 复现步骤与内存/CPU 证据。

场景五：启动慢

用 am start -W 量化，用 Perfetto 启动轨道分段，再针对最长的一段优化。 启动问题要先分段，不要盲改 Application。

常见误区

1. “logcat 就够”：时间线才是根因证据。
2. “不能复现也能修”：先造环境复现，再动手。
3. “卡顿都是主线程”：合成、GPU、调度都可能。
4. “改完就完事”：必须回归对比。
5. “工具越多越好”：按分类选工具，少而准。

延伸问题

1. 如何设计一套可重复的性能回归基准？
2. 线上问题与线下复现的证据链有什么不同？
3. 如何用自动化抓取 ANR/掉帧现场？
4. 多设备矩阵下如何收敛性能差异？

源码入口

文件	关键位置	作用
ActivityManagerService.java	ANR/崩溃处理	超时与恢复
Choreographer.java	doFrame()	帧时间
libs/frametimeline/	帧记录	掉帧判定
system/core/debuggerd/	tombstone	崩溃现场

公共路径沿用本系列各章。行号以 r75 检索为准。

系统服务维度的综合排障入口，见 系统调试与排障。