1.问题引入
在网上看一些文章的时候，发现Activity启动后，何时开始绘制View，有不同的说法：
比如：
- 在Android应用层View绘制流程与源码分析中，包括我们的分析也知道：在Activity的onCreate方法中会调用setContentView，接下来的调用链是：PhoneWindow.setContentView -> ViewGroup.addView() -> ViewGroup.invalidate() -> ViewRootImpl.performTrvaersals()，按照这个说法，应该是在onCreate方法时就触发了绘制操作；
- 在你知道android的MessageQueue.IdleHandler吗？中又分析，是在ActivityThread.handleResumeActivity中先执行了onResume方法，又通过vm.addView方法触发的，所以是先执行Activity的onResume方法，才执行View的绘制；
我们通过平时的开发经验或者打log可以知道，View的绘制确实是在Activity的onResume方法之后才执行的，那为什么会出现这两种冲突呢？下边我们从源码来探索下。
2. 猜测
发生这种情况，我们猜测，虽然在onCreate方法执行以后调用了setContentView等调用链最后调用了requestLayout和invalidate，但是并没有触发真正的绘制操作；
3. 探究源码
这里，我们不打算深入探究Activity的启动流程，大家不熟悉的可以自行在网上查阅资料，我这里追踪的源码是基于Android8.0。
我们知道，在Activity启动的过程中，在ActivityThread中有几个关键的方法:handleLaunchActivity，performLaunchActivity，handleResumeActivity，这三个主要的方法基本完成了Activity的创建到启动工作。
performLaunchActivity先于handleResumeActivity执行
- Activity启动的过程中，ActivityThread#handleLauchActivity会调用ActivityThread#performLaunchActivity，接着又调用了ActivityThread#handleResumeActivity:
private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent, String reason) {
...
Activity a = performLaunchActivity(r, customIntent);
if(a != null) {
...
handleResumeActivity(r.token, false, r.isForward,
!r.activity.mFinished && !r.startsNotResumed, r.lastProcessedSeq, reason);
}
}
创建Window对象，与Activity产生联系
- 在performLaunchActivity方法里，主要做了如下三件事：
- 调用了Instrumentation#newActivity创建了Activity
- 调用了attch方法，新建了一个PhoneWindow对象，并把Activity设置为这个PhoneWindow的Callback回调（此时Activity与Window有了联系，但window中还没有View）
- 执行了Activity的onCreate\onStart回调
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
...
//new出了一个Activity
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
...
//创建Application对象，是个单例，没有则创建，有了则返回，一个进程一个Application
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
...
//attch方法内部创建了PhoneWindow对象，并把Activity设置为它的回调
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstances, config,
r.referrer, r.voiceInteractor, window, r.configCallback);
...
//执行Activity的onCreate回调
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}
...
//执行Activity的onStart回调
if (!r.activity.mFinished) {
activity.performStart();
r.stopped = false;
}
...
}
DecorView添加到Wdindow中
- 执行完performLaunchActivity后，在handleLaunchActivity后，又执行了handleResumeActivity方法，主要做了如下两件事（或者说我们现在最关心的两件事）：
- 执行了Activity的onResume回调：
- 把DecorView添加到Window中；
final void handleResumeActivity(IBinder token,
boolean clearHide, boolean isForward, boolean reallyResume, int seq, String reason) {
//执行Activity的onResume回调
r = performResumeActivity(token, clearHide, reason);
...
//将DecorView添加到Window中，然后将这个Window添加到WindowManagerService中
//然后开始可以执行整个View树的测量布局绘制工作
if (!a.mWindowAdded) {
a.mWindowAdded = true;
wm.addView(decor, l);
}
}
总结
- 由于onCreate会先于handleResumeActivity执行，我们在onCreate中调用了setContentView，也只是生成DecorView并给这个DecorView的内容设置了布局而已，此时还并没有把这个DecorView添加到Window中，同样，WMS中也还没有这个Window，所以此时并不能做任何事情（绘制、接收点击事件等），虽然调用了requestLayout和invalidate，并不会真正触发布局和重绘（因为还没有与ViewRootImpl进行绑定）
- Activity与Window产生联系，是在调用activity#attach方法中，生成了一个PhoneWindow，并把这个activity对象自身，设置给了Window的Callback回调（Activity实现了Window的Callback接口）
- Window与WindowManagerService产生联系，是在handleResumeActivity中，先执行了onResume方法，通过调用WindowManagerImpl#addView方法将这个Activity对应的DecorView添加到了这个Window中，addView方法是一个IPC操作，将这个Window也添加到了WindowManagerService中；
- ViewRootImpl与Window产生联系，是在WindowManagerImpl#addView方法中，这个过程中会new一个ViewRootImpl与DecorView相对应，保存在WindowManagerGloable中；
- 总的来说，就是setContentView生成了DecorView及其视图，在onResume之后才把这个视图添加进了Window和WMS中，具备了交互能力；