0x00 简介

本文没有介绍WMS调用ViewRootImpl#performTraverals方法开始的View的测量、布局、绘制流程(可参考View的工作原理)，而是介绍了View开始measure/layout/draw之前的一些流程，Activity、Window、View的关系，以及View的绘制时机。另外，分析了一个在子线程中也能更新View的场景。

先简单介绍Activity启动。

从startActivity开始 -> 调用Instrumentation -> Instrumentation通过Binder向AMS(ActivityManagerService)发请求，启动Activity。

启动Activity执行的操作：

1. 获取待启动的Activity组件信息。
2. 通过Instrumentation的newActivity方法使用类加载器创建Activity对象。
3. 尝试创建Application对象（如果Application已经创建，则不会重复创建）。
4. 创建ContextImpl对象，并通过Activity的attach方法来完成一些重要数据的初始化（包括让Activity跟Window关联）
5. 调用Activity的onCreate方法。

Activity其他生命周期的调用都是通过Binder向AMS发请求，然后执行的PIC操作，最后从ApplicationThread对生命周期调用。

层级关系：

View的层级关系

0x01 Window Attach到Activity上

Window如何跟Activity关联？
每一个Activity都包含了唯一一个PhoneWindow，这个就是Activity根Window（之所以是说根Window是因为在它上面可以增加更多其他的Window，例如：弹出框（dialog））

setContentView方法的的实现，其实是getWindow().setContentView()，也就是设置到Window上的。下面是Activity.java的源码，里面可以看到Activity跟Window、View的关系。

setContentView是把view设置到window上去

attach()方法中的getWindow获取的是PhoneWindow对象

这个PhoneView的代码片段，是在Activity类的attach()方法里的。

在 attach 的时候执行了PhoneWindow的初始化。
提到了 activity 的 attach 方法，该方法是在执行Activity启动时在ActivityThread里面的performLaunchActivity调用的。performLaunchActivity里面做了很多Activity启动过程具体的操作，例如：主题、记录Activity栈、执行Activity onCreate 方法等。

Window是一个抽象类，PhoneWindow继承Window。下面是PhoneWindow的setContentView方法。

PhoneWindow的setContentView方法

这个mContentParent是一个ViewGroup，「window的内容放置在这个viewGroup里。它既是mDecor本身，也是mDecor的孩子（孩子存放着内容）」：

mContentParent

所以，PhoneWindow里面包含了一个ViewGroup，setContentView其实就是将layout设置到了这个ViewGroup上了。

看上面的setContentView里，如果这个Window里的容器是空的，就installDecor。

PhoneWindow#installDecor()

这个方法很长，可以看到mDecor如果是空，就generateDecor,如下。

protected DecorView generateDecor() {
    return new DecorView(getContext(), -1);
}

DecorView是PhoneWindow类的一个内部类，继承于FrameLayout。
如果decor不为空，那么调用mDecor.setWindow(this)，把decor和PhoneWindow关联起来。

DecorView extends FrameLayout，是window的top-level view

mContentParent是install在DecorView上的（我以为mContentParent包含了DecorView，其实不是）。
至此，我们理解了Window是Activity和View的中间人。
上面的过程，可以简单提炼下：

1. Activity#getWindow().setContentView() 
2. Activity#attach() : mWindow = new PhoneWindow()
3. PhoneWindow#getContentView(), 
4. if(mContentParent == null) installDecor();

WindowManager控制View:

Window对View的操作是通过WindowManager来处理的。WindowManager提供在Window上添加View、移除View、更新View的操作。
然而可见 WindowManager 其实只是一个接口，真正的实现类是WindowManagerImpl
以addView为例，里面有点绕，直接忽略中间过程，最后执行addView的是通过ViewRootImpl完成Window的添加工作的，它执行了View的requestLayout方法，在requestLayout方法里会通过WindowSession完成Window的添加过程WindowSession是IWindowSession类型的，它是一个Binder对象，因此Window的添加工作其实是一次IPC调用。

到目前为止，通过setContentView方法，创建了DecorView和加载了我们提供的布局，但是这时，我们的View还是不可见的，因为我们仅仅是加载了布局，并没有对View进行任何的测量、布局、绘制工作。在View进行测量流程之前，还要进行一个步骤，那就是把DecorView添加至window中，然后经过一系列过程触发ViewRootImpl#performTraversals方法，在该方法内部会正式开始测量、布局、绘制这三大流程。

0x02 将DecorView添加至Window

每一个Activity组件都有一个关联的Window对象，用来描述一个应用程序窗口。
每一个应用程序窗口内部又包含有一个View对象，用来描述应用程序窗口的视图。
上文分析了创建DecorView的过程，现在则要把DecorView添加到Window对象中。
而要了解这个过程，我们首先要简单先了解一下Activity的创建过程：

首先，在ActivityThread#handleLaunchActivity中启动Activity，在这里面会调用到Activity#onCreate方法，从而完成上面所述的DecorView创建动作，当onCreate()方法执行完毕，在handleLaunchActivity方法会继续调用到ActivityThread#handleResumeActivity方法，我们看看这个方法的源码：

final void handleResumeActivity(IBinder token, boolean clearHide, boolean isForward) { 
    //...
    ActivityClientRecord r = performResumeActivity(token, clearHide); // 这里会调用到onResume()方法

    if (r != null) {
        final Activity a = r.activity;

        //...
        if (r.window == null && !a.mFinished && willBeVisible) {
            r.window = r.activity.getWindow(); // 获得window对象
            View decor = r.window.getDecorView(); // 获得DecorView对象
            decor.setVisibility(View.INVISIBLE);//注意是INVISIBLE
            ViewManager wm = a.getWindowManager(); // 获得windowManager对象
            WindowManager.LayoutParams l = r.window.getAttributes();
            a.mDecor = decor;
            l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION;
            l.softInputMode |= forwardBit;
            if (a.mVisibleFromClient) {
                a.mWindowAdded = true;
                wm.addView(decor, l); // 调用addView方法
            }
            //...
        }
    }
}

也就是说，在onResume的时候，会获取该activity所关联的window对象，DecorView对象，以及windowManager对象。

WindowManager是抽象类，它的实现类是WindowManagerImpl，所以后面调用的是WindowManagerImpl#addView方法。

WindowManager会调用ViewRootImpl#setView方法，并把DecorView作为参数传递进去。在这个方法内部，会通过跨进程的方式向WMS（WindowManagerService）发起一个调用，从而将DecorView最终添加到Window上，在这个过程中，ViewRootImpl、DecorView和WMS会彼此关联，至于详细过程这里不展开来说了。

最后通过WMS调用ViewRootImpl#performTraverals方法开始View的测量、布局、绘制流程。

这一部分总结：

1. WindowManagerService将Decor添加到Window上了。
2. WMS调用ViewRootImpl#performTraverals方法开始View的测量、布局、绘制流程。

[番外篇]: Android只在UI主线程修改UI，是个谎言吗？

先看一下，为什么这段代码能完美运行？

子线程setImageResource

我运行了一下，确实可以更新图片。
但我没有尝试，如果在onCreate()里面设置一个按钮，在点的时候再new Thread().start()会怎样。。我猜是会报错的。
为什么子线程也可以更新图片？

根据前文我们可以得知，Activity是在onResume执行之后，才将自身所在的Window添加到WindowManager中的，然后才会调用ViewRootImpl的setview方法才开始View绘制的，在绘制过程中才会检查是否在UI线程中

上面的代码之所以能运行，是因为ImageView还没有完全初始化，mAttachInfo是空的：

final AttachInfo ai = mAttachInfo;
final ViewParent p = mParent;
if (p != null && ai != null && l < r && t < b) {
    //....
    p.invalidateChild(this, damage);
}

所以括号里的invalidate也没有执行，ViewRootImpl的checkThread也没有执行。
也就是说其实并不是完全不能在子线程里操作，各种带UI的操作系统都只是尽量规避你这么做，因为这么做不好。

ViewRootImpl#checkThread

只要在创建Window/View/ViewRootView的线程更新UI，就是合法的，并不一定在UI线程。
知乎原帖的评论里有个大V说，这不就是Handler吗？
我感觉这个问题跟Handler还是不太一样的。Handler是在子线程处理复杂信息，处理完了通过MessageQueue或者post来抛回到原来的thread，是跨线程通信；View的绘制过程是在主线程的。他想表达的可能是，可以用view.post（实际上利用的是Handler）来实现在主线程更新View。

其实看前面的总结：

最后通过WMS调用ViewRootImpl#performTraverals方法开始View的测量、布局、绘制流程。

View的测量、布局、绘制流程是在ActivityThread调用handleResumeActivity之后，把decorView加入到window，把window add到windowmanager之后才开始的，所以在onCreate里setImageResource的时候，ViewRoot没有初始化整个view tree，ImageView的mAttachInfo是空的。

14 December 2017

[番外篇-2] 优化SplashActivity的启动速度

今天很高兴又遇到一个跟上面的番外1以及0x03都有联系的问题，也是我们App中一直存在的问题，就是进入Splash的时间过长的问题。为什么，之前钱包采用的是透明Activity的方案：

这两段Style，上面那段是优化前的，下面那段是优化后的

以前SplashActivity用的是上面那段Style，其实我一直非常愧疚，也一直尝试想要改变它，因为它的问题在于，我们的Application启动的过程很长，导致冷启动状态下点击应用图标到进入SplashActivity的时间，会有1.5秒之久，在性能差的手机上甚至更长。怎么办呢？虽然把Application中的初始化操作大量地都放到子线程/延后了(其实应该还有优化空间)，但是仍然难以避免，所以我们采取的策略就是上面那段代码，把背景设成透明，这样导致一个非常不好的体验，点击APP后很久才会展示Splash，这回让用户觉得自己没点到，甚至把锅推到Android系统身上，我感到非常难过，因为Android系统没那么差啊。

我之前就想到一个办法，就是下面那个Style，把透明色去掉，用Splash的placeholder图；同时一定要把windowAnimationStyle设置成null。这也是很多App都广泛采用的折衷方案，比如Bilibili，当时我在知乎上私信他们的一个开发，他告诉我去搜索冷启动白屏这样的关键字。

但是在我们的App上还有一个问题，就是我发现我们的App会「闪」一下（动画的样子，在不同的机器上不一样），在有些手机上表现得是「黑」一下。

解决闪一下的动画问题

我用控制变量法发现，「闪一下」是由于我们的SplashActivity启动过程中会有一个透明的PermissionActivity去请求权限。那我就怀疑，应该是PermissionActivity的动画造成的。但是我去看了下，PermissionActivity的主题动画也是上面那样写的null。咨询新来的同事，他让我在Acitivty的finish后面加一个：

overridePendingTransition(0, 0);

看了下，是手动指定入场和出场动画。

指定入场和出场动画

设置上之后，动画确实消失了。注意，这个要写在finish的后面，写在面的话会无效，可能是因为finish会覆盖掉原来设置的动画。

解决黑一下的问题(关键！！！！！！！)

但是在一些性能差的手机上，仍然存在「黑」一下的问题。
一句话总结：onCreate执行的时候view并没有展示出来，onResume中WMS调用ViewRootImpl#performTraverals才会展示出来，所以需要在view.post里面去调用permissionActivity，否则会显示黑色（黑色是什么，有可能是App的背景）。

其实这个问题就跟上面的番外1以及0x03都有联系了。说下原因和解决方法。
原因：
0x03里提到，
ActivityThread#handleLaunchActivity会去launch Activity
调用Activity#onCreate，完成DecorView的创建动作
然后handleLaunchActivity()会继续直接ActivityThread#handleResumeActivity方法（这个方法很关键）

让我们读一下源码：
首先会执行performResumeActivity去调用onResume();
然后会get一些列的东西，getWindow获取window，然后用window#getDecorView获取decor；
然后decor.setVisibility(View.INVISIBLE);

说下后面的步骤：
获取WindowManager：ViewManager wm = a.getWindowManager()
WindowManager会调用ViewRootImpl#setView方法，并把DecorView作为参数传递进去。
在这个方法内部，会通过跨进程的方式向WMS（WindowManagerService）发起一个调用，从而将DecorView最终添加到Window上。
最后通过WMS调用ViewRootImpl#performTraverals方法开始View的测量、布局、绘制流程。

最终，ImageView显示出来。
所以，之前我在onCreate()里，立刻去调用PermissionActivity，造成的问题跟上面的番外1一样，都是在View没有加载完就做别的事情了。这里黑一下是因为，ImageView还没有绘制完成，但是SplashActivity是透明的，那段黑色的时间，是从Theme到View绘制完成的时间的间隔。
解决的办法，imgView.post(new Runnable())；里执行PermissionActivity的操作。
但是，黑色是什么颜色？PermissionActivity的底下难道不是正在绘制的SplashActivity吗？所以我猜想，在从Theme的背景显示到Activity绘制完成的时间里，如果有别的Activity覆盖在上面，底下的Activity的Theme会被覆盖，所以会呈现黑色。

Ref:
http://www.jianshu.com/p/5297e307a688
http://blog.csdn.net/a553181867/article/details/51477040