[Android]Activity/Window/View的关系以及View的绘制时机

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上,在这个过程中,ViewRootImplDecorView和WMS会彼此关联,至于详细过程这里不展开来说了。

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

这一部分总结:

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

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

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

子线程setImageResource

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

根据前文我们可以得知,Activity是在onResume执行之后,才将自身所在的Window添加到WindowManager中的,然后才会调用ViewRootImplsetview方法才开始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也没有执行,ViewRootImplcheckThread也没有执行。
也就是说其实并不是完全不能在子线程里操作,各种带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之后才开始的,所以在onCreatesetImageResource的时候,ViewRoot没有初始化整个view tree,ImageViewmAttachInfo是空的。


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);

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

最终,ImageView显示出来。
所以,之前我在onCreate()里,立刻去调用PermissionActivity,造成的问题跟上面的番外1一样,都是在View没有加载完就做别的事情了。这里黑一下是因为,ImageView还没有绘制完成,但是SplashActivity是透明的,那段黑色的时间,是从ThemeView绘制完成的时间的间隔。
解决的办法,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

推荐阅读更多精彩内容