1startActivity启动过程

假设从Activity A中跳转到另一个App中的Activity B，过程如下图所示：

整个startActivity的流程分为3部分，也涉及3个进程之间的交互：
1.Activity A 到 AMS；
2.AMS 到进程B中的ApplicationThread；
3.ApplicationThread 到 Activity B；

1.1 Activity A到AMS阶段

这一过程并不复杂，用一张图表示具体过程如下：

下面具体看看源码：

调用startActivity后，最终会调用到startActivityForResult方法，在startActivityForResult中，调用Instrumentation.exeStartActivity方法，把Activity的跳转交给类Instrumentation类去处理。

而在Instrumentation中，会通过ActivityManager.getService获取AMS的实例，然后调用其startActivity方法，至此，startActivity的工作重心从Activity A转移到类系统进程AMS中。

1.2AMS到ApplicationThread

这一步的流程看起来很负责，实际上就干了两件事：
1.综合处理launchMode和Intent中的Flag标志位，并根据处理结果生成一个目标Activity B的对象（ActivityRecord）；
2.判断是否需要位目标Activity B创建一个新的进程（ProcessRecord）、新的任务栈（TaskRecord）。

从AMS的startActivity看起：

经过多个方法的调用，最终通过obtainStarter方法获取了ActivityStarter类型的对象（ActivityStarter类是专门负责一个Activity的启动操作，主要作用包括解析Intent、创建ActivityRecord、创建TaskRecord等），然后调用其execute方法，在execute方法中，会再次调用其内部的startActivityMayWait方法：

从上图可以看出，获取目标Activity信息的操作由mSupervisor来实现，它是ActivityStackSupervisor类型，是负责Activity所处栈的管理类。在startActivityMayWait中调用类一个重载的startActivity方法，而最终会调用ActivityStarter中的startActivityUnchecked方法来获取启动Activity的结果。然后调用到realStartActivityLocked方法，在这个方法中，调用启动事物ClientTransaction的schedule方法，而这个transaction实际上是在创建ClientTransaction时传入的app.thread对象，也就是ApplicationThread。

1.3ApplicationThread到Activity

从ApplicationThread的scheduleTransaction方法开始，调用了ActivityThread中的scheduleTransaction方法，这个方法实际上实在ActivityThread的父类ClientTransactionHandler中实现的，具体代码如下：

调用sendMessage方法，向Handler中发送了一个EXECUTE_TRANSACTION的消息，并且Message中的obj就是启动Activity的事务对象，而这个Handler的具体实现是ActivityThread中的mH对象，代码如下：

最终调用了事务的execute方法，然后调用ActivityThread中的handleLaunchActivity方法：

1初始化Activity的WindowManager，每一个Activity都会对应一个窗口；
2调用performLauncheActivity创建并显示Activity
3通过反射创建目标Activity 对象
4调用attach方法建立Activity与Context之间的联系，创建PhoneWindow对象，并与Activity进行关联操作
5通过Instrumentation最终调用Activity的onCreate方法

2底层剖析Window、Activity、View三者关系

当我们需要显示Activity布局时，只需要在Activity 中添加一行setContentView即可，查看Activity中的源码如下：

可以看到，其实Activity几乎什么都每做，而是将操作直接交给Window处理的，getWindow返回的是Activity中的全局变量mWindow，是一个Window类型，它的赋值是在ActivityThread中的performLaunchActivity中，通过反射创建Activity对象后，执行attach方法，attach方法源码如下：

在Activity的attach方法中将一个PhoneWindow对象赋值给mWindow，接下来调用了setWindowManager方法将系统WindowManager传给PhoneWindow，如下图：

最终，在PhoneWindow中持有一个WindowManagerImpl的引用。

PhoneWindow的setContentView

Activity将setContentView的操作交给了PhoneWindow，接下来看看其实现过程：

图中1处判断mContentParent是否为空，为空则调用installDecor初始化DecorView和mContentParent
图中2处将传入的布局添加到mContentParent中。
可以看出，在PhoneWindow中默认有一个DecorView（是FrameLayout子类），在DecorView中默认自带一个mContentParent（ViewGroup类型），然后把xml中写的布局添加到mContentParent中，因此经过setContentView之后，PhoneWindow内部的View关系如下：

目前为止，PhoneWindow中只是创建类一个DecorView，并在DecorView中填充Activity中传入的布局，可是DecorView还没有跟Activity建立任何联系，也没有被绘制到界面上显示。我们知道，Activity执行到onCreate时并不可见，只有执行完onResume后Activity中的内容才是屏幕可见状态，这是因为在onCreate阶段只是初始化类Activity需要显示的内容，而在onResume阶段才会将PhoneWindow中的DecorView绘制到屏幕上。
在ActivityThread的handleResumeActivity中，会调用WindowManager的addView方法将DecorView添加到WMS，如下图：

WindowManager的addView结果有两个：
1.DecorView被渲染绘制到屏幕上显示；
2.DecorView可以接收屏幕触摸事件。

WindowManager的addView

PhoneWindow只是负责处理一些应用窗口通用的逻辑（设置标题栏，导航栏等），真正完成把一个View作为窗口添加到WMS的过程是由WindowManager来完成的。
WindowManager是接口类型，真正的实现者是WindowManagerImpl类，addView源码如下：

WindowManagerImpl也是一个空壳，它调用了WindowManagerGlobal的addView方法。WindowManagerGlobal是一个单例，每一个进程中只有一个实例对象，如上图红框所示，在addView方法中创建了一个最关键的ViewRootImpl对象，然后通过ViewRootImpl的setView方法将view添加到WMS。

ViewRootImpl的setView

图中1处的requestLayout是刷新布局的操作，调用此方法后ViewRootImpl所关联的View执行measure-layout-draw操作，确保View被添加到Window上显示到屏幕之前，已经完成测量和绘制操作。
图中2处调用mWindowSession的addToDisplay方法将View添加到WMS中。
WindowSession是WindowManagerGlobal中的单例对象，初始化代码如下：

sWindowSession实际上是IWindowSession类型，是一个Binder类型，真正的实现类是System进程中的Session。上图中红框中就是用AIDL获取System进程中Session的对象，addToDisplay方法如下：

图中的mService就是WMS，至此，Window已经成功的被传递给类WMS，剩下的工作就全部转移到系统system_server进程中的WMS来完成最终的添加操作。

再看Activity

上文提到addView成功有一个标志就是能够接收触碰事件，通过对setContentView流程的分析，可以看出添加View的操作实质上是PhoneWindow在全盘操作，背后负责人是WMS，而Activity没有任何参与。但是当触碰事件发生后，Touch事件首先是被传入到Activity，然后才被下发到布局中的ViewGroup和View，那么Touch事件是如何传递到Activity上的呢？
ViewRootImpl中的setView方法中，除了调用IWindowSession执行跨进程添加View之外，还有一项重要的操作就是设置输入事件的处理：

如上图红框中所示，设置了一系列的输入通道。一个触碰事件的发生是由屏幕发起，然后经过驱动层一系列的优化计算通过Socket跨进程通知AndroidFramework层（WMS），最终屏幕事件被发送到上图的输入管道中。
这些输入管道实际上是一个链表结构，当某一个屏幕触摸事件到达其中的ViewPostImeInpustState时，会经过onProcess来处理，如下：

可以看到在onProcess中最终调用来一个mView的dispatchPointerEvent方法，mView实际上就是PhoneWindow中的DecorView，而dispatchPointerEvent是被View.java实现的，如下：

最终调用来PhoneWindow中Callback的dispatchTouchEvent方法，这个Callback就是Activity，在启动Activity阶段，attach中有如下代码：

再看Activity的dispatchTouchEvent：

Touch事件在Activity中绕来一圈，最终回到PhoneWindow中的DecorView来处理。

小结

通过setContentView的流程，分析了Activity、Window、View之间的关系。整个过程Activity表面上参与度比较低，大部分View的添加操作都被封装到Window中实现。而Activity就相当于提供给开发人员的一个管理类，通过它能够更简单的实现Window和View的操作逻辑。以下几点需要注意：
1.一个Activity中有一个Window，也就是PhoneWindow对象，在PhoneWindow中有一个DecorView，在setContentView中会将layout填充到此DecorView中；
2.一个应用进程中只有一个WindowMnagerGlobal对象，因为在ViewRootImpl中它是static静态类型；
3.每一个PhoneWindow对应一个ViewRootImpl对象；
4.WindowManagerGlobal通过调用ViewRootImpl的setView方法，完成window的添加过程；
5.ViewRootImpl的setView方法中主要完成两件事情，View渲染（requestLayout）以及接收触屏事件。

3Android如何通过View进行渲染

上文介绍类Activity、Window和View之间的关系，了解了ViewRootImpl在整个过程中起到承上启下的作用。一方面ViewRootImpl中通过Binder通信机制，远程调用WindowSession将View添加到Window中，另一方面，ViewRootImpl在添加View之前，又需要调用requestLayout方法，执行完整的View树的渲染操作。

屏幕绘制

ViewRootImpl requestLayout流程
requestLayout第一次被调用是在setView中，从名字也能看出，这个方法的主要目的就是请求布局操作，其中包括View的测量、布局、绘制等

requestLayout源码如上图，注释1处检查是否为合法线程，一般情况下就是检查是否为主线程；
注释2处将请求布局标识符设置为true，这个参数决定了后续是否需要执行measure和layout操作；
最后执行scheduleTraversals方法，如下：

注释1处向主线程消息队列插入同步屏障消息，该方法发送一个没有target的Message到Queue中，在next方法中获取消息时，如果发现没有target的Message，则在一定的时间内跳过同步消息，优先执行异步消息，保证UI绘制操作优先执行。
注释2处调用Choregographer的postCallback方法，实际上也是发送一个Message到主线程消息队列。流程代码如下：

可以看出，最终通过Handler发送到MessageQueue中的Message被设置为异步消息。
mTraversalRunnable是一个实现Runnable接口的TraversalRunnable类型对象，其run方法如下：

在run方法中调用了doTraversal方法，并最终调用了performTraversals()方法，在这个方法里面会真正地开始View绘制流程：measure->layout->draw。

ViewRootImpl的performTraversals方法
这个方法比较重，源码有将近900行，但是抽取一下核心部分代码可以发现，这个方法只负责做3件事：

接下来以measure流程举例
我们知道View的测量是一层递归调用，递归执行子View的测量工作后，再最后决定父View的宽高，这个递归的起源就是DecorView。measureHierarchy方法源码如下：

这个方法中，通过getRootMeasureSpec方法获取了根View的MeasureSpec，实际上就是Window的宽高，然后调用performMeasure方法进行测量工作

ViewRootImpl的performMeasure

方法很简单，只是执行了mView的measure方法，这个mView就是DecorView，然后在DecorView的measure方法中会调用onMeasure方法，然后会递归调用子View的onMeasure方法。performLayout方法过程类似。

ViewRootImpl的performDraw

图中可以看出，在performDraw方法中，调用的是ViewRootImpl的draw方法，在draw方法中进行UI绘制操作。Android系统提供了2种绘制方式，图中1表示App开启了硬件加速功能，所以会启用硬件加速绘制；2处表示使用软件绘制。
ViewRootImpl中有一个非常重要的对象Surface，ViewRootImpl会将在draw方法中绘制的UI元素，绑定到这个Surface上，如果说Canvas是画板，那么Surface就是画板上的画纸，Surface中的内容最终会被传递给底层的SurfaceFlinger，最终将Surface中的内容进行合成并显示到屏幕。

软件绘制drawSoftware

1处就是调用DecorView的draw方法将UI元素绘制到画布Canvas对象中，2处将Canvas中的内容显示到屏幕上，实际上就是将Canvas中的内容提交给SurfaceFlinger进行合成处理。默认情况下软件绘制没有采用GPU渲染的方式，全部由CPU完成。
DecorView并没有覆写draw方法，因此实际上是调用顶层View的draw方法：

1处绘制View的背景，2绘制View自身内容，3表示对draw事件进行分发，在ViewGroup中会递归调用子View的draw。

硬件加速
是否启用硬件加速
在ViewRootImpl的draw方法中，通过以下判断是否启用硬件加速：

而启用硬件加速的设置，可以在manifest清单文件中，指定Application或者某个Activity支持硬件加速，如下：

此外还可以通过Window或者VIew在进行更小粒度的硬件加速设置：

需要注意的是，不是所有的2D绘制操作都支持硬件加速，如果在自定义View中使用了以下API，可能会造成程序工作不正常：
Canvas
clipPath()
clipRegion()
drawPicture()
drawPosText()
drawTextOnPath()
drawVertices()
Paint
setLinearText()
setMaskFilter()
setRasterizer()

硬件加速优势
接下来看看为什么硬件加速能够提高UI渲染的性能，ViewRootImpl的draw方法中，硬件加速部分代码如下：

图中mThreadRenderer是ThreadRenderer类型，其draw方法如下：

1处是硬件加速的特殊之处，通过updateRootDisplayList方法将View视图抽象成一个RenderNode对象，并构建View的DrawOp树；2处通知RenderThread进行绘制操作，RenderThread是一个单例线程，每个进程最多只有一个硬件渲染线程，所以不会有并发问题。
updateRootDisplayList方法如下：

Android硬件加速过程中，View属兔被抽象成RenderNode节点，View中的绘制操作都会被抽象成一个个DrawOp，每个DrawOp有对应的OpenGL绘制命令。绘制命令是由GPU执行的，GPU比CPU更擅长进行计算操作，所以整个流程会更加顺畅。

Invalidate轻量级刷新
Invalidate和requestLayout的区别在于，它不一定会触发View的measure和layout操作，多数情况下只执行draw操作。
postInvalidate和invalidate的区别是可以在非UI线程调用，原理是通过Handler方法发送消息到主线程去执行invalidate方法

Payne的小站

Android工程师进阶34讲-Android源码分析