不止是“经理”与“员工”：解构 Android 窗口管理的三层架构

一句话总结：

我们 App 中的 WindowManager 并非真正的“经理”，而只是一个**“接口人”。它通过 Binder IPC，将添加/删除窗口的请求，发送给远在系统进程中的“真正的大老板” WindowManagerService (WMS)**。ViewRootImpl 则是连接我们 View 树与 WMS 的关键“桥梁”。

---

第一章：误解与真相——Android 窗口管理的“三层 C/S 架构”

我们通常的“员工-经理”模型，是一个简洁的客户端视角。但真实的 Android 窗口管理，是一个经典的三层 Client/Server 架构。

1. 客户端 (App 进程): Window 与 WindowManager 接口

   • 这是我们开发者直接打交道的一层。Window 对象（如 PhoneWindow）负责管理窗口的策略和内容（持有 DecorView），而我们获取的 WindowManager 只是一个提供 addView/removeView 等 API 的“接口人” 。

2. 通信桥梁 (App 进程): ViewRootImpl 与 WindowSession

   • 当我们调用 addView 时，真正的魔法发生在这里。系统会创建一个 ViewRootImpl 对象，它既是 View 树的“根”，也是一个**“驻应用进程的 WMS 大使”**。它通过一个名为 WindowSession 的 Binder 代理，与系统服务进行跨进程通信。

3. 服务端 (System Server 进程): WindowManagerService (WMS)

   • 这才是真正的“大老板”，是窗口管理的唯一“源头真相” 。它在系统进程中，维护着屏幕上所有窗口（WindowState）的列表，并负责计算它们的尺寸、层级、动画，最终将“布局蓝图”交给 SurfaceFlinger 去绘制。

---

第二章：一次 addView 的“跨界之旅”

让我们追踪一次 addView 调用，看看这三层架构是如何协同工作的：

graph TD
    subgraph "<b>Tier 1: 客户端 (App 进程)</b>"
        A[1. 你的代码<br>windowManager.addView(myView)] --> B(WindowManagerImpl);
    end
    
    subgraph "<b>Tier 2: 桥梁 (App 进程)</b>"
        B --> C[2. 创建 ViewRootImpl];
        C --> D(3. 通过 WindowSession (Binder)<br>发起 IPC 调用);
    end
    
    subgraph "<b>Tier 3: 服务端 (System Server 进程)</b>"
        D --> E[4. WMS.addWindow()<br>接收请求];
        E --> F[5. 创建 WindowState<br>计算布局, 分配 Surface];
        F --> G[6. 通知 SurfaceFlinger 绘制];
    end
    
    F -- 返回 Surface --> D;
    D -- 关联 Surface --> C;
    C -- 驱动 --> H[7. myView 开始<br>Measure/Layout/Draw];

1. 客户端发起： 你的代码调用 WindowManager 接口的 addView 方法。
2. 秘书接单： WindowManagerImpl 接到请求，创建一个 ViewRootImpl 实例，并将 View 树与它关联。
3. 跨界通话： ViewRootImpl 通过 WindowSession 这个 Binder 代理，向远端的 WMS 发起一个 addWindow 的 IPC 调用。
4. 老板决策： WMS 收到请求，经过权限校验、参数计算后，创建一个 WindowState 对象来记录这个新窗口，并为其分配好层级（Z-Order）。
5. 分配画板： WMS 通知 SurfaceFlinger 为这个窗口准备一块“画板”（Surface）。
6. 返回凭证： WMS 将 Surface 的控制权，通过 Binder 返回给 App 进程的 ViewRootImpl。
7. 开始装修： ViewRootImpl 拿到“画板”后，正式启动 View 树的 measure, layout, draw 流程，将内容画在 Surface 上。

---

第三章：WindowToken——与 WMS 通信的“安全令牌”

为什么用 ApplicationContext 弹 Dialog 会崩溃？因为它缺少一个合法的“身份证”——WindowToken。

• WindowToken 是什么？ 它是一个 IBinder 对象，是 Activity（由 ATMS 管理）合法性的唯一凭证。
• 安全机制： 当 ViewRootImpl 向 WMS 请求添加窗口时，必须出示其 WindowToken。WMS 会校验这个 Token 的有效性，确保是“根正苗红”的组件在申请窗口，而不是某个野路子的 Context。Activity 的 Window 天然持有这个 Token，而 ApplicationContext 则没有。

---

四、总结：从“API 使用者”到“架构洞察者”

旧思维（API 视角）	新思维（三层架构视角）
Window 是一个 View	Window 是 View 的承载者和策略容器
WindowManager 是管理者	WindowManager 是客户端接口，真正的管理者是服务端的 WMS
addView 是一个简单的调用	addView 是一次穿越三层架构的、由 ViewRootImpl 驱动的跨进程通信
WindowToken 异常是个 Bug	WindowToken 是 ATMS 与 WMS 之间进行安全校验的核心凭证

通过理解这套“客户端-桥梁-服务端”的三层架构，你才能真正洞悉 Android 窗口系统的运作精髓，并在遇到 WindowManager 相关问题时，拥有直击本质的分析能力。