前言
在上文Android Activity的创建流程中，我们讲到了ActivityThread创建Activity。并没有涉及到Activity的生命周期流转。本文就以Activity A启动Activity B，B再通过finish返回A这样的跳转逻辑，来看Activity的生命周期在AMS中的流转过程。阅读本文前需要对Activity的启动流程、AMS、Android进程间通讯等有一点了解。建议提前阅读
开始之前先放上官方的生命周期简化图：
同时放上本文中启动逻辑下的生命周期流转方式：
- A启动B：A:onPause->B:onCreate->B:onStart->B:onResume->A:onStop
- B返回A：B:onPause->A:onRestart->A:onStart->A:onResume->B:onStop->B:onDestroy
接下来我们跟着a.startActivity方法启动B的源码来看一下Activity的生命周期的流转过程。
Activity启动过程中的生命周期流转(A->B)
当A Activity调用了startActivity(Intent(this,B::class.java))方法后，其中的主要流程我们已经在Android Activity的创建流程中介绍过了，这次我们直接从和生命周期流转有关的地方开始。也就是当startActivity经过层层调用走得到了ActivityStack的resumeTopActivityInnerLocked。该方法在Android Activity的创建流程也有过讲解。我们在那篇文章中也提过这里会调用Activity的onPause方法。接下来我们就分析一下它的调用逻辑：
A Activity的onPause调用逻辑
关键代码如下：
boolean resumeTopActivityUncheckedLocked(ActivityRecord prev, ActivityOptions options) {
boolean pausing = getDisplay().pauseBackStacks(userLeaving, next, false);
if (mResumedActivity != null) {
pausing |= startPausingLocked(userLeaving, false, next, false);
}
//...
}
final boolean startPausingLocked(boolean userLeaving, boolean uiSleeping,
ActivityRecord resuming, boolean pauseImmediately) {
ActivityRecord prev = mResumedActivity;
mPausingActivity = prev;//标记当前要进入Pause状态的Activity
if (prev.attachedToProcess()) {
try {
mService.getLifecycleManager().scheduleTransaction(prev.app.getThread(),
prev.appToken, PauseActivityItem.obtain(prev.finishing, userLeaving,
prev.configChangeFlags, pauseImmediately));
} catch (Exception e) {}
}
}
在Activity启动之前，会调用startPausingLocked方法，令当前Activity进入onPause状态。其中的关键是： mService.getLifecycleManager().scheduleTransaction。我们着重分析一下这里。
其中mService就是ActivityTaskManagerService的实例，getLifecycleManager()返回的ClientLifecycleManager的scheduleTransaction方法代码如下：
void scheduleTransaction(@NonNull IApplicationThread client, @NonNull IBinder activityToken,
@NonNull ActivityLifecycleItem stateRequest) throws RemoteException {
final ClientTransaction clientTransaction = transactionWithState(client, activityToken,
stateRequest);
scheduleTransaction(clientTransaction);
}
private static ClientTransaction transactionWithState(@NonNull IApplicationThread client,
@NonNull IBinder activityToken, @NonNull ActivityLifecycleItem stateRequest) {
//创建ClientTransaction，并将其mLifecycleStateRequest设置为stateRequest
//也就是前面的PauseActivityItem实例
final ClientTransaction clientTransaction = ClientTransaction.obtain(client, activityToken);
clientTransaction.setLifecycleStateRequest(stateRequest);
return clientTransaction;
}
void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
final IApplicationThread client = transaction.getClient();
transaction.schedule();
if (!(client instanceof Binder)) {
transaction.recycle();
}
}
代码并不复杂，经过重载调用ClientTransaction的schedule方法。
private IApplicationThread mClient;
public void schedule() throws RemoteException {
mClient.scheduleTransaction(this);
}
代码更简单了，这里mClient是IApplicationThread的客户端实例，IApplicationThread本身是个AIDL，在ActivityThread作为内部类被实现。这里就是AMS利用AIDL（AIDL工作原理）和ActivityThread的通讯了。可以发现，AMS做为服务端，将ClientTransaction通过scheduleTransaction整个发送给了ActivityThread。而scheduleTransaction在ActivityThread里的实现如下：
@Override
public void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
ActivityThread.this.scheduleTransaction(transaction);
}
调用了ActivityThread的scheduleTransaction方法，该方法在其父类ClientTransactionHandler中实现：
void scheduleTransaction(ClientTransaction transaction) {
transaction.preExecute(this);
sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction);
}
这里调用了sendMessage方法，是利用ActivityThread里内部类H实现的，它就是一个Handler消息循环机制。因为Binder服务端接收到的消息是运行在Binder线程池中的，这里首先切换到主线程中。在执行后续操作。ActivityThread 的sendMessage方法有很多重载，我们就不展开了，我们只看它是如何处理消息的：
case EXECUTE_TRANSACTION:
final ClientTransaction transaction = (ClientTransaction) msg.obj;
mTransactionExecutor.execute(transaction);
if (isSystem()) {
transaction.recycle();
}
break;
调用了TransactionExecutor的execute方法：
public void execute(ClientTransaction transaction) {
//..
executeCallbacks(transaction);
executeLifecycleState(transaction);
}
public void executeCallbacks(ClientTransaction transaction) {
final int lastCallbackRequestingState = lastCallbackRequestingStafinal List<ClientTransactionItem> callbacks = transaction.getCallbacks();
final int size = callbacks.size();
for (int i = 0; i < size; ++i) {
//..
item.execute(mTransactionHandler, token, mPendingActions);
item.postExecute(mTransactionHandler, token, mPendingActions);
//..
if (postExecutionState != UNDEFINED && r != null) {
// Skip the very last transition and perform it by explicit state request instead.
final boolean shouldExcludeLastTransition =
i == lastCallbackRequestingState && finalState == postExecutionState;
cycleToPath(r, postExecutionState, shouldExcludeLastTransition, transaction);
}
}
}
private void executeLifecycleState(ClientTransaction transaction) {
final ActivityLifecycleItem lifecycleItem = transaction.getLifecycleStateRequest();
//..
lifecycleItem.execute(mTransactionHandler, token, mPendingActions);
lifecycleItem.postExecute(mTransactionHandler, token, mPendingActions);
}
其中ClientTransaction中两个成员变量的实现如下：
private List<ClientTransactionItem> mActivityCallbacks;
private ActivityLifecycleItem mLifecycleStateRequest;
从上文中的代码中不难发现，**TransactionExecutor的execute的主要目的就是调用ClientTransactionItem的execute和ActivityLifecycleItem的execute方法。而且分别通过executeCallbacks和executeLifecycleState两个方法依次调用ClientTransaction的所有callbacks和lifecycleStateRequest(ActivityLifecycleItem)的方法。**那么ClientTransactionItem和ActivityLifecycleItem又是什么呢？
还记得上文的PauseActivityItem吗？它的继承关系如下：
**本质上都继承自BaseClientRequest，都是为了驱动Activity的生命周期调用。ClientTransaction中可能有多个BaseClientRequest的实现，分别是在mActivityCallbacks和mLifecycleStateRequest中存储。execute方法本质就是依次执行这些类具体实现的BaseClientRequest定义的方法。**这里的cycleToPath方法我们先不展开，下文中遇到了再讲。
不难发现，本质上就是执行PauseActivityItem的execute方法：
public void execute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityPause");
client.handlePauseActivity(token, mFinished, mUserLeaving, mConfigChanges, pendingActions,
"PAUSE_ACTIVITY_ITEM");
Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
}
此处的client就是我们的ActivityThread了，它继承自ClientTransactionHandler，client.handlePauseActivity方法实现如下：
@Override
public void handlePauseActivity(IBinder token, boolean finished, boolean userLeaving,
int configChanges, PendingTransactionActions pendingActions, String reason) {
ActivityClientRecord r = mActivities.get(token);
if (r != null) {
performPauseActivity(r, finished, reason, pendingActions);
//..
}
}
private Bundle performPauseActivity(ActivityClientRecord r, boolean finished, String reason,
PendingTransactionActions pendingActions) {
//..
performPauseActivityIfNeeded(r, reason);
//..
}
private void performPauseActivityIfNeeded(ActivityClientRecord r, String reason) {
//..
mInstrumentation.callActivityOnPause(r.activity);
//..
}
代码很简单，调用了Instrumentation的callActivityOnPause：
public void callActivityOnPause(Activity activity) {
activity.performPause();
}
然后调用Activity的performPause：
final void performPause() {
dispatchActivityPrePaused();
mDoReportFullyDrawn = false;
mFragments.dispatchPause();
mCalled = false;
onPause();
writeEventLog(LOG_AM_ON_PAUSE_CALLED, "performPause");
mResumed = false;
if (!mCalled && getApplicationInfo().targetSdkVersion
>= android.os.Build.VERSION_CODES.GINGERBREAD) {
throw new SuperNotCalledException(
"Activity " + mComponent.toShortString() +
" did not call through to super.onPause()");
}
dispatchActivityPostPaused();
}
很明显，这里就是调用了Activity的onPause方法。
还没完，上文中说的BaseClientRequest定义了三个方法：preExecute、execute和postExecute。根据名字不难看出三个方法的作用和执行顺序。我们重点关注后面两个方法：execute和postExecute。每次它们都是依次执行，我们看看PauseActivityItem的postExecute做了什么：
public void postExecute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
if (mDontReport) {
return;
}
try {
// TODO(lifecycler): Use interface callback instead of AMS.
ActivityTaskManager.getService().activityPaused(token);
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
}
调用了AMS（此处对应的是ActivityTaskManagerService）的activityPaused方法，当然了，也是通过AIDL方法，对AIDL还不了解的可以看Android里的多进程和跨进程通讯方式。activityPaused的实现如下：
public final void activityPaused(IBinder token) {
final long origId = Binder.clearCallingIdentity();
synchronized (mGlobalLock) {
ActivityStack stack = ActivityRecord.getStackLocked(token);
if (stack != null) {
stack.activityPausedLocked(token, false);
}
}
Binder.restoreCallingIdentity(origId);
}
关键之处是调用了ActivityStack的activityPausedLocked方法，其中的调用逻辑如下：
final void activityPausedLocked(IBinder token, boolean timeout) {
final ActivityRecord r = isInStackLocked(token);
if (r != null) {
mHandler.removeMessages(PAUSE_TIMEOUT_MSG, r);
//注意，此处在上文startPausingLocked方法中已经
//将mPausingActivity标记过了，所以此处mPausingActivity == r
//的值为true
if (mPausingActivity == r) {
//..
try {
completePauseLocked(true /* resumeNext */, null /* resumingActivity */);
} finally {
mService.mWindowManager.continueSurfaceLayout();
}
return;
}
//..
}
mRootActivityContainer.ensureActivitiesVisible(null, 0, !PRESERVE_WINDOWS);
}
private void completePauseLocked(boolean resumeNext, ActivityRecord resuming) {
ActivityRecord prev = mPausingActivity;
if (prev != null) {
//..
addToStopping(prev, true /* scheduleIdle */, false /* idleDelayed */,
"completePauseLocked");
//..
}
mPausingActivity = null;
}
private void addToStopping(ActivityRecord r, boolean scheduleIdle, boolean idleDelayed,
String reason) {
if (!mStackSupervisor.mStoppingActivities.contains(r)) {
//..
mStackSupervisor.mStoppingActivities.add(r);
}
//..
}
代码的逻辑很清晰，在ActivityThread调用了Activity的onPause方法之后，ActivityThread会告知AMS，然后AMS将该Activity添加到ActivityStackSupervisor的mStoppingActivities中：**其中，mStoppingActivities是一个ArrayList类型，用来存储那些标记为需要调用onStop方法的Activity信息。这里非常关键，因为新启动的Activity在显示之后，AMS就是通过mStoppingActivities来确定哪些Activity是需要调用onStop方法的。**同理，ActivityStackSupervisor 中的mFinishingActivities成员变量也是这个用处，不过它的作用是存储需要被销毁的Activity的信息的。
此时，A Activity已经被调用了onPasue方法了。在看B Activity的流程之前，我们还要继续了解一下ActivityLifecycleItem，它在系统中有一下几个实现：
- PauseActivityItem；
- StartActivityItem；
- ResumeActivityItem；
- StopActivityItem；
- DestroyActivityItem
- LaunchActivityItem
- ...
相信看到这些命名规则，就一定知道它们的作用了。没错，这些名字就是对应了Activity的生命周期。结合上文中PauseActivityItem 的讲解，不难理解AMS正式通过这些类实现对Activity生命周期的管理的。当然，这其中是使用AIDL，通过跨进程通信借助ActivityThread使用Instrumentation进行管理的。但是它们并不是和Activity生命周期一一对应的，reStart就是确实的。因为它是通过其他生命周期驱动的。
到此为止，ActivityLifecycleItem的关键已经介绍完了，AMS都是通过这种方式管理生命周期的。下文中就不再介绍它们的调用流程了，我们就直接看他们的实现，也就是preExecute、execute和postExecute方法了。
接下来就是被启动的Activity B的调用逻辑了
B Activity的onCreate、onStart和onResume
我们接着Android Activity的创建流程中的末尾将，也就是中的ActivityThread的performLaunchActivity方法，注意该方法的调用链来自于LaunchActivityItem的execute方法，详细代码就不展开了。
performLaunchActivity的代码如下：
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
ActivityInfo aInfo = r.activityInfo;
//..
Activity activity = null;
try {
java.lang.ClassLoader cl = appContext.getClassLoader();
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
//..
}
//..
try {
//..
if (activity != null) {
CharSequence title = r.activityInfo.loadLabel(appContext.getPackageManager());
//..
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,
r.assistToken);
//..
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}
//..
}
} //..
return activity;
}
这段代码做了三个工作：通过反射创建Activity实例、调用Activity的attach方法和调用Instrumentation的callActivityOnCreate方法，该方法有重载，但最终实现为：
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) {
//..
if (persistentState != null) {
onCreate(icicle, persistentState);
} else {
onCreate(icicle);
}
//..
}
最终，调用了Activity的onCreate方法。接下来就应该轮到onStart和onResume了。
还记得上文中的TransactionExecutor.cycleToPath方法还未讲解吗？看一下它的实现：
private void cycleToPath(ActivityClientRecord r, int finish, boolean excludeLastState,
ClientTransaction transaction) {
final int start = r.getLifecycleState();
final IntArray path = mHelper.getLifecyclePath(start, finish, excludeLastState);
performLifecycleSequence(r, path, transaction);
}
private void performLifecycleSequence(ActivityClientRecord r, IntArray path,
ClientTransaction transaction) {
final int size = path.size();
for (int i = 0, state; i < size; i++) {
state = path.get(i);
if (DEBUG_RESOLVER) {
Slog.d(TAG, tId(transaction) + "Transitioning activity: "
+ getShortActivityName(r.token, mTransactionHandler)
+ " to state: " + getStateName(state));
}
switch (state) {
case ON_CREATE:
mTransactionHandler.handleLaunchActivity(r, mPendingActions,
null /* customIntent */);
break;
case ON_START:
mTransactionHandler.handleStartActivity(r, mPendingActions);
break;
case ON_RESUME:
mTransactionHandler.handleResumeActivity(r.token, false /* finalStateRequest */,
r.isForward, "LIFECYCLER_RESUME_ACTIVITY");
break;
case ON_PAUSE:
mTransactionHandler.handlePauseActivity(r.token, false /* finished */,
false /* userLeaving */, 0 /* configChanges */, mPendingActions,
"LIFECYCLER_PAUSE_ACTIVITY");
break;
case ON_STOP:
mTransactionHandler.handleStopActivity(r.token, false /* show */,
0 /* configChanges */, mPendingActions, false /* finalStateRequest */,
"LIFECYCLER_STOP_ACTIVITY");
break;
case ON_DESTROY:
mTransactionHandler.handleDestroyActivity(r.token, false /* finishing */,
0 /* configChanges */, false /* getNonConfigInstance */,
"performLifecycleSequence. cycling to:" + path.get(size - 1));
break;
case ON_RESTART:
mTransactionHandler.performRestartActivity(r.token, false /* start */);
break;
default:
throw new IllegalArgumentException("Unexpected lifecycle state: " + state);
}
}
}
其中：getLifecyclePath() 方法就是根据 start 和 finish 计算出中间的生命周期路径，根据我们的代码流转不难发现，该路径只有onStart，也就是最终调用mTransactionHandler.handleStartActivity(r, mPendingActions);：
public void handleStartActivity(ActivityClientRecord r,
PendingTransactionActions pendingActions) {
//
// Start
activity.performStart("handleStartActivity");
//..
}
}
final void performStart(String reason) {
//..
mInstrumentation.callActivityOnStart(this);
}
最终，还是调用Instrumentation.callActivityOnStart方法了，就不展开该方法了，里面直接调用了Activity的onStart方法。
这时，我们就再要看一下ActivityStackSupervisor中realStartActivityLocked方法：
boolean realStartActivityLocked(ActivityRecord r, WindowProcessController proc,
boolean andResume, boolean checkConfig) throws RemoteException {
final ClientTransaction clientTransaction = ClientTransaction.obtain(
proc.getThread(), r.appToken);
clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),
System.identityHashCode(r), r.info,
// TODO: Have this take the merged configuration instead of separate global
// and override configs.
mergedConfiguration.getGlobalConfiguration(),
mergedConfiguration.getOverrideConfiguration(), r.compat,
r.launchedFromPackage, task.voiceInteractor, proc.getReportedProcState(),
r.icicle, r.persistentState, results, newIntents,
dc.isNextTransitionForward(), proc.createProfilerInfoIfNeeded(),
r.assistToken));
//启动时此处andResume传来的为true
if (andResume) {
lifecycleItem = ResumeActivityItem.obtain(dc.isNextTransitionForward());
} else {
lifecycleItem = PauseActivityItem.obtain();
}
clientTransaction.setLifecycleStateRequest(lifecycleItem);
}
其中和ClientTransaction创建的代码如上。可以看到：里面设置了mLifecycleStateRequest参数为ResumeActivityItem，根据上文中对ClientTransaction的讲解，我们知道，在执行完ClientTransaction的callBaclk，也就是(LaunchActivityItem的execute方法后。紧接着会执行mLifecycleStateRequest的execute方法。也就是ResumeActivityItem的execute方法：
public void execute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
client.handleResumeActivity(token, true /* finalStateRequest */, mIsForward,
"RESUME_ACTIVITY");
}
又是AIDL跨进程调用了ActivityThread端的方法，跟踪client.handleResumeActivity方法:
public void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward,
String reason) {
//..重点1
final ActivityClientRecord r = performResumeActivity(token, finalStateRequest, reason);
//..重点2
Looper.myQueue().addIdleHandler(new Idler());
}
其调用逻辑逻辑依旧和上文中的onPause流程一样：ActivityThread-> Instrumentation->Activity。最终执行Activity. performResume
final void performResume(boolean followedByPause, String reason) {
performRestart(true /* start */, reason);
//..
mInstrumentation.callActivityOnResume(this);
//..
}
final void performRestart(boolean start, String reason) {
if (mStopped) {
mStopped = false;
mInstrumentation.callActivityOnRestart(this);
if (start) {
performStart(reason);
}
}
}
代码逻辑很简单，首先performRestart方法，如果Activity处于stop状态，调用onRestart方法，紧着这调用onStart方法，然后调用Instrumentation.callActivityOnResume方法。这里我们是新创建的Activity，现在处于的是start状态就是直接走callActivityOnResume流程了。又是通过Instrumentation最终调用了Activity的onResume方法。
至此，新启动的B Activity的onResume方法已经被调用了。接下来就轮到A Activity的onStop方法了。
A Activity的onStop方法
留意上文中的handleResumeActivity方法中的重点二：Looper.myQueue().addIdleHandler(new Idler());。这里是个IdleHandler。最终的调用逻辑是：
private class Idler implements MessageQueue.IdleHandler {
@Override
public final boolean queueIdle() {
ActivityClientRecord a = mNewActivities;
//..
if (a != null) {
IActivityTaskManager am = ActivityTaskManager.getService();
ActivityClientRecord prev;
do {
if (a.activity != null && !a.activity.mFinished) {
try {
am.activityIdle(a.token, a.createdConfig, stopProfiling);
a.createdConfig = null;
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
}
} while (a != null);
}
//..
}
}
整个逻辑是当我们的B Activity处于闲时状态时，又是通过AIDL，调用了ActivityTaskManagerServer的activityIdle方法：
public final void activityIdle(IBinder token, Configuration config, boolean stopProfiling) {
final long origId = Binder.clearCallingIdentity();
try {
//
final ActivityRecord r = mStackSupervisor.activityIdleInternalLocked(token,
false /* fromTimeout */, false /* processPausingActivities */, config);
//..
}
} finally {
Binder.restoreCallingIdentity(origId);
}
}
接着看ActivityStackSuperVisor的activityIdleInternalLocked方法：
final ActivityRecord activityIdleInternalLocked(final IBinder token, boolean fromTimeout,
boolean processPausingActivities, Configuration config) {
ActivityRecord r = ActivityRecord.forTokenLocked(token);
if (r != null) {
//查找所有需要stop的Activity
final ArrayList<ActivityRecord> stops = processStoppingActivitiesLocked(r,
true /* remove */, processPausingActivities);
NS = stops != null ? stops.size() : 0;
for (int i = 0; i < NS; i++) {
r = stops.get(i);
final ActivityStack stack = r.getActivityStack();
if (stack != null) {
if (r.finishing) {
//如果Activity被标记为需要finish
stack.finishCurrentActivityLocked(r, ActivityStack.FINISH_IMMEDIATELY, false,
"activityIdleInternalLocked");
} else {
stack.stopActivityLocked(r);
}
}
}
//..
return r;
}
final ArrayList<ActivityRecord> processStoppingActivitiesLocked(ActivityRecord idleActivity,
boolean remove, boolean processPausingActivities) {
ArrayList<ActivityRecord> stops = null;
for (int activityNdx = mStoppingActivities.size() - 1; activityNdx >= 0; --activityNdx) {
ActivityRecord s = mStoppingActivities.get(activityNdx);
if (remove) {
final ActivityStack stack = s.getActivityStack();
final boolean shouldSleepOrShutDown = stack != null
? stack.shouldSleepOrShutDownActivities()
: mService.isSleepingOrShuttingDownLocked();
if (!animating || shouldSleepOrShutDown) {
stops.add(s);
mStoppingActivities.remove(activityNdx);
}
}
}
return stops;
}
关键代码如上，工作流程大致为：首先找到所有需要stop的Activity，方法是在成员变量mStoppingActivities里找。没错，它就是上文中我们调用A Activity的onPause时通过addToStopping将A添加进去的。而此时，我们的Activity并没有标记为finish，所以最终的调用逻辑为：ActivityStack.stopActivityLocked
final void stopActivityLocked(ActivityRecord r) {
//..
if (r.attachedToProcess()) {
try {
mService.getLifecycleManager().scheduleTransaction(r.app.getThread(), r.appToken,
StopActivityItem.obtain(r.visible, r.configChangeFlags));
}
}
发现了 StopActivityItem，那么问题就简单了：看它的execute方法：
public void execute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityStop");
client.handleStopActivity(token, mShowWindow, mConfigChanges, pendingActions,
true /* finalStateRequest */, "STOP_ACTIVITY_ITEM");
Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
}
追踪ActivityThread端的handleStopActivity方法：ActivityThread.handleStopActivity->ActivityThread.performStopActivityInner->ActivityThread.callActivityOnStop->Activity.performStop->Instrumentation.callActivityOnStop:
public void callActivityOnStop(Activity activity) {
activity.onStop();
}
最终，调用了Activity的onStop方法。
Activity返回过程中的生命周期流转(B->A)
当B调用了finish方法之后，其方法流转过程如下：Activity.finish->ActivityTaskManagerService.finishActivity->ActivityStack.requestFinishActivityLocked->ActivityStack.startPausingLocked。马上开始的就是A的onPause方法
B Activity的onPause调用逻辑
马上看ActivityStack.startPausingLocked的代码：
final boolean startPausingLocked(boolean userLeaving, boolean uiSleeping,
ActivityRecord resuming, boolean pauseImmediately) {
if (prev.attachedToProcess()) {
if (DEBUG_PAUSE) Slog.v(TAG_PAUSE, "Enqueueing pending pause: " + prev);
try {
EventLogTags.writeAmPauseActivity(prev.mUserId, System.identityHashCode(prev),
prev.shortComponentName, "userLeaving=" + userLeaving);
mService.getLifecycleManager().scheduleTransaction(prev.app.getThread(),
prev.appToken, PauseActivityItem.obtain(prev.finishing, userLeaving,
prev.configChangeFlags, pauseImmediately));
}
}
没有丝毫意外，这里又出现了PauseActivityItem，在上文中我们已经就A启动B时，A的onPause方法调用逻辑进行了分析，对B也是如此。通过PauseActivityItem的execute方法执行，这里就不再描述了。
A Activity的onRestart、onStart和onResume
此时，PauseActivityItem的postExecute方法排上了用场：
public void postExecute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
if (mDontReport) {
return;
}
try {
ActivityTaskManager.getService().activityPaused(token);
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
}
调用逻辑如下：ActivityTaskManagerService.activityPaused->ActivityStack.activityPausedLocked-> ActivityStack.completePauseLocked等等。这里经过了一堆代码的调用，最终走的流程跟Activity的创建类似——走到了resumeTopActivityInnerLocked方法。这期间AMS还做了一下几件事，将B Activity的描述信息加入到mFinishingActivities中，并找去要resume的A Activity。接下来就是resumeTopActivityInnerLocked里的调用了。和B创建时不同的是，这次走的不是Launch流程了，而是resume流程：
final ClientTransaction transaction =
ClientTransaction.obtain(next.app.getThread(), next.appToken);
transaction.setLifecycleStateRequest(
ResumeActivityItem.obtain(next.app.getReportedProcState(),
getDisplay().mDisplayContent.isNextTransitionForward()));
mService.getLifecycleManager().scheduleTransaction(transaction);
这里不再描述代码调用流程了，只展示关键代码。可以看到，又是ResumeActivityItem。那么B的onResume调用逻辑就很明了，依旧是通过ResumeActivityItem的execute方法调用，最终走到Activity的performResume方法。而在上文中，我们已经分析过该方法里。它首先调用了performRestart方法，又接着调用了Instrumentation.callActivityOnResume方法，其中Instrumentation.callActivityOnResume方法就是onResume的流程。这里performRestart方法排上了用场了。由于当前A Activity被标记了stop。所以会走如下流程：
final void performRestart(boolean start, String reason) {
if (mStopped) {
//..
mInstrumentation.callActivityOnRestart(this);
writeEventLog(LOG_AM_ON_RESTART_CALLED, reason);
if (!mCalled) {
throw new SuperNotCalledException(
"Activity " + mComponent.toShortString() +
" did not call through to super.onRestart()");
}
if (start) {
performStart(reason);
}
}
}
此时，mStopped的值为true。而start传过来的也是true。不难发现，这里就是执行onRestart和onStart方法的地方了。
B Activity的onStop和onDestory
和上文中B的Resume流程一样，A在Resume之后，也会通过Looper.myQueue().addIdleHandler(new Idler());调用到ActivityStackSuperVisor的activityIdleInternalLocked方法。而此时，代码调用的逻辑就和上次不同了：
final ActivityRecord activityIdleInternalLocked(final IBinder token, boolean fromTimeout,
boolean processPausingActivities, Configuration config) {
ArrayList<ActivityRecord> finishes = null;
final ArrayList<ActivityRecord> stops = processStoppingActivitiesLocked(r,
true /* remove */, processPausingActivities);
NS = stops != null ? stops.size() : 0;
if ((NF = mFinishingActivities.size()) > 0) {
finishes = new ArrayList<>(mFinishingActivities);
mFinishingActivities.clear();
}
for (int i = 0; i < NF; i++) {
r = finishes.get(i);
final ActivityStack stack = r.getActivityStack();
if (stack != null) {
activityRemoved |= stack.destroyActivityLocked(r, true, "finish-idle");
}
}
}
由于B Activity在finish()调用时已经被添加到mFinishingActivities中了，所以。这次会走到ActivityStack的destroyActivityLocked方法。最终发现其逻辑如下：
final boolean destroyActivityLocked(ActivityRecord r, boolean removeFromApp, String reason) {
try{
mService.getLifecycleManager().scheduleTransaction(r.app.getThread(), r.appToken,
DestroyActivityItem.obtain(r.finishing, r.configChangeFlags));
}
}
出现了DestroyActivityItem。那么问题就很简单了，直接看它的execute方法：
public void execute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityDestroy");
client.handleDestroyActivity(token, mFinished, mConfigChanges,
false /* getNonConfigInstance */, "DestroyActivityItem");
Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
}
接着就是老讨论，ActivityThread中的handleDestroyActivity->performDestroyActivity:
ActivityClientRecord performDestroyActivity(IBinder token, boolean finishing,
int configChanges, boolean getNonConfigInstance, String reason) {
if (!r.stopped) {
callActivityOnStop(r, false /* saveState */, "destroy");
}
try{
mInstrumentation.callActivityOnDestroy(r.activity);
}
}
private void callActivityOnStop(ActivityClientRecord r, boolean saveState, String reason) {
try {
r.activity.performStop(r.mPreserveWindow, reason);
}
}
由于B Activity此时处于onPause状态，所以代码会先执行callActivityOnStop方法，其中的Activity.performStop会调用Instrumentation的callActivityOnStop方法。而callActivityOnStop和callActivityOnDestroy的具体实现为:
public void callActivityOnStop(Activity activity) {
activity.onStop();
}
public void callActivityOnDestroy(Activity activity) {
activity.performDestroy();
}
逻辑很清晰，接连调用了onStop和onDestroy方法（activity.performDestroy方法很简单，就不贴出来了）
总结
至此，Activity生命周期的调用逻辑已经完成。我们可以看到，其生命周期都是通过TransactionExecutor获取 ClientTransaction中的ActivityLifecycleItem和ClientTransactionItem然后执行它们的execute等方法驱动的。 。期间涉及到了AMS所在进程和App进程的通信，主要是靠AMS和ActivitThread实现的，同时也涉及到了IdleHandler等Handler的知识。
大致的调用逻辑如下：
大致步骤如下：
- AMS将BaseClientRequest的具体实现（根据不同的实现，控制Activity的生命周期流程）传递给ActivityThread；
- ActivityThread拿到BaseClientRequest的具体实现之后，切换到主线程，然后执行里面的具体实现（preExecute、execute和postExecute）；
- BaseClientRequest的不同实现调用ActivityThread不同的方法，然后ActivityThread通过Instrumentation实现对Activity生命周期的控制；
- 最后，将结果返还给AMS
其中AMS和后面三者处于不同的进程，所以通信需要借助AIDL，而ActivityThread首先会通过Handler切换线程再执行后续的操作。最终再次使用AIDL将结果返还给AMS。
如果对文中提到的各种概念不太理解。可以参考一下文章：
建议按顺序阅读
