Android WMS（一）-窗口管理
WMS（WindowManagerService）是系统核心服务，它主要职责主要包含如下几个部分：
窗口管理和Surface管理，几乎贯穿了之前图形系统系列，这里相当于单独拎出来分析下，同时也是对之前图形系统的知识点进行回顾。本篇先针对窗口管理部分进行梳理。
一、捋清几个关系
关系1：Activity 、Window、View
这部分牵扯到的是窗口视图架构。
Activity是系统可视化交互组件，四大组件都由AMS统一管理生命周期，事实上它的职责只是生命周期的管理，处于单一职责的原则，那势必需要将Activity和其上的视图View进行解耦，那么就引入Window的概念，它是个抽象类，对于Activity来说，它的具体实现类是PhoneWindow，在Activity执行attach的时候，会创建了一个PhoneWindow对象。PhoneWindow作为装载根视图DecorView的顶级容器，Activity通过setContentView实际上是调用PhoneWindow来创建DecorView，并解析xml布局加载到DecorView的contentView部分。
关系2：WindowManager、WindowManagerImpl、WindowManagerGlobal
这部分牵扯到的是应用端的窗口管理架构。
WindowManager是一个接口类，继承自接口ViewManager，负责窗口的管理(增、删、改)。它的实现类是WindowManagerImpl，而具体操作实际上又会交给WindowManagerGlobal来处理，它是个单例，进程唯一。WindowManagerGlobal执行addView的方法中会传入DecorView, 还会初始化一个ViewRootImpl。WindowManagerGlobal因为是单例的，它内部会有两个List来分别保存这两个对象，来统一管理。
关系3：ViewRootImpl、WindowManagerService
这份部分牵扯到的是具体窗口操作的binder IPC。
WindowManagerGlobal负责对DecorView和对应的ViewRootImpl进行统一管理，而具体功能是由ViewRootImpl来处理。
以addView为例，具体window是由WMS统一管理的，所以这里会进行binder IPC。
binder IPC:
IWindowSession: 应用程序通过Session与WMS通信，并且每个应用程序进程都会对应一个Session。
IWindow: 作为WMS主动与应用程序通信的client端，因为不同的Window是不同的client，因此它也被作为识别window的key。
具体可以参考之前图形系统系列文章：
Android图形系统（一）-Window加载视图过程
Android图形系统（二）-DecorView布局加载流程
Android图形系统（三）-View绘制流程
Android图形系统（四）-Activity、Window、View关系总结
二、Activity与Window关联分析
Activity与Window联系是非常紧密，很多显示相关操作需要两者密切配合，那么如何保证他们的一致性呢？Android通过token来保证两者的一致性校验：
token流向简单归纳如下：
1）new ActivityRecord的时候会new一个token与之对应。
2）ApplicationThread scheduleLaunchActivity的时候，ActivityClientRecord 接收这个token。
3）activity.attach传入该token。
4）setWindowManager的时候传入该token,最终由Window的AppToken接收。
5）在WindowManagerGlobal的addView方法中，执行adjustLayoutParamsForSubWindow，将WindowManager.LayoutParams wp,wp.token赋值appToken,并在之后的流程中，WindowManager.LayoutParams wp作为参数传入WMS的addWindow方法对应attrs.token。
6）WMS中通过WindowToken与之对应。
那么其实，Activity的token，Window中的token，连传入addWindow的attrs.token，都是同一个token，都是ActivityRecord构造函数中创建的Token对象。这样做保证了一致性，主要体现在如下两点：
- 将AMS中创建的ActivityRecord和Window挂钩，当前的window明确知道自己是哪一个Activity创建的。
- Window和AMS有联系，同时又和WMS有关系，appToken则保证了这种同步机制。
三、窗口属性与类型
WindowManagerGlobal的addView函数有个重要参数：WindowManager.LayoutParams，它对应有两个重要的值：flag与type。
-flags:表示Window的属性:
| flags | 意义 |
|---|---|
| FLAG_NOT_FOCUSABLE | 表示Window不需要获取焦点，也不需要接收各种输入事件，此标记会同时启用FLAG_NOT_TOUCH_MODAL，最终事件会直接传递给下层具有焦点的Window。 |
| FLAG_NOT_TOUCH_MODAL | 系统会将当前Window区域以外的单击事件传递给底层的Window，当前Window区域以内的单击事件则自己处理，这个标记很重要，一般来说都需要开启此标记，否则其他Window将无法接收到单击事件。 |
| FLAG_SHOW_WHEN_LOCKED | 开启此模式可以让Window显示在锁屏的界面上。 |
-type: 表示窗口的类型（具体值太多了就不一一列举了，具体可以去WindowManager的LayoutParams看详细类型描述），窗口类型大体上就分三类：
| window类型 | 特点 | 层级范围 | 典型window代表 |
|---|---|---|---|
| system window | 独立存在 | 2000~2999 | Toast 、警告提示window、键盘window等 |
| application window | 属于应用的窗口 | 1~99 | 对应的就是activity的window |
| sub window | 需要依附于父window，不能独立存在 | 1000~1999 | Dialog 、 popupWindow |
四、窗口组织方式（分组与分层）
Android采用的是层叠式的布局
这个部分逻辑主要在WMS.addWindow中，这个方法非常非常重要！
分组：
子窗口与其依附的父窗口属于同一组，共用相同的token。
分层：
WindowState在WMS中对应一个具体的窗口。它有两个重要属性：
- mBaseLayer:它按窗口类型来决定z-order顺序。
- mSubLayer：它按值的大小与正负关系来决定多个子窗口在父窗口中的前后关系，以及相互之间的顺序。
然后，按如下流程来调整窗口的层级关系:
z-order计算过程
最终SurfaceFlinger会根据z-order顺序来决定视图的合成。
