Android 窗口那些事儿_android windowmanager addview-CSDN博客

/**
 * Abstract base class for a top-level window look and behavior policy.  An
 * instance of this class should be used as the top-level view added to the
 * window manager. It provides standard UI policies such as a background, title
 * area, default key processing, etc.
 *
 * <p>The only existing implementation of this abstract class is
 * android.view.PhoneWindow, which you should instantiate when needing a
 * Window.
 */
public abstract class Window {

}

结合 Window 类的注释，我们知道 Window 就是一层封装，提供通用页面模板，并不是真正的窗口。

2.3 Window 到底是什么？

Window 是一个抽象的概念，对应屏幕显示图像的一块区域，实际是 View。比如：前言中的图例情景，共包含3个 Window，分为3块区域，对应3个具体 View，当在 Dialog 的 Window 中添加、更新与删除 View，是不会影响到 Activity 和 Toast 的。

微观角度，Window 就是 View；宏观角度，Window 是 WMS 窗口体系下的最小单位。

其实，根本就没有具体的 Window，只有具体的 View。

3. 💠 Window 相关

3.1 WindowManager

WindowManager 是一个接口，继承自 ViewManager 接口，它的实现类为 WindowManagerImpl，WindowManagerImpl 通过桥接模式，将所有操作全部委托给 WindowManagerGlobal 来实现。

WindowManager 是我们访问 Window 的入口，使用 WindowManager 对 Window 进行添加、更新和删除，具体工作则由 WMS 来处理，WindowManager 和 WMS 通过 Binder 来进行跨进程通信。

接下来，让我们先从 WindowManager.addView(view, layoutParams) 方法的2个入参开始聊起。

1）入参1：View

View 表示需要在屏幕显示的内容，它是具体的。

2）入参2：WindowManager.LayoutParams

LayoutParams 对内容进行约束，包括宽高、位置、类型和 flag 等。

LayoutParams.type

表示 Window 的类型，Window 共有三种类型，分别是应用 Window、子 Window、系统 Window。

应用 Window：1 ~ 99，如：Activity 的 type 为2；
子 Window：1000 ~ 1999，如：PopupWindow 的 type 默认为1000，Dialog 的 type 为1003；
系统 Window：2000~ 2999，如：状态栏 type 为2000，Toast type 为2005，悬浮窗口 type 为2038。

数值越大层级越高，层级高覆盖层级低的，一般通过常量设置，系统 Window 需要申请权限。

LayoutParams.flags

设置 Window 相关的属性，常用：FLAG_NOT_FOCUSABLE、FLAG_NOT_TOUCH_MODA、FLAG_SHOW_WHEN_LOCKED 等。

FLAG_NOT_FOCUSABLE：表示窗口不需要获取焦点，也不需要接收各种事件，此属性会同时启动FLAG_NOT_TOUCH_MODAL，最终的事件会传递给下层拥有焦点的 Window；
FLAG_NOT_TOUCH_MODAL：将 Window 区域以外的单击事件传递给下层的 Window，当前 Window 内的单击事件自己处理，一般都要开启此事件，否则其他 Window 无法收到单击事件；
FLAG_SHOW_WHEN_LOCKED：可以将 Window 显示在锁屏的界面上。

3）三个方法

WindowManager 常用的有三个方法，addView、updateView 和removeView，这三个方法定义在 ViewManager 中，而 WindowManager 继承自 ViewManager。

package android.view;

public interface ViewManager {
    public void addView(View view, ViewGroup.LayoutParams params);
    public void updateViewLayout(View view, ViewGroup.LayoutParams params);
    public void removeView(View view);
}

3.2 DecorView 与 ViewRootImpl

DecorView 是 FrameLayout 的子类，被认为是 Android 视图树的根节点视图。

ViewRootImpl 是一个抽象的概念，相比于 DecorView 这种“实体”根节点，它是一个虚拟的根节点。

Measure-Layout-Draw 三大 View 绘制流程、触屏和按键等 Input 事件传递，以及 Insets 的更新、大部分需要遍历 View 层级结构的流程，起点都是在 ViewRootImpl。

简单来说，ViewRootImpl 不仅是 View 和 WM 的桥梁，也是事件分发的桥梁，是视图系统的核心。

3.3 WindowManagerService（WMS）

WMS 是 Android 系统中的重要服务，管理所有窗口，也是输入事件的中转站。

对 WMS 来说，一个窗口就是一个可以用来显示的 View 类，一个通过 WindowManagerGlobal.addView() 添加的 View。

View 本身并不能直接从 WMS 中接收消息，而是通过实现了 IWindow 接口的 ViewRootImpl.W 类来实现。

3.4 Layer

Layer 是一个比 Window 更底层的实现，代表屏幕上一块显示内容的区域。

一个 Window 就是一个 Surface，对应一个 Layer。

3.5 SurfaceFlinger

SurfaceFlinger 作用是合成所有 Layer 并送显。在 App 请求创建 Surface 时，SurfaceFlinger 会创建一个 Layer，在拿到从 WMS 传过来的 Window 宽高、位置，以及 App 提供需要绘制的 View 后合成该 Layer，然后送给屏幕进行显示。

在 Android 平台上创建的每个 Window 都由 Surface 提供支持，所有被渲染的可见 Surface 都被 SurfaceFlinger 合成到屏幕。

4. ⚛️ Window 深入

4.1 Activity/Window/View 的关系

Activity：是最上层的封装，屏蔽复杂的系统实现细节，抽象出 UI 生命周期，方便开发人员专注于界面编写，持有 Window；
Window：也是一层封装，提供通用页面模板，作为视图承载器，负责视图控制，持有 DecorView，DecorView 就是 View 的根布局；
View：就是视图，在 Activity.setContentView 中将 View 视图添加到 DecorView 中，一个页面通用且不变的部分交给 PhoneWindow 实现，变化的部分交给 View，让开发人员能够自由定制。

Activity 很庞大，通过采用单一职责原则，把 View 相关的代码从 Activity 中剥离到 Window 中去。

4.2 Activity/Window/DecorView/ViewRootImpl 的创建时机

Activity：在 ActivityThread 的 performLaunchActivity 方法中，通过 Instrumentation 在内部使用类加载器创建 Activity 实例；
Window：在 ActivityThread 的 performLaunchActivity 方法中，调用 Activity 的 attach 方法 new 一个 PhoneWindow 然后赋值给 mWindow 成员变量；
DecorView：在 Activity 的 onCreate 方法中调用 setContentView 方法，最后会调用 PhoneWindow 的 generateDecor 方法 new 一个 DecorView 然后赋值给 mDecor 成员变量；
ViewRootImpl：
1. 在 ActivityThread 的 handleResumeActivity 方法中，内部通过 WindowManagerGlobal 的 addView 方法 new 一个 ViewRootImpl 然后赋值给局部变量 root(ViewRootImpl)；
2. 通过 addView 方法，我们也注意到，一个 Window 对应一个 ViewRootImpl；
3. 此时也会调用 setView 方法与 DecorView 进行绑定：ViewRootImpl 会声明 mView 成员变量，并在 setView 方法中给 mView 对象赋值；
4. 和 PhoneWindow 一样会持有 DecorView，但 DecorView 的创建还是在 PhoneWindow 的；

4.3 DecorView 什么时候被 WindowManager 添加到 Window 中

即使 Activity 布局已成功添加到 DecorView 中，但 DecorView 此时还没有添加到 Window 中；
在 ActivityThread 的 handleResumeActivity 方法中，首先会调用 Activity.onResume 方法，接着调用 Activity.makeVisible 方法，在 makeVisible() 中完成 DecorView 的添加和显示。

4.4 Android 多窗口原理

简单来说，多窗口框架的核心思想是分栈和设置栈边界。

分栈：在 Android 系统中，启动一个 Activity 之后，必定会将此 Activity 存放于某一个 Stack，Android 为了支持多窗口，在运行时创建了多个 Stack；
栈边界：在多窗口框架中，通过设置 Stack 的边界来控制里面每个 Task 的大小，最终 Task 的大小决定了里面的 Activity 的窗口大小。

4.5 Window 点击与双击事件的区别

单击走的是 MotionEvent、双击走的是 KeyEvent；
MotionEvent 会返回位置坐标，KeyEvent 不会上报位置坐标。

5. ✅ Window 底层

5.1 Window/View 添加过程

Window/View
WindowManager.addView()
WindowManagerImpl.addView()
WindowManagerGlobal.addView()
ViewRootImpl.setView()
WindowManagerService

WindowMangerImpl 通过桥接模式，将所有操作全部委托给 WindowManagerGlobal 来实现。

不管是 Activity 窗口还是非 Activity 窗口，最终都要通过 ViewRootImpl.setView 向 WMS 注册窗口。

5.2 布局加载流程

setContentView 中通过 LayoutInflate.inflate 加载对应布局；
inflate 方法中首先调用 Resources.getLayout 通过 pull 方式 IO 加载 Xml 布局解析器到内存中；
createViewFromTag 根据 xml 的 Tag 标签反射创建 View 到内存；
递归构建其中子 View，并将子 View 添加到父 ViewGroup 中。

Android 这套布局加载流程的性能瓶颈：布局文件解析中的 IO 过程；创建 View 对象时的反射过程。

5.3 View 绘制流程

1）addView 流程

ActivityThread.handleResumeActivity；
WindowManagerImpl.addView；
WindowMangerGlobel.addView；
ViewRootImpl.setView；
ViewRootImpl.scheduleTraversals；
ViewRootImpl.doTraveral；
ViewRootImpl.performTraversals。

2）performTraversals 流程

performMeasure—DecorView.measure—DecorView.onMeasure—View.measure；
performLayout—DecorView.layout—DecorView.onLayout—View.layout；
performDraw—DecorView.draw—DecorView.onDraw—View.draw。

3）Measure、Layout、Draw 三大流程

Context.startActivity；
ActivityThread.handleLaunchActivity，执行 onCreate，完成 DecorView 和 Activity 的创建；
ActivityThread.handleResumeActivity，执行 onResume，完成 DecorView 添加到 WindowManager；
ViewRootImpl.performTraversals()，测量、布局、绘制，从 DecorView 自上而下遍历整个 View 树。

5.4 View 绘制屏幕刷新

CPU：主要负责 Measure、Layout、Record、Execute 数据计算工作；
GPU：负责栅格化（向量图形格式表示的图像转换成位图用于显示器）、渲染，渲染好后放到 buffer（图像缓冲区）里存起来；
Display：屏幕或显示器会以一定的帧率刷新，每次刷新时，就会从缓存区将图像数据读取显示出来，如果缓存区没有新数据，就一直用旧数据，这样屏幕看起来就没有变。

CPU 准备数据，通过 Driver 层把数据交给 GPU 渲染，Display 负责消费显示内容。

5.5 View 事件分发机制

定义：将事件（MotionEvent）传递到某个具体的 View & 处理的整个过程；
ViewRootImpl—DecorView—Activity—Window—DecorView(ViewGroup)—View：事件先到 DecorView 然后到 Window。当屏幕被触摸时，input 系统事件从 Native 层分发到 Framework 层，然后到 ViewRootImpl 的 DecorView，进一步到 Activity -> PhoneWindow -> DecorView，最后到 View；
DecorView 怎么将事件分发给 Activity 的？

a、在 DecorView 的 dispatchKeyEvent 方法内部通过 Window 获取 callback，然后执行 callback 的 dispatchKeyEvent ；

b、Activity 本身实现了 Window.Callback 接口，并设置给了 Window 的 callback，所以这里的 callback 其实就是 Activity，这样事件就传递到了 Activity；

为什么 DecorView 走了两遍：主要原因就是解耦。

ViewRootImpl 并不知道 Activity 的存在，它只是持有了 DecorView，所以先传给了 DecorView，而 DecorView 知道有 Activity，所以传给了 Activity；
Activity 也不知道有 DecorView ，它只是持有 PhoneWindow，于是这样一段调用链就形成了。