先聊聊 Android 窗口容器树到底是个啥玩意儿

说实话，我第一次kan到 WindowContainer 那一堆类名，脑子里直接冒出“这玩意儿到底管几层？”的疑问。

哈哈，别急，咱慢慢拆。

先把Zui根本的概念摆出来：窗口容器树是 Android 系统里管理所有窗口的“组织结构”。

它不是 UI 的层级，而是后台的“谁管谁”。

咱们先把大树的根节点找出来——RootWindowContainer。

整个系统只有一个 RootWindowContainer。

它是所有 DisplayContent 的父亲。

class RootWindowContainer extends WindowContainer implements DisplayManager.DisplayListener {}

RootWindowContainer 负责统一调度，像老大一样指挥下属。

一块物理屏幕或外接显示器，就会对应一个 DisplayContent。

所以Ru果你玩双屏、投屏，那系统里可Neng有多个 DisplayContent。

DisplayContent 继承自 RootDisplayArea，兼具“区域根”和“显示信息”的双重身份：

class DisplayContent extends RootDisplayArea implements WindowManagerPolicy.DisplayContentInfo {}

在每个 DisplayContent 里系统会进一步划分几个 DisplayArea。

TaskDisplayArea——专门放 App 窗口的区域。

DisplayArea.Tokens——放系统窗口、输入法、壁纸等非任务窗口。

ImeContainer——输入法专属区。

这层划分让“窗口类型”和“落在哪块区”解耦。比如对话框会直接挂在 TaskDisplayArea 下而状态栏则走 Tokens 路径。

RootWindowContainer
 └─ DisplayContent
     ├─ TaskDisplayArea
     │   └─ Task 
     │       └─ ActivityRecord
     │           ├─ WindowState 
     │           └─ WindowState 
     └─ DisplayArea.Tokens
         └─ WindowToken 
             └─ WindowState

kan见没？从根到叶，一条链子顺着走下来就是一个完整的窗口实例如何在系统里定位的过程。

WindowContainer

- 所有容器节点的基类。提供 mParent、mChildren 等通用属性和 addChild、removeChild 方法。

class WindowContainer extends ConfigurationContainer
        implements Comparable, Animatable, SurfaceFreezer.Freezable,
        InsetsControlTarget {
    private WindowContainer mParent = null;
    protected final WindowList mChildren = new WindowList;
}

WindowToken

- 把一组窗口组织起来的“分组标签”。ActivityRecord 实际上就是一种特殊的 Token。

class WindowToken extends WindowContainer {
    final IBinder token;
    final int windowType;
}

ActivityRecord → WindowState

- ActivityRecord 持有一个或多个 WindowState。主窗口一般是 TYPE_BASE_APPLICATION，弹窗则是 TYPE_APPLICATION_PANEL 或 ATTACHED_DIALOG。

# 为什么百度不收录？# 这个问题经常被问到，尤其是写技术博客的小伙伴们。

- 你得保证页面内容是真正原创、有价值的。百度爱新鲜，不喜欢抄来抄去的复制粘贴。

- 再者，标题和正文要匹配。别搞标题党，把文章写成《Android 窗口容器树》却全篇讲怎么Zuo饭，这可不行呀！

- Zui后要Zuo好站内 SEO 基础：合理使用 H1/H2/H3、Meta Description，还有适量关键词自然出现。别硬塞太多，否则会被判作弊。

# 小结 # 用心写内容，技术细节扎实自然就Neng被百度抓取啦~ 嗯，就是这么简单。

- The TaskDisplayArea 是任务容器，它下面Ke以挂多个 Task。

- 每个 Task 对应一堆 ActivityRecord，栈顶的是前台 Activity。

- ActivityRecord 包含实际渲染用的 WindowState以及可Neng的附属窗口。

- 这些 WindowState Zui终关联到 SurfaceControl，上交给 SurfaceFlinger 合成显示。说白了就是“一颗星星”从代码到屏幕的旅程路线图啦！

- 系统 UI、输入法、壁纸，dou走这条路。

- 它们没有对应的 ActivityRecord，只是单独挂在 DisplayArea.Tokens 下的 Token 上，然后生成自己的 WindowState。

- 举个例子：键盘弹起时会创建一个 TYPE_INPUT_METHOD 的 Token，然后生成对应的 Keyboard 窗口状态，这个窗口会被放进 ImeContainer 区域，确保它总是在Zui上层显示但又不抢占应用焦点。.

- 每个 window type dou映射到一个 policy layer，这一步在 WMS 策略里完成：

window type -> policy layer -> DisplayArea 分区 -> Z‑order 排序 -> SurfaceControl 层级

- 举例来说TYPE_STATUS_BAR 对应的是 POLICY_LAYER_STATUS_BAR，它会比普通应用窗口高，却比 INPUT_METHOD 低，这样状态栏总是在Zui上方但不会遮挡键盘弹窗。

- 想找某个 Activity 的主窗体？先定位到对应的 DisplayContent，再往下找 TaskDisplayArea → Task → ActivityRecord → 主 WindowState 即可；

- 想追踪系统弹窗？直接在 RootWindowContainer 下遍历 DisplayArea.Tokens 中各个 Token 的子节点；

- 想了解输入法层级？kan ImeContainer 区域里的 Token 和它对应的 WINDOW_STATE；

- Ru果要调试 Z‑Order，Ke以打开 dumpsys activity windows -a -b -c | grep "layer" 来查kan每个 window 的 layer 值。

public class DisplayArea extends WindowContainer{}
    

- 每个 WindowState 持有一个 SurfaceControl 对象；

- SurfaceControl 会形成自己的父子关系，对应于真正渲染时 GPU 合成使用的 Layer 树；

- Zui终由 SurfaceFlinger 把所有 Layer 按 Z‑Order 合成输出帧缓冲区。

- 简单来说： "WMS 树" 管理 “谁管谁”，而 "Surface 树" 把这些管辖关系转化为硬件可渲染层级。

* RootWindowContainer —— 全局根节点，一切皆从这里起步；

* DisplayContent —— 对应每块屏幕/虚拟显示；

* DisplayArea —— 把屏幕划分功Neng区，如任务区、系统区、IME 区；

* 各种 Container —— 构成应用路径；

* Token 系列 —— 为非任务窗口提供分组机制；

* WindowState —— 真正可见/可交互的窗口实体；

* SurfaceControl / SurfaceFlinger —— 将上述逻辑映射为 GPU 可渲染图层，实现Zui终画面。