📚 课程目录第2章 dumpsys 输出结构

AMS 主线程队列状态排查：从卡顿现象到阻塞点定位

Android 系统的核心组件 ActivityManagerService（AMS） 运行在主线程（通常称为“AMS 线程”或“UI 线程”）上。当该线程的消息队列被耗时操作或死循环阻塞时，整个系统的进程管理、Activity 生命周期调度、Service 控制等都会出现明显延迟，用户直接感受到的就是应用启动慢、界面跳转卡顿、后台任务无响应。

排查信条：AMS 线程卡顿 ≠ 所有系统卡顿，但 AMS 队列阻塞往往是连锁会话的根源。优先确认“是不是 AMS 线程”的阻塞，再深究“是哪个消息/Handler”导致的。

1. 现象识别：AMS 主线程卡顿的典型表象

AMS 线程卡顿不会直接报错，需要通过现象组合判断：

现象编号	用户/测试层面表现	系统日志 / 指标线索
P1	点击桌面图标后应用图标闪动很久才进入首页	logcat 中出现 `waitForIdle()` 超时，或 `ActivityRecord` 状态变化间隔 > 1s
P2	最近任务列表滑动明显掉帧	`dumpsys activity activities` 中 `mFocusedStack` 无法快速切换
P3	发起同步、广播或 AIDL 回调后等待数秒才有回应	后台 `BroadcastQueue` 中积压大量 `PendingBroadcast`
P4	使用 `dumpsys activity oom` 时命令执行时间 > 2s	`dumpsys` 中 `- - - - - - - - completed` 出现极慢

  快速自判定规则：执行 dumpsys activity activities | grep "mResumedActivity" 连续两次（间隔 2s），若 mResumedActivity 的组件名未变化且两次时间戳差 > 1500ms，则高度怀疑 AMS 线程卡顿。

2. 数据采集：dumpsys activity queues 命令详解

dumpsys activity queues 是排查 AMS 队列问题的核心命令，它直接输出当前 AMS 主线程上所有消息队列的状态、待处理消息、处理器信息。典型执行方式：

adb shell dumpsys activity queues
# 或者保存到文件以便分析
adb shell dumpsys activity queues > /data/local/tmp/ams_queues$(date +%s).txt

输出内容结构如下（伪造但典型的真实片段）：

DUMP OF ACTIVITY MANAGER QUEUES:
  Main handler (com.android.server.am.ActivityManagerService$MainHandler)
    Process: ActivityManagerService
    Thread: android.bg (id=2)  *主线程名字可能不同
    Current message: msg=what=100 (START_ACTIVITY)
    Looper stats:
      Main Looper: Android Anr Monitor, active, 14 pending messages
      Delayed messages: 2

  Queue: ActivityTaskManagerService$UiHandler
    Pending messages: 3
    History (last 5):
      21:43:12.123: what=CMD_RESUME_ACTIVITY (8) took 1234ms
      21:43:10.889: what=CMD_PAUSE_ACTIVITY (7) took 890ms
      21:43:09.999: what=CMD_STOP_ACTIVITY (6) took 15ms
      21:43:09.984: what=CMD_CLEANUP_RECENT_TASKS (16) took 7ms
      21:43:09.977: what=CMD_IDLE (20) took 3ms

  Queue: BroadcastQueue (Background)
    Pending ordered broadcasts: 2
    History status: last broadcast processed 2.3s ago

3. 关键字段解读：找到阻塞点

你需要关注以下关键字段和分类：

Current message — 当前正在处理的消息，若长时间不变（比如连续两次 dump 对比），说明该消息执行超长。
Looper stats / pending messages — 待处理消息堆积数量，正常应 < 10；若连续堆积 > 50 且长时间不消化，表示严重阻塞。
History 中的 took 列 — 每个消息的执行耗时。超过 500ms 的消息都值得怀疑；超过 1000ms 的基本就是卡顿元凶。
BroadcastQueue 的 pending ordered broadcasts — 有序广播卡住时，AMS 可能一直等待 onReceive 返回。
Delayed messages — 延迟消息的存在正常，但若大量延迟且实际延迟远超设定值，说明线程无法及时处理。

字段	正常阈值	异常标志
Pending messages 总数	≤ 5	> 20
任何一条 History 消息 took	< 200ms	> 800ms
两条 dump 之间 Current message 相同	应该变化	连续 2 次相等
Delay 消息实际延迟 (检查系统时间差)	误差 < 20%	远大于设定值
有序广播待处理数	0	> 2

4. 定位阻塞点：故障树与判断规则

将采集到的数据代入以下故障树进行推理：

故障树定位 AMS 主线程阻塞点
├─ 1. 检查 Current message 是否长时间同一 what？
│   ├─ 是 → 该消息是直接阻塞源，记录 what 与参数
│   └─ 否 → 进入 2
├─ 2. 查看 History 中 took 异常的消息列表
│   ├─ 有单个消息耗时 > 1s → 改为 startService 或 startActivity 极慢？
│   │   ├─ 是 → 可能由目标进程的 ANR 或 Binder 长时间等待导致
│   │   └─ 否 → 可能是 AMS 内部循环（如 killBackgroundProcesses）占用
│   └─ 多个消息都 > 500ms → 线程整体负载高 → 检查系统级锁竞争
├─ 3. 检查 BroadcastQueue 状态
│   ├─ pending ordered broadcasts > 0 → 输出具体 broadcast，查看是否因 onReceive 卡死
│   └─ 无异常 → 进入 4
└─ 4. 使用 dumpsys activity containers 或 strace 进一步

常见陷阱：History 中 took 很大的消息不一定是导致当前卡顿的直接原因——可能是之前的阻塞残留。务必比较两次 dump 的时间差和消息变化。

5. 修复动作：针对不同阻塞点的典型方案

根据阻塞点类型选择对应修复手段：

阻塞类型	可能原因	修复动作
Message what=100 (START_ACTIVITY) 耗时过长	目标进程创建慢、Binder 超时	优化目标 Application onCreate；或调整 `persistent` 策略
Message what=CMD_RESUME_ACTIVITY 耗时 > 1s	Resume 时执行了重量级操作（如数据库查询）	将重量操作移出 UI 线程，或使用 `handler.post` 延迟
BroadcastQueue 有序广播 pending	某个 receiver 未及时返回 `onReceive`	检查该 receiver 超时原因，避免在主线程做繁重 I/O
Pending messages 大量堆积但单个消息时间正常	消息频率过高，处理器来不及消化	合并冗余消息，或增加消峰机制

6. 复测与预防

执行修复后，重复以下复测流程：

再次执行 dumpsys activity queues 连续三次（间隔 1s），确认 History 中所有消息 took < 200ms。
模拟用户典型场景（冷启动、快速切换应用、后台多任务），观察是否存在卡顿。
使用 dumpsys activity oom 检查 OOM adjust 响应时间是否缩短。

预防策略：

在系统开发阶段，为 AMS 相关 Handler 添加日志记录每条消息耗时（可用 Log.w 打印 + Looper.setMessageLogging）。
建立自动化监控指标：一旦 History 中出现 took > 800ms 的消息，自动记录堆栈。
限制第三方应用通过 startActivity/ sendOrderedBroadcast 在短时间内发出超过 10 个请求，防止队列风暴。