本文通过探索 Android 生命周期方法的源码，寻找 Activity 中 DecorView 绘制的真正时机。
背景
最初对生命周期中 Activity "可见"的理解是：相关 View 绘制完毕，并且可以从屏幕上看到。而网上很多文章中说 onStart（onResume）时可见。
最近阅读源码逻辑发现与上述结论有矛盾：Activity 的 DecorView 真正的绘制发生在 onResume 方法之后。
那么到底哪个是对的呢？
背景知识
WindowManager 通过 IPC 通信将 View 交给 WindowManagerService（WMS），WMS 继而创建 SurfaceSession 完成窗口的绘制。
源码分析
通过分别查找生命周期方法与绘制方法，将俩者触发顺序进行比较，找到可见在 Activity 生命周期里的真正时机。
生命周期方法的触发时机
这里直接分析 Android 系统通过 AMS 启动 ActivityThread 之后，ActivityThread 继而启动 Activity 的过程。以下为 8.0 源码。
onCreate 触发时机
ActivityThread 首先会调用 handleLaunchActivity() 方法：
private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent, String reason) {
...
Activity a = performLaunchActivity(r, customIntent); //1.
if (a != null) {
...
handleResumeActivity(r.token, false, r.isForward,
!r.activity.mFinished && !r.startsNotResumed, r.lastProcessedSeq, reason); //2.
handleLaunchActivity() 执行了注释1、2处的俩个关键方法。这里先分析注释1处的 performLaunchActivity：
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
...
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
...
performLaunchActivity 是 Activity 启动过程中非常重要的方法，它创建了 Context、Activtiy 等关键类，但这不是分析的重点。重点是在初始化这些关键类之后，会调用mInstrumentation.callActivityOnCreate()执行 Activity 的 onCreate 方法：
public void callActivityOnCreate(Activity activity, Bundle icicle,
PersistableBundle persistentState) {
prePerformCreate(activity);
activity.performCreate(icicle, persistentState);
postPerformCreate(activity);
}
看下 activity.performCreate：
final void performCreate(Bundle icicle, PersistableBundle persistentState) {
mCanEnterPictureInPicture = true;
restoreHasCurrentPermissionRequest(icicle);
if (persistentState != null) {
onCreate(icicle, persistentState);
} else {
onCreate(icicle);
}
...
}
所以 onCreate 的触发时机为：
ActivityThread.handleLaunchActivity -> ActivityThread.performLaunchActivity -> Instrumentation.callActivityOnCreate -> Activity.performCreate
onRestart & onStart 触发时机
接着看 handleLaunchActivity 源码中的注释2 -- handleResumeActivity ：
final void handleResumeActivity(IBinder token,
boolean clearHide, boolean isForward, boolean reallyResume, int seq, String reason) {
ActivityClientRecord r = mActivities.get(token);
...
//1.
r = performResumeActivity(token, clearHide, reason);
if (r != null) {
final Activity a = r.activity;
...
//2.
if (r.window == null && !a.mFinished && willBeVisible) {
r.window = r.activity.getWindow();
View decor = r.window.getDecorView();
decor.setVisibility(View.INVISIBLE);
ViewManager wm = a.getWindowManager();
WindowManager.LayoutParams l = r.window.getAttributes();
a.mDecor = decor;
l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION;
l.softInputMode |= forwardBit;
if (r.mPreserveWindow) {
a.mWindowAdded = true;
r.mPreserveWindow = false;
ViewRootImpl impl = decor.getViewRootImpl();
if (impl != null) {
impl.notifyChildRebuilt();
}
}
if (a.mVisibleFromClient) {
if (!a.mWindowAdded) {
a.mWindowAdded = true;
//3.
wm.addView(decor, l);
} else {
a.onWindowAttributesChanged(l);
}
}
...
这里只关注注释1处，首先调用了 performResumeActivity() 方法，而 performResumeActivity() 紧接着又调用了 Activity.performResume() ：
final void performResume(boolean followedByPause, String reason) {
performRestart(true /* start */, reason); //1.
...
mInstrumentation.callActivityOnResume(this); //2.
...
onPostResume();
...
}
先看 performRestart() 源码 ：
final void performRestart(boolean start, String reason) {
...
if (mToken != null && mParent == null) {
WindowManagerGlobal.getInstance().setStoppedState(mToken, false /* stopped */);
}
if (mStopped) {
mStopped = false;
synchronized (mManagedCursors) {
final int N = mManagedCursors.size();
for (int i=0; i<N; i++) {
ManagedCursor mc = mManagedCursors.get(i);
if (mc.mReleased || mc.mUpdated) {
if (!mc.mCursor.requery()) {
if (getApplicationInfo().targetSdkVersion
>= android.os.Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
throw new IllegalStateException(
"trying to requery an already closed cursor "
+ mc.mCursor);
}
}
mc.mReleased = false;
mc.mUpdated = false;
}
}
}
mCalled = false;
mInstrumentation.callActivityOnRestart(this); //1.
writeEventLog(LOG_AM_ON_RESTART_CALLED, reason);
...
if (start) {
performStart(reason); // 2.
}
}
}
注释1处，最终执行了 Activity.onRestart() 方法。
注释2处，调用 performStart ：
final void performStart(String reason) {
mActivityTransitionState.setEnterActivityOptions(this, getActivityOptions());
mFragments.noteStateNotSaved();
mCalled = false;
mFragments.execPendingActions();
mInstrumentation.callActivityOnStart(this); //1.
...
performStart() 调用了 mInstrumentation.callActivityOnStart(this)，它最终调用了 Activity.onStart()。
所以 onRestart 的触发时机为：
ActivityThread.handleLaunchActivity -> ActivityThread.handleResumeActivity -> ActivityThread.performResumeActivity -> Activity.performResume -> Activity.performRestart -> Instrumentation.callActivityOnRestart
onStart 的触发时机为：
ActivityThread.handleLaunchActivity -> ActivityThread.handleResumeActivity -> ActivityThread.performResumeActivity -> Activity.performResume -> Activity.performRestart -> Activity.performStart -> Instrumentation.callActivityOnStart
onResume 触发时机
回到上面的 performResume() 方法，performRestart() 执行完 onRestart()、onStart() 之后，紧接着调用了 Instrumentation.callActivityOnResume(this) 去执行 onResume() 方法。
onResume 的触发时机为：
ActivityThread.handleLaunchActivity -> ActivityThread.handleResumeActivity -> ActivityThread.performResumeActivity -> Activity.performResume -> Instrumentation.callActivityOnResume
绘制的触发时机
真实绘制发生在 WMS 所在的系统进程中，所以只要找到对应应用层的 WM 是什么时候添加的 DecorView 即可。
由上面的分析我们可知：
performResumeActivity() 方法分别执行了 onRestart()、onStart()、onResume
() 等生命周期函数。而在 handleResumeActivity() 源码中，我们可以看到在 performResumeActivity() 执行完毕后，才做了真实绘制操作：
final void handleResumeActivity(IBinder token,
boolean clearHide, boolean isForward, boolean reallyResume, int seq, String reason) {
ActivityClientRecord r = mActivities.get(token);
...
//1.
r = performResumeActivity(token, clearHide, reason);
if (r != null) {
final Activity a = r.activity;
...
//2.
if (r.window == null && !a.mFinished && willBeVisible) {
r.window = r.activity.getWindow();
View decor = r.window.getDecorView();
decor.setVisibility(View.INVISIBLE);
ViewManager wm = a.getWindowManager();
WindowManager.LayoutParams l = r.window.getAttributes();
a.mDecor = decor;
l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION;
l.softInputMode |= forwardBit;
if (r.mPreserveWindow) {
a.mWindowAdded = true;
r.mPreserveWindow = false;
ViewRootImpl impl = decor.getViewRootImpl();
if (impl != null) {
impl.notifyChildRebuilt();
}
}
if (a.mVisibleFromClient) {
if (!a.mWindowAdded) {
a.mWindowAdded = true;
//3.
wm.addView(decor, l);
} else {
a.onWindowAttributesChanged(l);
}
}
...
上述注释2、3，将 DecorView 交给了 WMS 去绘制，而通过前面分析可知，这个操作发生在 onResume 方法之后。
执行顺序图
总结
首先，handleResumeActivity() 不同于字面意思，它共计执行了 onRestart()、onStart()、onResume() 三个生命周期函数。
其次，wm.addView(decor, l) 发生在 handleResumeActivity() 之后，说明 View 的真正绘制发生在 onResume() 之后。而 onCreate() 中调用 setContentView() 只是创建 DecorView 并添加子视图，并没有真正开始绘制。
最后，有一些关键知识点需要了解，后续会专程研究，这里可以如下简单理解：
一个 View 从数据渲染为屏幕可见的视图，不是光靠应用层就能完成的。应用层只负责数据的处理，真正的渲染发生在系统层，俩者通过 Android 匿名共享内存进行通信。
应用层通过 ViewRootImpl（Surface），与系统层的 SurfaceFlinger 进行交互。其中 ViewRootImpl 可以简单理解为 View 在应用层数据的处理者，而 SurfaceFlinger 可以理解为 View 在系统层渲染的处理者。
WindowManager.addView 之后，相应窗口的 ViewRootImpl、以及对应系统层的 SurfaceSession 才会创建。后续添加、更新 View，都是通过 ViewRootImpl 触发 View 的三大方法，计算 View 数据，然后交给系统层 SurfaceFlinger 去绘制的。
所以上述 wm.addView(decor, l) 发生在 handleResumeActivity() 之后，可以得出 View 绘制发生在 onResume() 之后，就是基于此。
那么为什么网上很多文章都说 onStart（onResume）可见呢？上面说，应用层负责数据、系统层负责渲染。所以我的理解是：应用层对于 View 的可见性理解，是基于数据的，只要数据设置完毕，后续系统层级的绘制工作无需关心。而我这里的可见，是视觉意义上真正的绘制完毕，故不能抛开系统层的渲染，所以 Activity 中 DecorView 的可见发生在 onResume() 方法之后。
以上为个人理解，有异议欢迎留言。
