注:源码分析基于 Android SDK API 28
在前一篇中,我们分析了 startActivity 的整个流程,并且也讲到了何时调用了 onCreate() 。
那么就会有一个疑问,其他的生命周期方法是在哪里被调用的呢?今天就来揭开这个谜底。
我们知道,Activity A 启动 Activity B ,其生命周期方法调用如下:
- Activity A onPause()
- Activity B onCreate()
- Activity B onStart()
- Activity B onResume()
- Activity A onStop()
那首先我们来看看 Activity A 的 onPause() 是什么地方调用的?
onPause()
在前一篇文章中讲到,startActivity 的流程中有一步是 resumeTopActivityInnerLocked 。
我们来看一下其中的源码片段:
1 | boolean pausing = mStackSupervisor.pauseBackStacks(userLeaving, next, false); |
从 startPausingLocked 方法的名字上来看,这就是去调用 onPause 方法的入口。
1 | final boolean startPausingLocked(boolean userLeaving, boolean uiSleeping, |
和调用 onCreate 一样,onPause 也是利用 Transaction 来完成的。不过这里的是 PauseActivityItem 。
追踪到 PauseActivityItem 的 execute 方法
1 | @Override |
发现还是一个套路,最终还是要去 ActivityThread 中找答案。
1 | @Override |
重点关注 performPauseActivity
1 | private Bundle performPauseActivity(ActivityClientRecord r, boolean finished, String reason, |
最终由 mInstrumentation 内部调用 Activity.performPause 。而 performPause 方法内部又调用了 onPause 。
1 | public void callActivityOnPause(Activity activity) { |
onCreate()
onCreate 的生命周期调用在前一篇中已经分析过了,所以在这里就不讲了。
如果有需要的话可以看前一篇博客。
onResume()
在前一篇中讲到,resumeTopActivityInnerLocked(ActivityRecord prev, ActivityOptions options)
方法中有一段代码
1 | transaction.setLifecycleStateRequest( |
可以看到 transaction 将最后的生命周期状态设置为了 resume 。
根据前一篇博客的分析,代码最后会执行 ResumeActivityItem.execute
1 | @Override |
可以看到在 execute 中调用了 ActivityThread 的 handleResumeActivity 方法。
1 | @Override |
在 handleResumeActivity 中调用了 performResumeActivity 来完成 Activity 的 resume 操作。
1 | @VisibleForTesting |
activity.performResume 的内部将 onResume 回调的操作交给了 mInstrumentation 来处理。
1 | final void performResume(boolean followedByPause, String reason) { |
在 mInstrumentation.callActivityOnResume 内部调用了 Activity 的 onResume 方法。
1 | public void callActivityOnResume(Activity activity) { |
onStart()
可能有些同学会觉得奇怪,怎么从 onCreate 直接跳到 onResume 了?不是应该还有一个 onStart 么?
那接下来,我们就来看看 onStart 是哪里被调用的。
话还要从 transaction 开始说起。
一开始 transaction 设置了 LaunchActivityItem ,然后又设置了生命周期状态 ResumeActivityItem 。
所以可以简单地看出,onCreate -> onResume ,中间并没有加 onStart 。那么 onStart 是哪里在调用呢?
我们来看下 TransactionExecutor.execute 方法。
1 | public void execute(ClientTransaction transaction) { |
经过上一篇中分析,我们知道执行 executeCallbacks(transaction);
之后,Activity 就完成了 onCreate 的调用,所以此时 Activity 的状态应该是 ON_CREATE 。
然后来看看 executeLifecycleState 方法。
1 | private void executeLifecycleState(ClientTransaction transaction) { |
重点来关注下 cycleToPath 方法。
1 | private void cycleToPath(ActivityClientRecord r, int finish, |
我们发现 mHelper.getLifecyclePath 返回的 path 直接传入到 performLifecycleSequence 方法中。
而 performLifecycleSequence 方法里面一堆 switch case 正是去调用生命周期的,可以看到有 ON_START 的身影。我们的可以猜想到,在 mHelper.getLifecyclePath 方法中应该会返回 ON_START 。这样在 performLifecycleSequence 中就会去调用 mTransactionHandler.handleStartActivity(r, mPendingActions)
了。
那么我们来看看 mHelper.getLifecyclePath 中的方法。
1 | @VisibleForTesting |
看完上面这一段代码,相信你已经大致的明白了吧。上面这段代码中主要做的就是把“中间路径”给计算出来。
比如起点是 ON_CREATE , 终点是 ON_RESUME 。所以“中间路径”就是 [ON_START, ON_RESUME] 。但是之前传入的 excludeLastState 参数是 true 。所以还要减掉最后一个终点,因为“中间路径”就是 [ON_START] 了。
这样一连贯起来,我们就明白了 onStart 是怎么调用了的吧!
那么接着看吧。有了 ON_START 后,会调用 ActivityThread.handleStartActivity
1 |
|
在 handleStartActivity 里面调用了 Activity.performStart
1 | final void performStart(String reason) { |
不出所料,performStart 中又调用了 mInstrumentation.callActivityOnStart(this)
在 callActivityOnStart 中直接调用 activity.onStart
1 | public void callActivityOnStart(Activity activity) { |
onStop()
最后,我们来看一下 onStop 。
在 ActivityThread 的 handleResumeActivity 方法中,末尾有一段代码
1 | r.nextIdle = mNewActivities; |
重点来关注下 Idler 。
1 | private class Idler implements MessageQueue.IdleHandler { |
可以看到,其中有一句 am.activityIdle(a.token, a.createdConfig, stopProfiling);
。
而 am 就是 AMS 了,所以我们需要去 AMS 里面看看。
1 | @Override |
用 mStackSupervisor 来处理 Activity 任务栈的操作。
1 | @GuardedBy("mService") |
上面这段代码有点长,其实我们只要关注以下这段代码就好了
// Stop any activities that are scheduled to do so but have been
// waiting for the next one to start.
for (int i = 0; i < NS; i++) {
r = stops.get(i);
final ActivityStack stack = r.getStack();
if (stack != null) {
if (r.finishing) {
stack.finishCurrentActivityLocked(r, ActivityStack.FINISH_IMMEDIATELY, false,
"activityIdleInternalLocked");
} else {
stack.stopActivityLocked(r);
}
}
}
发现如果 ActivityRecord 没有 finish 的话,就会调用 stack.stopActivityLocked(r);
那我们去 ActivityStack 中看看
1 | final void stopActivityLocked(ActivityRecord r) { |
一眼就看到了 onStop 调用的入口啦:
mService.getLifecycleManager().scheduleTransaction(r.app.thread, r.appToken,
StopActivityItem.obtain(r.visible, r.configChangeFlags));
经过上面这么多的分析,相信已经不用说这句代码意味着什么了吧!
我们直接看 StopActivityItem 的 execute 方法
1 | @Override |
和其他的一样,也是调用了 ActivityThread 的 handleStopActivity 方法。
1 | @Override |
关键代码 performStopActivityInner
1 | private void performStopActivityInner(ActivityClientRecord r, StopInfo info, boolean keepShown, |
内部会调用 performPauseActivityIfNeeded
1 | private void performPauseActivityIfNeeded(ActivityClientRecord r, String reason) { |
我们看到,还是利用 mInstrumentation 来调用 onStop
1 | public void callActivityOnPause(Activity activity) { |
好了,到这里就把整个 Activity 启动的生命周期回调流程都走了一遍,回去好好理解下吧。