一、最近再做一個項目的時候去查看了一下ActivityThread的handleLaunchActivity方法：
@Override
public Activity handleLaunchActivity(ActivityClientRecord r,
PendingTransactionActions pendingActions, Intent customIntent) {
...代碼省略...
final Activity a = performLaunchActivity(r, customIntent);
if (a != null) {
r.createdConfig = new Configuration(mConfiguration);
reportSizeConfigurations(r);
if (!r.activity.mFinished && pendingActions != null) {
pendingActions.setOldState(r.state);
pendingActions.setRestoreInstanceState(true);
pendingActions.setCallOnPostCreate(true);
}
} else {
// If there was an error, for any reason, tell the activity manager to stop us.
try {
ActivityManager.getService()
.finishActivity(r.token, Activity.RESULT_CANCELED, null,
Activity.DONT_FINISH_TASK_WITH_ACTIVITY);
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
}
return a;
}
看了這段代碼，突然懵逼了：
what?！
handleResumeActivity方法呢？！
我怎么記得之前看的時候一直都有的？
后來想了一下：應該是我更新了最新的Android28的SDK的緣故。隨即翻了下Android27的源碼：：
private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent, String reason) {
...代碼省略...
Activity a = performLaunchActivity(r, customIntent);
if (a != null) {
r.createdConfig = new Configuration(mConfiguration);
reportSizeConfigurations(r);
Bundle oldState = r.state;
handleResumeActivity(r.token, false, r.isForward,
!r.activity.mFinished && !r.startsNotResumed, r.lastProcessedSeq, reason);
if (!r.activity.mFinished && r.startsNotResumed) {
// The activity manager actually wants this one to start out paused, because it
// needs to be visible but isn't in the foreground. We accomplish this by going
// through the normal startup (because activities expect to go through onResume()
// the first time they run, before their window is displayed), and then pausing it.
// However, in this case we do -not- need to do the full pause cycle (of freezing
// and such) because the activity manager assumes it can just retain the current
// state it has.
performPauseActivityIfNeeded(r, reason);
// We need to keep around the original state, in case we need to be created again.
// But we only do this for pre-Honeycomb apps, which always save their state when
// pausing, so we can not have them save their state when restarting from a paused
// state. For HC and later, we want to (and can) let the state be saved as the
// normal part of stopping the activity.
if (r.isPreHoneycomb()) {
r.state = oldState;
}
}
} else {
// If there was an error, for any reason, tell the activity manager to stop us.
try {
ActivityManager.getService()
.finishActivity(r.token, Activity.RESULT_CANCELED, null,
Activity.DONT_FINISH_TASK_WITH_ACTIVITY);
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
}
}
果然我沒記錯，看來是Android28在啟動機制上面做了比較大的改動。然后我特意去跑了下activity 啟動時的生命周期，其實并沒有發(fā)生變化。另外ActivityThread新繼承了ClientTransactionHandler，handleLaunchActivity方法從私有變成了公有，并且變成了重載方法，所以我猜想可能是新增了個管理類來控制生命周期變化了。
Activity啟動生命周期.png
二、于是乎，我重新研究一遍從Launcher開始啟動activity的源碼，開始找不同之處。我這里先貼出時序圖，然后再作分析：
Activity啟動時序圖(點擊查看大圖)
因為Android27之前在ActivityStackSupervisor類的realStartActivityLocked方法里面執(zhí)行的是ActivityThread內(nèi)部類ApplicationThread的scheduleLaunchActivity。然后執(zhí)行下面這段代碼，調(diào)用handleLaunchActivity方法
@Override
public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,
ActivityInfo info, Configuration curConfig, Configuration overrideConfig,
CompatibilityInfo compatInfo, String referrer, IVoiceInteractor voiceInteractor,
int procState, Bundle state, PersistableBundle persistentState,
List<ResultInfo> pendingResults, List<ReferrerIntent> pendingNewIntents,
boolean notResumed, boolean isForward, ProfilerInfo profilerInfo) {
...代碼省略...
//發(fā)送啟動activity的message
sendMessage(H.LAUNCH_ACTIVITY, r);
}
所以這里我們主要分析ActivityStackSupervisor之后的時序圖。這里我們截取ActivityStackSupervisor的realStartActivityLocked方法里面的主要操作
// Create activity launch transaction.
final ClientTransaction clientTransaction = ClientTransaction.obtain(app.thread,
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, app.repProcState, r.icicle,
r.persistentState, results, newIntents, mService.isNextTransitionForward(),
profilerInfo));
// Set desired final state.
final ActivityLifecycleItem lifecycleItem;
if (andResume) {
lifecycleItem = ResumeActivityItem.obtain(mService.isNextTransitionForward());
} else {
lifecycleItem = PauseActivityItem.obtain();
}
clientTransaction.setLifecycleStateRequest(lifecycleItem);
// Schedule transaction.
mService.getLifecycleManager().scheduleTransaction(clientTransaction);
根據(jù)上面的代碼及注釋我們發(fā)現(xiàn)里面包含了三步操作：
- 創(chuàng)建activity啟動的事務,并且添加到clientTransaction對象的列表當中去，這個列表之后執(zhí)行生命周期的時候會用到，需要記下。
- 設置最終期望到達的狀態(tài)(我這里主要探討的是activity啟動時的事務，所以這里期望狀態(tài)必然是resume狀態(tài))到事務當中去
- 執(zhí)行事務
mService.getLifecycleManager()獲取的是ClientLifecycleManager對象，所以接下來要調(diào)用的就是ClientLifecycleManager對象的scheduleTransaction。那么我們進入代碼看看：
// TODO(lifecycler): Implement building transactions or global transaction.
// TODO(lifecycler): Use object pools for transactions and transaction items.
/**
* Schedule a transaction, which may consist of multiple callbacks and a lifecycle request.
* @param transaction A sequence of client transaction items.
* @throws RemoteException
*
* @see ClientTransaction
*/
void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
final IApplicationThread client = transaction.getClient();
transaction.schedule();
if (!(client instanceof Binder)) {
// If client is not an instance of Binder - it's a remote call and at this point it is
// safe to recycle the object. All objects used for local calls will be recycled after
// the transaction is executed on client in ActivityThread.
transaction.recycle();
}
}
執(zhí)行的是ClientTransaction的schedule方法：
public class ClientTransaction implements Parcelable, ObjectPoolItem {
...代碼省略...
/** Target client. */
private IApplicationThread mClient;
/**
* Schedule the transaction after it was initialized. It will be send to client and all its
* individual parts will be applied in the following sequence:
* 1. The client calls {@link #preExecute(ClientTransactionHandler)}, which triggers all work
* that needs to be done before actually scheduling the transaction for callbacks and
* lifecycle state request.
* 2. The transaction message is scheduled.
* 3. The client calls {@link TransactionExecutor#execute(ClientTransaction)}, which executes
* all callbacks and necessary lifecycle transitions.
*/
public void schedule() throws RemoteException {
mClient.scheduleTransaction(this);
}
...代碼省略...
}
這里面的mClient變量就是IApplicationThread對象即ActivityThread的ApplicationThread對象，所以最終還是回到了ActivityThread上面了：
@Override
public void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
ActivityThread.this.scheduleTransaction(transaction);
}
// Schedule phase related logic and handlers.
/** Prepare and schedule transaction for execution. */
void scheduleTransaction(ClientTransaction transaction) {
transaction.preExecute(this);
sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction);
}
case EXECUTE_TRANSACTION:
final ClientTransaction transaction = (ClientTransaction) msg.obj;
mTransactionExecutor.execute(transaction);
if (isSystem()) {
// Client transactions inside system process are recycled on the client side
// instead of ClientLifecycleManager to avoid being cleared before this
// message is handled.
transaction.recycle();
}
// TODO(lifecycler): Recycle locally scheduled transactions.
break;
在ActivityThread發(fā)送執(zhí)行事務的消息，然后調(diào)用TransactionExecutor的execute方法：
/**
* Resolve transaction.
* First all callbacks will be executed in the order they appear in the list. If a callback
* requires a certain pre- or post-execution state, the client will be transitioned accordingly.
* Then the client will cycle to the final lifecycle state if provided. Otherwise, it will
* either remain in the initial state, or last state needed by a callback.
*/
public void execute(ClientTransaction transaction) {
final IBinder token = transaction.getActivityToken();
log("Start resolving transaction for client: " + mTransactionHandler + ", token: " + token);
executeCallbacks(transaction);
executeLifecycleState(transaction);
mPendingActions.clear();
log("End resolving transaction");
}
/** Cycle through all states requested by callbacks and execute them at proper times. */
@VisibleForTesting
public void executeCallbacks(ClientTransaction transaction) {
final List<ClientTransactionItem> callbacks = transaction.getCallbacks();
if (callbacks == null) {
// No callbacks to execute, return early.
return;
}
log("Resolving callbacks");
final IBinder token = transaction.getActivityToken();
ActivityClientRecord r = mTransactionHandler.getActivityClient(token);
// In case when post-execution state of the last callback matches the final state requested
// for the activity in this transaction, we won't do the last transition here and do it when
// moving to final state instead (because it may contain additional parameters from server).
final ActivityLifecycleItem finalStateRequest = transaction.getLifecycleStateRequest();
final int finalState = finalStateRequest != null ? finalStateRequest.getTargetState()
: UNDEFINED;
// Index of the last callback that requests some post-execution state.
final int lastCallbackRequestingState = lastCallbackRequestingState(transaction);
final int size = callbacks.size();
for (int i = 0; i < size; ++i) {
final ClientTransactionItem item = callbacks.get(i);
log("Resolving callback: " + item);
final int postExecutionState = item.getPostExecutionState();
final int closestPreExecutionState = mHelper.getClosestPreExecutionState(r,
item.getPostExecutionState());
if (closestPreExecutionState != UNDEFINED) {
cycleToPath(r, closestPreExecutionState);
}
item.execute(mTransactionHandler, token, mPendingActions);
item.postExecute(mTransactionHandler, token, mPendingActions);
if (r == null) {
// Launch activity request will create an activity record.
r = mTransactionHandler.getActivityClient(token);
}
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);
}
}
}
這時主要操作就在executeCallbacks方法的for循環(huán)里面了，callbacks列表中存放的就是之前在ActivityStackSupervisor里面創(chuàng)建事務是設置進去的，即LaunchActivityItem。所以這里執(zhí)行LaunchActivityItem對象的execute方法：
@Override
public void execute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
ActivityClientRecord r = new ActivityClientRecord(token, mIntent, mIdent, mInfo,
mOverrideConfig, mCompatInfo, mReferrer, mVoiceInteractor, mState, mPersistentState,
mPendingResults, mPendingNewIntents, mIsForward,
mProfilerInfo, client);
client.handleLaunchActivity(r, pendingActions, null /* customIntent */);
Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
}
最終調(diào)用了handleLaunchActivity方法，這個方法里面調(diào)用performLaunchActivity方法，最后執(zhí)行onCreate方法。
那么onStart和onResume呢？不著急，接下來看execute的executeLifecycleState方法：
/** Transition to the final state if requested by the transaction. */
private void executeLifecycleState(ClientTransaction transaction) {
final ActivityLifecycleItem lifecycleItem = transaction.getLifecycleStateRequest();
if (lifecycleItem == null) {
// No lifecycle request, return early.
return;
}
log("Resolving lifecycle state: " + lifecycleItem);
final IBinder token = transaction.getActivityToken();
final ActivityClientRecord r = mTransactionHandler.getActivityClient(token);
if (r == null) {
// Ignore requests for non-existent client records for now.
return;
}
// Cycle to the state right before the final requested state.
cycleToPath(r, lifecycleItem.getTargetState(), true /* excludeLastState */);
// Execute the final transition with proper parameters.
lifecycleItem.execute(mTransactionHandler, token, mPendingActions);
lifecycleItem.postExecute(mTransactionHandler, token, mPendingActions);
}
第一句話取出對應的lifecycleItem,那么這是哪來的呢？還記不記得之前ActivityStackSupervisor方法里面的第二步操作，就是將期望到達的狀態(tài)保存起來，這里取出的就是當時保存的狀態(tài)即ResumeActivityItem對象。看到這個名字是不是很熟悉，跟之前的LaunchActivityItem很像，所以最后執(zhí)行 lifecycleItem.execute，就是調(diào)用了onResume方法。
問題又來了，onStart方法去哪了？我之前按照這種命名方式搜了一下StartActivityItem,發(fā)現(xiàn)并沒有這個類。于是我只能將希望寄托在cycleToPath方法里面了：
/**
* Transition the client between states with an option not to perform the last hop in the
* sequence. This is used when resolving lifecycle state request, when the last transition must
* be performed with some specific parameters.
*/
private void cycleToPath(ActivityClientRecord r, int finish,
boolean excludeLastState) {
final int start = r.getLifecycleState();
log("Cycle from: " + start + " to: " + finish + " excludeLastState:" + excludeLastState);
final IntArray path = mHelper.getLifecyclePath(start, finish, excludeLastState);
performLifecycleSequence(r, path);
}
mHelper是TransactionExecutorHelper類，他的作用是將起始狀態(tài)和期望狀態(tài)中間的狀態(tài)通過一定的計算得出然后放到一個數(shù)組中返回。
performLifecycleSequence就是調(diào)用數(shù)組里面的所有生命周期狀態(tài)：
/** Transition the client through previously initialized state sequence. */
private void performLifecycleSequence(ActivityClientRecord r, IntArray path) {
final int size = path.size();
for (int i = 0, state; i < size; i++) {
state = path.get(i);
log("Transitioning to state: " + 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);
}
}
}
到此所有啟動邏輯執(zhí)行完畢，下面上一張完整的時序圖：
Activity啟動時序圖(點擊查看大圖)
總結(jié)
主要有以下幾點變化：
- 取消了ActivityThread里面編號110之前的Message即：
public static final int LAUNCH_ACTIVITY = 100;
public static final int PAUSE_ACTIVITY = 101;
public static final int PAUSE_ACTIVITY_FINISHING= 102;
public static final int STOP_ACTIVITY_SHOW = 103;
public static final int STOP_ACTIVITY_HIDE = 104;
public static final int SHOW_WINDOW = 105;
public static final int HIDE_WINDOW = 106;
public static final int RESUME_ACTIVITY = 107;
public static final int SEND_RESULT = 108;
public static final int DESTROY_ACTIVITY = 109;
新增了
public static final int EXECUTE_TRANSACTION = 159;
- ActivityThread繼承了ClientTransactionHandler，將原先放在ActivityThread里面的handleLaunchActivity、handlerStartActivity等等抽取出來，放到ClientTransactionHandler類中，作為抽象方法。
- 新增了ClientLifecycleManager、ClientTransactionHandler、ClientTransaction、TransactionExecutor、TransactionExecutorHelper、ClientTransactionItem
ClientLifecycleManager：作為ActivityStackSupervisor和ClientTransaction的橋梁
ClientTransactionHandler： 由ActivityThread實現(xiàn)。
ClientTransaction：管理ClientTransactionItem
TransactionExecutor：執(zhí)行ClientTransactionItem
TransactionExecutorHelper：協(xié)助TransactionExecutor執(zhí)行ClientTransactionItem
ClientTransactionItem：真正執(zhí)行生命周期的類，每一個生命周期對應一個Item（onStart除外，原因不詳）。
個人理解以上操作，主要是為了減輕ActivityThread的壓力，將生命周期抽成一個具體的對象，更有利于生命周期的管理。以及降低了耦合度。
