添加流程_WMSWindow的添加流程

总览

我在上一篇文章介绍了 Activity 的启动流程，一直讲到到 WMS 这里结束，这篇文章讲沿着上篇文章的脉络继续分析下去。
这篇文章不仅仅是 Window 的添加过程，也会涉及到一些 WMS 相关的原理。我希望能通过了解 Window 添加流程来掌握整个 WMS 的架构，从而对其产生一个完整的印象，至于旁枝末节也不着急深入的理解，有空就看看，这样后面遇到相关的问题也能知道个大概。

先看一下 Window 的添加过程：

上一篇文章讲了 AMS 将会调用 WMS 中的几个方法，也就是上图中从 AMS 引出的箭头，WMS 的流程也是从这几个方法开始运转起来的。

Window

Window 是一个抽象类，实现类一般为 PhoneWindow，在 Activity#attach 中被创建，一个 Activity 对应一个 Window。

对于 AMS 来说，Activity 是一个基本操作单元，而对于 WMS 来说，Window 就是一个基本的操作单元。这意味着，对于一个页面来说，AMS 中的表现是 Activity，WMS 中的表现是 Window。

WMS 一切几乎都是为了服务 Window 所展开的，Window 主要具有两个功能，一个是负责展示页面，一个是接受触摸/按键事件。
先来看看 setContentView 方法：

public void setContentView(int layoutResID) {    //省略部分代码    //创建 DecorView    installDecor();    //加载资源文件到 DecorView 中    mLayoutInflater.inflate(layoutResID, mContentParent);    //回调 onContentChanged    getCallback().onContentChanged();}

上面代码中的注释已经很明确了，DecorView 待会在介绍，getCallback() 方法获取到的就是 Activity 中设置的 Callback，除此之外还包括触摸事件等等回调。
我们再来看看 installDecor 方法：

private void installDecor() {    //省略部分代码    //创建 DecorView    mDecor = generateDecor(-1);    //创建 ContentParent    mContentParent = (ViewGroup)mDecor.findViewById(com.android.internal.R.id.content);    //设置 Title    mTitleView = findViewById(R.id.title);    mTitleView.setText(mTitle);}

DecorView 是整个 Activity View 树的根节点，主要包含一个 Toolbar 以及内容区域 ContentParent。
上面代码的最后设置 Title 那里，并不是直接这么设置的，还有一些判断操作，还可能会设置 logo 图标等等。

然后就会调用 inflate 方法将我们设置的 layout 加载到 ContentParent 中去。

WindowManager

WindowManager 是个接口，实现类为 WindowManagerImpl，WindowManager 是 WindowManagerService 的低层次实现，其中提供了 WMS 的部分功能来应对大部分的场景，将会关联到特定的 Context 上下文，可以通过 Context.getSystemService(Context.WINDOW_SERVICE)获取到。
上一篇文章中说到，ActivityThread 会调用 WindowManager#addView 方法添加 mWindow.decorView，该方法内部会直接委托给WindowManagerGlobal#addView来实现，那么这个又是个什么鬼呢。

WindowManagerGlobal

WindowManagerGlobal 是一个单例类，全局唯一实现，同样也是 WMS 的低层级实现，与 WindowManager 不同的是，它与上下文是无关的。
上面说到 addView 走到了这个类中，我们再来看看 WindowManagerGlobal#addView：

public void addView(View view, ViewGroup.LayoutParams params,                    Display display, Window parentWindow) {    ViewRootImpl root = new ViewRootImpl(view.getContext(), display);    final WindowManager.LayoutParams wparams = (WindowManager.LayoutParams) params;    mViews.add(view);    mRoots.add(root);    mParams.add(wparams);    root.setView(view, wparams, panelParentView);}

这个方法最重要的是创建了一个 ViewRootImpl 实例，然后依次添加这三个对象到响应的集合中，再调用 root.setView 方法将 view 设置到 ViewRootImpl 中，也就是说，从 ActivityThread 中调用的 addView 现在又走到了 ViewRoot 中。
WindowManagerGlobal 作为一个全局的单例管理类，其中的 mViews、mRoots、mParams 三个集合保存了所有 Window 对应的 View，ViewRootImpl，Param，可以大概理解为是 ViewRootImpl 与 WindowManager 的桥梁。

ViewRootImpl

首先要说的是，ViewRootImpl 并不是一个 View，他是整个 View 的根节点，用来负责 View 与 WindowManager 进行通信。
setView 方法太长了，还有一堆调用，我直接把重点挑出来好了，内部还有很多乱七八糟的调用流程：

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {    int relayoutResult = mWindowSession.relayout(mWindow, mSeq, params,            (int) (mView.getMeasuredWidth() * appScale + 0.5f),            (int) (mView.getMeasuredHeight() * appScale + 0.5f), viewVisibility,            insetsPending ? WindowManagerGlobal.RELAYOUT_INSETS_PENDING : 0, frameNumber,            mTmpFrame, mPendingOverscanInsets, mPendingContentInsets, mPendingVisibleInsets,            mPendingStableInsets, mPendingOutsets, mPendingBackDropFrame, mPendingDisplayCutout,            mPendingMergedConfiguration, mSurfaceControl, mTempInsets);    mSurface.copyFrom(mSurfaceControl);    mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,            getHostVisibility(), mDisplay.getDisplayId(), mTmpFrame,            mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,            mAttachInfo.mOutsets, mAttachInfo.mDisplayCutout, mInputChannel,            mTempInsets);}

先调用 WMS 申请 Surface，然后调用 WMS 显示。主要就这两步，细节不追究了，我们这里关注的人是 Window 的添加流程。
其实到了这就大概知道是怎么回事了，Surface 是 SurfaceFlinger 中的概念，SurfaceFlinger 是具体负责图形显示的服务，我们这篇文章不准备继续深入下去，只要知道申请到了 Surface 就行，Surface 如何被显示等等都是 SurfaceFlinger 该关心的。
SurfaceFlinger 日常用的就比较少，我也还没学，暂时也不准备继续学下去了。
上面代码中的 mWindowSession 的实现类为 Session，内部调用了 WindowManagerService.relayoutWindow方法，我们现在把目光放到这个方法中。

WindowManagerService

WindowManagerService 就是整个 WMS 模块的核心了，负责整个 Android 系统的 Window 相关的工作。Window 的添加流程到了这里就差不多了，从这里开始是申请 Surface 的部分。具体对应WindowManagerService#relayoutWindow方法。
这个方法需要做的事情比较多，除了申请 Surface 之外，还需要考虑到 Window 的显示状态、是否正在进行动画、层级值分配等等，而申请 Surface 又是在WindowStateAnimator中实现的，WMS 与 SurfaceFlinger 的通信是放在WindowStateAnimator中的。
所以在调用WindowManagerService#relayoutWindow方法后，会再调用WindowStateAnimator#createSurfaceLocked方法创建 Surface，到了这就不继续看下去了，太深了，学无止境。

ViewRootImpl 中调用完 relayout 方法之后会继续调用 addToDisplay 方法，这个方法最终调用到了WindowManagerService#addView方法。而这个方法就是添加 Window 的最终方法。

其实里面很多细节都没顾及到，这么写有点水了，但是细节真的太多，而且书里面写的也很详细，我这里就是做了个总览，把整个流程大概捋一下，后面可以针对性的看看某一部分，如果对详细过程感兴趣的可以看看深入理解 Android 内核设计思想这本书，里面 WMS 和 SurfaceFlinger 部分写了块两百页，看得我头疼。

现在 AMS 和 WMS 学习阶段暂时先这样了，准备再看看函数式编程相关的概念，之前就看了 Java函数式编程这本书，但是看得比较快，而且那会函数式用的少，理解的不是很透彻，这次准备再看看，不仅仅看书，也会看看其他的文档等等，把函数式编程真正掌握才行。