在 Android 视图体系的中央矗立着一个沉默的巨人——WindowManagerServiceWMS。它是所有窗口的“大管家”掌管着屏幕上每一寸像素的归属协调着应用、系统UI与触控事件的交互。理解 WMS就等于掌握了 Android 图形显示与交互的灵魂。本文将基于 Android 11API 级别 30的 AOSP 源码带你深入 WMS 的设计哲学、核心数据结构、启动流程、窗口添加、布局、动画以及输入事件分发机制。一、为什么需要 WMS——职责全景从应用开发者的视角看一个Activity通过setContentView就能将布局显示在屏幕上。但这背后从应用进程的 View 树到屏幕上的像素存在一条漫长的流水线应用端View 树的测量、布局、绘制生成一帧显示列表DisplayList。系统服务端WMS接收来自多个应用窗口的元数据决定它们的位置、大小、可见性、层级并协调动画。渲染引擎SurfaceFlinger拿到所有窗口的图形缓冲区进行合成最终送往显示硬件。输入系统InputManagerService将原始触摸事件分发给正确的窗口。WMS 正好位于中间承担了窗口管理与输入事件派发枢纽的双重角色。具体职责包括窗口状态管理为每个窗口维护一个WindowState对象记录其位置、大小、可见性、标志等。Z 轴顺序与层级决定哪个窗口在上哪个在下。布局与尺寸计算根据系统栏、Insets、配置变化等重新计算窗口大小和位置。动画调度协调窗口出现、消失、切换时的过渡动画。Token 与权限验证通过WindowToken防止恶意窗口添加并处理焦点分配。与 SurfaceFlinger 交互作为系统级窗口管理者创建和管理用于绘图的 Surface。输入焦点的管理虽然输入事件由 InputManagerService 分发但 WMS 负责维护窗口焦点状态输入事件经由 WMS 再传递到目标窗口。没有 WMS多窗口共存、自由切换就会成为一场混乱的争夺战。二、鸟瞰全局WMS 的架构与启动2.1 系统服务中的位置WMS 运行在SystemServer进程中作为众多系统服务的一员被启动。其初始化顺序十分关键因为它依赖输入管理、显示管理、电源管理等多个服务。SystemServer.run() - startBootstrapServices() - ... startCoreServices() - ... startOtherServices() - WindowManagerService.main() // 创建并初始化 WMS inputManager new InputManagerService(context, wm) wm.displayReady() ...WMS 通过WindowManagerService.main()工厂方法创建接收Context、InputManagerService、显示管理、输入管理策略等。2.2 核心类族谱WMS 并不是单打独斗它拥有一整套围绕“窗口容器”设计的类层级WindowManagerService服务本身提供了addWindow、removeWindow、relayoutWindow等 Binder 接口。RootWindowContainer窗口容器的顶层根管理多个 Display。DisplayContent代表一个逻辑显示器屏幕包含若干DisplayArea。TaskDisplayArea/Task在多窗口分屏、自由窗口模式下Task作为 Activity 的容器。ActivityRecord代表一个 Activity。WindowContainer所有窗口容器的基类采用树形结构完美支持遍历和动画。WindowState代表一个具体的窗口如 Activity 窗口、状态栏、对话框等是 WMS 管理的最小单元。WindowToken与应用端窗口令牌一一对应标识一组窗口的归属。Session应用进程与 WMS 通信的 Binder 桥梁用于权限检查。从容器树形结构看大致如下RootWindowContainer └─ DisplayContent (默认屏幕) ├─ DisplayArea (如状态栏、导航栏区域) ├─ TaskDisplayArea │ └─ Task │ └─ ActivityRecord │ └─ WindowState (窗口1, 窗口2...) └─ ImeContainer (输入法容器) └─ WindowState (输入法窗口)这种容器化设计使得 WMS 能通过递归遍历统一管理所有窗口极大简化了动画、旋转、分屏等复杂逻辑。三、窗口的生命线Token 机制要防止流氓窗口弹窗WMS 需要一种机制来验证窗口的合法性。这就是WindowToken存在的原因。3.1 WindowToken 与 AppWindowTokenWindowToken一个系统级令牌与应用端IWindow绑定。每个客户端在WindowManager全局操作前需要先向 WMS 注册一个WindowToken。如果客户端崩溃WMS 可据此清理其所有窗口。AppWindowToken在 Android 11 中已合并到ActivityRecord专为 Activity 派生它对应一个ActivityRecord并且会参与输入焦点、生命周期等管理。添加窗口时的令牌检验当应用调用WindowManager.addView()时最终会通过Session的addToDisplay抵达 WMS。WMS 会检查传入的IWindow对应的WindowToken是否有效。如果没有合法的 Token 且属于需要 Token 的窗口类型如 TYPE_APPLICATION则会直接拒绝。这就是为什么从Service或普通BroadcastReceiver直接弹出系统级窗口时需要申请TYPE_APPLICATION_OVERLAY并请求悬浮窗权限而且从 Android 8.0 开始要求使用TYPE_APPLICATION_OVERLAY而非远古的TYPE_PHONE同时需要动态权限。3.2 父子窗口与 Token 树窗口可以通过LayoutParams.token指定父窗口令牌从而建立父子关系。子窗口会跟随父窗口移动、显示和隐藏其 Z 轴顺序也由 WMS 保证在父窗口之上。常见如对话框、下拉菜单等。四、一图胜千言窗口添加的完整流程我们以 Activity 启动后添加主窗口为例梳理addView到窗口显示的全链路。4.1 应用进程侧在ActivityThread.handleResumeActivity中最终会调用WindowManagerImpl.addView(decorView, layoutParams)。WindowManagerImpl委托给WindowManagerGlobal后者做了两件关键事为每个ViewRootImpl创建IWindow的 Binder 桩W。调用Session.addToDisplay(...)远程调用 WMS。// ViewRootImpl.setView()publicvoidsetView(Viewview,WindowManager.LayoutParamsattrs,...){...resmWindowSession.addToDisplay(mWindow,mSeq,mWindowAttributes,getHostVisibility(),mDisplay.getDisplayId(),mTmpFrame,...);...}4.2 WMS 内部处理Session.addToDisplay()经过权限检查后调用WindowManagerService.addWindow()。addWindow核心逻辑简化验证调用者身份检查是否持有合法 Token。创建 WindowState 对象并将其插入到对应的窗口容器树中根据类型、Token 找到父容器。调整 Z 轴顺序利用WindowContainer的addChild并重新排序。执行布局调用WindowState的computeFrame计算窗口初始位置和大小并发起 relayout 到应用端。发送窗口变化通知触发 Surface 创建、动画启动。更新输入焦点如果是可见的焦点窗口类型则请求更新输入焦点。安排过渡动画并调用SurfaceFlinger进行合成。值得一提的是WMS 并不会直接参与绘制它只关心几何属性与可见性。真正的图形缓冲区由应用进程通过Surface写入SurfaceFlinger 负责合成。五、秩序的艺术窗口层级与布局屏幕空间寸土寸金谁在上谁在下由 WMS 的层级规则决定。5.1 窗口类型与 Z 轴LayoutParams.type定义了窗口类型它分为三大范围应用窗口1 ~ 99如TYPE_APPLICATION、TYPE_APPLICATION_ATTACHED_DIALOG等必须依附于一个应用 Token。子窗口1000 ~ 1999必须依附于父窗口。系统窗口2000 ~ 2999如TYPE_SYSTEM_OVERLAY、TYPE_STATUS_BAR、TYPE_INPUT_METHOD等通常由系统进程持有可以悬浮在应用窗口之上。在 WMS 内部这些类型会被映射到具体的容器层级。例如DisplayContent会预定义一些DisplayAreaDisplayArea.DEFAULT普通应用区域。DisplayArea.ABOVE_TASKS输入法、保护屏等。DisplayArea.SYSTEM_WINDOWS状态栏、导航栏等。这些区域本身就有固定的 Z 序加上同一区域内窗口的顺序调整构成了完整的层级体系。5.2 布局计算与 Insets系统UI如状态栏、导航栏、刘海屏会挤占应用窗口的空间这就引出了WindowInsets的概念。WMS 负责计算每个窗口的Content Frame和Visible FrameContent Frame窗口可绘制区域的最大边界可能超出物理屏幕。Visible Frame减去系统装饰状态栏、导航栏等后实际可见的区域。当InsetsSource变化时例如状态栏隐藏WMS 会重新计算并调用WindowState的notifyInsetsChanged最终触发ViewRootImpl的分发让 View 树有机会调整布局。DisplayPolicy则是布局策略的制定者定义了状态栏和导航栏的摆放规则、旋转时的行为等。5.3 多窗口与分屏Android 7.0 引入多窗口模式Split-Screen, Freeform, PIP。WMS 通过Task来组织多窗口界面Task是可以独立堆叠的 Activity 集合每个Task拥有自己的边界矩形。在分屏模式下DisplayContent会将可用区域划分为两个TaskDisplayArea分别包含各自的Task栈。WMS 在布局时只需对每个Task施加边界限制其中的ActivityRecord和WindowState会自动适应。这种设计使得多窗口模式与单窗口模式在管理上几乎没有本质区别。六、变幻的桥梁动画系统窗口切换的流畅感来自 WMS 强大的动画框架。窗口动画涉及两种类型Window animation窗口本身的动画由WindowStateAnimator负责。Transition animation窗口集合的过渡动画如打开应用、回到桌面、最近任务切换由Transition和AnimationAdapter驱动。6.1 Transition 控制器当 WMS 检测到窗口树发生变化如新增、移除、显示、隐藏时会创建一个Transition对象收集所有受影响的窗口。随后系统 UI如SystemUI的LauncherTransition或核心通过TransitionPlayer可以接管这个过渡播放自定义的动画序列。这也就是为什么启动器可以定制应用打开的动画。Transition机制提供了高度的灵活性。6.2 动画执行与 Surface动画通常运行在WindowAnimator循环中通过Choreographer的帧回调驱动。每一帧WMS 会更新所有动画状态计算窗口 alpha、平移、缩放等矩阵并通过WindowSurfacePlacer将新的几何信息应用到SurfaceControl上。因为SurfaceControl的操作是通过SurfaceFlinger事务Transaction进行的所以动画可以完全脱离应用进程高效运行甚至在应用无响应时依然保持系统动画流畅。七、触摸的终点输入事件分发WMS 与 InputManagerServiceIMS是紧密协作的伙伴。输入事件的最终分发路径是硬件驱动 → EventHub → InputReader → InputDispatcher → 目标应用窗口。WMS 在此的角色是“向导”它维护着每个窗口的可点击区域Touchable Region和输入通道InputChannel。7.1 InputChannel 的创建当窗口首次添加或属性变化需要重新布局时WMS 会在WindowState.openInputChannel()中创建一对InputChannel一端交给应用进程由ViewRootImpl中的InputEventReceiver接收另一端注册到 IMS。IMS 借助这对套接字将事件直接发送到应用主线程的消息队列中高效且安全。7.2 焦点与触碰区域IMS 分发触摸事件时会向 WMS 查询当前焦点窗口和窗口的触摸区域。WMS 根据 Z 序、是否可见、FLAG_NOT_TOUCHABLE等标志计算出包含触摸区域的最顶层窗口再将事件派发到对应的InputChannel。从手指按下到应用onTouchEvent被调用路径虽长但在 WMS 与 IMS 的协同下延迟极低。八、线程模型与性能考虑WMS 的大部分业务逻辑运行在“android.display”线程全局显示线程上它是一个HandlerThread。所有窗口状态修改、布局、动画更新都需在这个线程的Handler消息循环中执行天然形成一个同步屏障避免了复杂的锁。应用进程通过 Binder 调用 WMS 时WMS 会快速将请求封装成消息投递到android.display线程的WMH(Handler) 中因此 Binder 调用本身不会阻塞系统关键流程。这样的设计也暗示开发者频繁跨进程调用 WMS例如疯狂updateViewLayout会增加android.display线程的负载可能导致窗口操作延迟。九、演进与未来从早期的“扁平化”窗口列表到 Android 7.0 引入WindowContainer树形结构再到 Android 11/12 进一步将ActivityRecord并入层级、重构DisplayAreaWMS 的架构演化始终遵循一个原则用统一的树形容器模型抽象所有窗口组织方式以应对折叠屏、多显示设备、桌面模式等未来场景。目前WindowManagerService的部分责任正向WindowManagerShell和SystemUI转移使得定制度更高、可扩展性更强但核心容器与动画引擎依然是那个不可撼动的“窗口之王”。十、结语WindowManagerService 是一个庞大而精密的系统它不仅是“窗口的摆放者”更是 Android 图形栈和输入栈的调度中心。读懂 WMS需要从架构设计者视角理解其容器哲学从代码细节中品味其性能考量。希望本文能为你拨开迷雾让你在自定义窗口行为、调试 UI 问题、深入系统优化时胸有成竹。最后不妨记住一张脑图SurfaceFlinger管“画”InputManager管“摸”WMS 管谁在哪里画、谁能被摸到三者协同构建了 Android 交互体验的基石。