3. 稳定性问题分类
在 Android 系统服务稳定性调试中，第一步不是急着抓日志，而是把问题归入正确的类别。因为不同类别的问题，其触发路径、证据形态、定位工具和修复策略完全不同。崩溃、ANR、死锁、内存泄漏、Watchdog、Native Crash 并不是彼此孤立的“故障名词”，它们常常处在同一条因果链上：内存泄漏可能引发频繁 GC 与主线程卡顿，进而触发 ANR；ANR 若发生在系统服务关键线程，可能被 Watchdog 判定为超时；而死锁则可能同时表现为 ANR 和 Watchdog 超时。理解这些关系，是建立稳定调试直觉的核心。
一、核心原理：六类问题的本质与边界
从系统服务视角看，稳定性问题可以按“异常发生的层次”和“表现形态”两个维度来划分。Java/Kotlin 层崩溃通常由未捕获异常导致进程终止；ANR 是主线程或关键线程在规定时间内未完成消息处理；死锁是多个线程互相持有对方所需锁，形成永久等待；内存泄漏是对象无法被回收，导致堆持续增长；Watchdog 是系统对关键服务线程的主动监控机制，超时后会重启系统或服务；Native Crash 则是 C/C++ 层信号异常，如 SIGSEGV、SIGABRT。
这六类问题最容易被混淆的地方在于：它们经常以“表象”出现。例如用户看到的是“系统界面无响应”，但根因可能是 Native 层内存越界导致 system_server 崩溃，也可能是 Binder 线程池耗尽导致服务调用阻塞。因此，分类不是贴标签，而是建立从现象到根因的映射路径。
二、方法流程：从现象到分类的判定路径
面对一个稳定性问题，建议按以下顺序进行判定，避免一开始就陷入细节：
- 确认进程与线程：先看是应用进程、system_server 还是某个 native 服务进程。进程不同，日志入口和工具链不同。
- 看 tombstone 与 dropbox：/data/tombstones/ 下有 native crash 记录；/data/system/dropbox/ 下有 system_server 的 watchdog、ANR、crash 记录。
- 区分“主动重启”与“被动崩溃”：Watchdog 触发的重启会在 logcat 中打印 “Watchdog: *** WATCHDOG KILLING SYSTEM PROCESS ***”，这是主动行为，不是随机崩溃。
- 检查 ANR traces：/data/anr/traces.txt 或 traces_xx.txt 中查看主线程堆栈，判断是锁等待、IO 阻塞还是 Binder 调用卡住。
- 结合内存与 GC 日志：若 ANR 前有频繁 GC 或 heap 持续增长，优先怀疑内存泄漏。
关键命令示例：
# 查看 tombstone 列表
adb shell ls -lt /data/tombstones/
# 拉取 dropbox 中的 watchdog 记录
adb shell dumpsys dropbox --print system_server_watchdog
# 查看 ANR traces
adb shell cat /data/anr/traces.txt
# 查看系统服务线程状态
adb shell debuggerd -b $(pidof system_server)三、案例/场景：一次“系统界面无响应”的完整归因
某设备在压力测试下出现 SystemUI 无响应，用户看到导航栏卡死。初步抓取 logcat 发现：
W Watchdog: *** WATCHDOG KILLING SYSTEM PROCESS ***
W Watchdog: Blocked in handler on monitor thread
E ActivityManager: ANR in com.android.systemui
E lowmemorykiller: Kill 'com.android.systemui'进一步查看 traces，发现 SystemUI 主线程阻塞在 Binder 调用上，等待 system_server 的 ActivityManagerService。再查 system_server 的 watchdog 记录，发现 ActivityManagerService 的 main thread 被一个长耗时操作占用，而该操作又在等待一个被 Native 层持有的锁。最终定位为 Native 层某个 HAL 接口在异常路径下未释放 mutex，导致 Java 层 Binder 调用超时，进而引发 ANR 和 Watchdog 连锁反应。
这个案例说明：表象是 ANR，触发是 Watchdog，根因在 Native 死锁。如果只盯着 ANR 日志，就会错过真正的修复点。
四、误区与复盘：分类中最容易犯的错
| 误区 | 正确做法 |
|---|---|
| 看到 ANR 就只查应用主线程 | 系统服务 ANR 要同时查 Binder 线程池、system_server 锁状态和 native 调用栈 |
| 把 Watchdog 当成独立故障 | Watchdog 是监控机制，要追它监控的线程为何超时，而不是只处理重启结果 |
| 内存泄漏只看 Java heap | Native heap、Graphics 内存、FD 泄漏同样会导致系统服务不稳定 |
| Native Crash 只抓 tombstone 就结束 | 要结合符号表还原调用栈，并确认是否由 Java 层非法参数传入触发 |
| 死锁只分析 Java 层锁 | 跨 Java/Native 的锁顺序反转是系统服务死锁的高发场景 |
复盘建议：每次定位完一个稳定性问题，都记录“现象 → 分类 → 证据 → 根因 → 修复”五段式。长期积累后，你会形成对系统服务异常传导链的直觉，看到 Watchdog 日志就能快速判断是 ANR 型、死锁型还是 Native 崩溃型。
注意：不要在没有确认进程和线程上下文的情况下，直接把问题归为“系统服务异常”。系统服务异常是一个结果状态，不是根因分类。真正的分类必须落到崩溃、ANR、死锁、内存泄漏、Watchdog 或 Native Crash 中的至少一个具体类别，才能选择正确的调试工具和修复策略。