4. 使用 dumpsys 分析 WMS 状态：窗口层级、焦点窗口、布局参数、输入通道

在 Android 窗口系统调试与性能优化中，dumpsys 是通往 WMS (WindowManagerService) 运行态的一把万能钥匙。通过 adb shell dumpsys window 命令，可以获取 WMS 内部的完整快照：窗口层级树、焦点归属、每个窗口的布局参数以及输入通道的绑定状态。本章围绕如何从原始 dump 数据中提取这四类关键信息，并判定是否存在性能瓶颈或异常配置。

4.1 命令入口与输出结构

基础命令只有一条，但输出量可能达到数千行。核心入口命令：

adb shell dumpsys window [options]
# 常用子选项：
# -t [N]  只输出最近 N 个  状态
# -a      显示所有附带信息（布局、动画、输入等）
# -v      逐层详细输出（适用于窗口层级分析）
# 实战推荐：adb shell dumpsys window -v 2>&1 | head -300

WMS dump 输出按逻辑段划分，本章聚焦的四个关键段在输出中的位置与标记如下表：

分析目标Dump 段标题标记关键子标题
窗口层级Window HierarchyDisplay #0 – Window #N
焦点窗口Focused window / Focused applicationmCurrentFocus / mFocusedApp
布局参数WindowState 详情mFrame / mContentInsets / mVisibleInsets / mLayoutParams
输入通道Input event dispatchInputChannel / mInputChannel / mInputWindowHandle

4.2 窗口层级分析：从根到叶的树状结构

窗口层级（Window Hierarchy）反映了 Z-order 顺序与父子托管关系。在 dump 中层级以缩进展示，越靠上的节点越靠近屏幕（显示在最顶层）。

Window Hierarchy:
  Display #0 (0x1):
    Window #6: NavigationBar0 (com.android.systemui)
      mOwnerUid=1000, mShowToOwnerOnly=true
      mFrame=[0,2160-1440,0] mContentFrame=[0,2160-1440,0]
    Window #5: StatusBar (com.android.systemui)
      mFrame=[0,0-1440,84] mContentFrame=[0,0-1440,84]
    Window #4: SurfaceView - com.example.app/com.example.MainActivity
      (has child: InputMethod)
    Window #3: com.example.app/com.example.MainActivity
      mFrame=[0,84-1440,2160] mContentFrame=[40,124-1400,2136]
性能检查点：
  • 检查是否存在层级深度大于 6 的窗口链（例如：Display → Root → Task → Activity → Dialog → PopupWindow → SurfaceView），过深会拉长合成与命中测试路径。
  • 关注非全屏窗口的 mFrame 是否频繁跳动（暗示布局参数持续变化，可能导致过度重绘）。

4.3 焦点窗口：mCurrentFocus 与焦点切换异常

焦点窗口决定了按键（KeyEvent）与触摸事件的最终接收者。在 dump 中通过 mCurrentFocus 和 mFocusedApp 标识：

Focused window: FocusedWindow{1eb2e34 u0 com.example.app/com.example.MainActivity}
Focused app: FocusedApp{3c4d5e6 u0 com.example.app/com.example.MainActivity}

# 若出现异常：
mCurrentFocus=null
mFocusedApp=null
WARNING: No focus window!
常见焦点问题：
  • 无焦点窗口：应用 ANR 或窗口被销毁后未触发 focus 转移，导致全局输入无响应。
  • 焦点窗口与显示窗口不匹配：焦点指向一个已隐藏的窗口，通常由 setVisibility 或 泄露引起。
  • 快速焦点切换：两次 dump 采样间隔内 mCurrentFocus 变化超过 2 次，可能触发输入帧延迟。

4.4 布局参数：mFrame、mContentInsets 与 mVisibleInsets

布局参数决定窗口的最终绘制尺寸与内容安全区域。每个 WindowState 节点后会跟随布局详情。

Window #3: com.example.app/com.example.MainActivity
  mFrame=[0,84-1440,2160]        // 窗口在屏幕上的实际矩形
  mContentFrame=[40,124-1400,2136]  // 扣除状态栏、导航栏后的内容区
  mVisibleInsets=(40,124)-(1400,2136) // 可见性裁减区域（通常等于 mContentFrame）
  mLayoutParams:
    type=1    // TYPE_BASE_APPLICATION
    format=-3 // 半透明
    flags=0x00000800  // FLAG_DIM_BEHIND
布局参数含义性能排查要点
mFrame窗口在屏幕坐标中的尺寸若频繁非整数（如 1439.5），疑为子像素偏移
mContentInsets系统装饰(状态栏/导航栏)占用的上下左右边距动态 inset 变化应靠 OnApplyWindowInsetsListener 补偿
mVisibleInsets实际可见区域（系统裁减后的最终边界）若比 mContentFrame 更小，表示有截断或 Shape 窗口覆盖
flags窗口标志位组合FLAG_LAYOUT_NO_LIMITS 可能导致超大帧外绘制

4.5 输入通道：InputChannel 与通道阻塞

输入通道（InputChannel）是事件从 InputDispatcher 派发到窗口的管道。每个窗口的 InputChannel 以十六进制地址显示，若出现 WARNING 或 CHANNEL_BROKEN 则代表管道已损坏。

Window #3: com.example.app/com.example.MainActivity
  InputChannel: 0x7a1b2c3d 'com.example.app/com.example.MainActivity (client)'
  mInputWindowHandle: 0x8a9b0c1d
    dispatchMode=Paused            // 正常为 Normal，Paused 表示窗口无响应
    touchableRegion=[40,124-1400,2136]
    hasFocus=true

# 异常示例：
  InputChannel: 0x00000000 'DEAD CHANNEL (com.example.app)'
  WARNING: Channel broken or null!
输入通道性能诊断：
  • 检查 dispatchMode 是否为 Paused 或 Queueing。若大量窗口处于 Paused 状态，输入事件将滞留，导致触摸卡顿。
  • touchableRegion 是否与 mFrame 严重不匹配？不匹配区域会造成触摸盲区。
  • 若出现 DEAD CHANNEL 且窗口仍存在于层级中，疑为应用未释放 InputChannel 引起资源泄露。

4.6 全流程整合：从 dump 数据到性能判断

以下 SVG 流程图展示了一次完整分析的过程——从执行 dumpsys window -v 开始，经过四个维度的关键数据提取，到达判定与优化建议。

WMS dump 数据->性能判定全流程 adb shell dumpsys window -v Window Hierarchy mCurrentFocus LayoutParams InputChannel 层级深度>6？ 焦点为空？ mFrame异常？ 通道断裂？ 汇总判定：Z-order / 焦点 / 布局 / 输入问题

4.7 实战：一次 WMS dump 性能调优案例

某社交应用反馈“返回手势时偶发 200ms 无响应”。抓取 dumpsys window 后发现：

Window Hierarchy:
  ...
  Window #7: ActivityRecord{xxx com.example.social/com.example.SplashActivity}
    InputChannel: 0xdeadbeef 'SplashActivity (client)'
    dispatchMode=Paused
  ...
  Window #8: ActivityRecord{yyy com.example.social/com.example.MainActivity}
    InputChannel: 0x7f000001 'MainActivity (client)'
    dispatchMode=Normal
Focused window: FocusedWindow{yyy com.example.social/com.example.MainActivity}

根因：SplashActivity 窗口已退出动画，但其 WindowToken 未被及时清理，且输入通道已断裂（0xdeadbeef），导致 InputDispatcher 在分发给焦点窗口前尝试向 SplashActivity 派发一次事件，引发 200ms 超时。修复方案（Causes/解决对照）：

  • 修复：在启动页 finish 后显式清理 WindowToken 并释放 InputChannel。
  • 优化：WMS 侧对 dispatchMode=Paused 的窗口跳过输入分派，减少一次轮询。已合入 AOSP 13 QPR2。

4.8 常见错误与优化清单

必须避开的 4 个常见错误：
  1. 直接 grep 忽略上下文：只搜 mCurrentFocus 但未比对其所属 Display，多屏设备中会误导焦点窗口归属。
  2. 忽略 mContentInsets 和 mVisibleInsets 差异：两者不一致意味着系统额外裁减，可能是由弹出窗口或重叠图层引起的过度合成。
  3. 只看 InputChannel 地址、不检查 dispatchMode：地址非零不代表通道可用，Paused 状态等效于死通道。
  4. 单次 dump 静态分析：WMS 状态是时间敏感数据，建议三次采样（间隔 2s），取交集或观察变化趋势。
优化方向执行动作预期效果
层级扁平化减少嵌套 SurfaceView 与 PopupWindow，使用 View.setZ 代替调整 WMS 子窗口Z-order 排序加速，降低合成开销
焦点管理在 onPause 中主动释放焦点，避免 mCurrentFocus 遗漏输入队列按键帧延迟降低 20~50ms
布局参数冻结将 mFrame 设置为固定尺寸，减少 relayoutWindow 调用频次WMS 线程负载下降
输入通道保洁Window 销毁时确保 InputChannel.dispose() 被调用消除幽灵通道，输入派发异常率归零

4.9 章节自检清单

  • ✔ 能通过 adb shell dumpsys window -v 还原窗口层级树
  • ✔ 能够从 dump 输出中定位 mCurrentFocus 并判断焦点是否合理
  • ✔ 会解析 mFrame / mContentInsets / mVisibleInsets 三者关系及性能影响
  • ✔ 能够识别 InputChannel 断裂、dispatchMode=Paused 等输入异常状态
  • ✔ 能够根据 dump 数据输出一份简短的性能分析报告（层级深度 / 焦点 / 布局 / 输入通道）
← 上一章 📖 返回目录 下一章 →