Android10?客戶端事務(wù)管理ClientLifecycleManager源碼解析
正文
在Android 10 App啟動(dòng)分析之Activity啟動(dòng)篇(二)一文中,簡(jiǎn)單地介紹了Activity的生命周期管理器是如何調(diào)度Activity進(jìn)入onCreate生命周期的流程。這篇文章,我們將詳細(xì)地分析framework中activity的生命周期管理功能,從更宏觀的角度來(lái)更全面地了解生命周期及相關(guān)事務(wù)的工作原理。
生命周期管理是google在Android 9才引入的設(shè)計(jì),在Android 9之前,activity 存在生命周期的概念,但并無(wú)生命周期管理這一說(shuō)法。為了方便生命周期的切換以及相關(guān)業(yè)務(wù)的管理,google采用了事務(wù)的思想,將生命周期抽象為客戶端事務(wù)的一部分來(lái)統(tǒng)一管理。下圖是客戶端事務(wù)管理完整的UML圖:

相關(guān)類說(shuō)明:
- ClientLifecycleManager: 客戶端事務(wù)管理類,包括且不限于處理Activity生命周期轉(zhuǎn)換事務(wù),同時(shí)也包括 與客戶端相關(guān)的其他事務(wù)處理。
- ClientTransaction:事務(wù)集類,一個(gè)事務(wù)集可以存放一系列Callback事務(wù)及一個(gè)生命周期事務(wù)。
- TransactionExecutor:事務(wù)執(zhí)行器,讓事務(wù)以正確的順序執(zhí)行。
- BaseClientRequest :事務(wù)的抽象類,定義了
preExecute、execute、postExecute三個(gè)接口,分別代表事務(wù)執(zhí)行前、執(zhí)行中、執(zhí)行后三個(gè)階段的回調(diào)方法。 - ActivityLifecycleItem:abstract class,Activity生命周期事務(wù)類,其子類有
DestroyActivityItem、PauseActivityItem、StopActivityItem、ResumeActivityItem,表示具體的activity生命周期轉(zhuǎn)換事務(wù)。 - ClientTransactionItem:abstract class,客戶端事務(wù)類,
ActivityLifecycleItem是它的子類之一。除此之外,還有如下內(nèi)置的客戶端事務(wù):
| Transaction Name | Desc |
|---|---|
| ConfigurationChangeItem | App configuration 改變的消息 |
| WindowVisibilityItem | Window可見(jiàn)性發(fā)生改變的消息 |
| MoveToDisplayItem | Activity 移動(dòng)到不同的顯示設(shè)備的消息 |
| MultiWindowModeChangeItem | 多窗口模式改變的消息 |
| ActivityConfigurationChangeItem | Activity configuration 改變的回調(diào) |
| PipModeChangeItem | 畫中畫模式改變的消息 |
| ActivityResultItem | Activity result的回調(diào) |
| NewIntentItem | New intent消息 |
| TopResumedActivityChangeItem | Top resumed activity 改變的回調(diào) |
| ActivityRelaunchItem | 重啟Activity的回調(diào) |
| LaunchActivityItem | 請(qǐng)求啟動(dòng)一個(gè)Activity |
ClientLifecycleManager
ClientLifecycleManager在ActivityTaskManagerService中初始化了唯一的實(shí)例,所有的事務(wù)操作,必須通過(guò)ATMS中的實(shí)例來(lái)發(fā)起。如: mService.getLifecycleManager().scheduleTransaction(clientTransaction);。
ClientLifecycleManager的源碼如下:
class ClientLifecycleManager {
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();
}
}
void scheduleTransaction(@NonNull IApplicationThread client, @NonNull IBinder activityToken,
@NonNull ActivityLifecycleItem stateRequest) throws RemoteException {
final ClientTransaction clientTransaction = transactionWithState(client, activityToken,
stateRequest);
scheduleTransaction(clientTransaction);
}
void scheduleTransaction(@NonNull IApplicationThread client, @NonNull IBinder activityToken,
@NonNull ClientTransactionItem callback) throws RemoteException {
final ClientTransaction clientTransaction = transactionWithCallback(client, activityToken,
callback);
scheduleTransaction(clientTransaction);
}
void scheduleTransaction(@NonNull IApplicationThread client,
@NonNull ClientTransactionItem callback) throws RemoteException {
final ClientTransaction clientTransaction = transactionWithCallback(client,
null /* activityToken */, callback);
scheduleTransaction(clientTransaction);
}
private static ClientTransaction transactionWithState(@NonNull IApplicationThread client,
@NonNull IBinder activityToken, @NonNull ActivityLifecycleItem stateRequest) {
final ClientTransaction clientTransaction = ClientTransaction.obtain(client, activityToken);
clientTransaction.setLifecycleStateRequest(stateRequest);
return clientTransaction;
}
private static ClientTransaction transactionWithCallback(@NonNull IApplicationThread client,
IBinder activityToken, @NonNull ClientTransactionItem callback) {
final ClientTransaction clientTransaction = ClientTransaction.obtain(client, activityToken);
clientTransaction.addCallback(callback);
return clientTransaction;
}
}
可以看到,ClientLifecycleManager對(duì)外暴露了三種事務(wù)調(diào)度方法:一是 直接調(diào)度一個(gè)事務(wù)集(ClientTransaction);二是調(diào)度一個(gè) Lifecycle事務(wù); 三是調(diào)用一個(gè)Callback事務(wù)(ps:除LifeCycle以外的事務(wù),都屬于Callback事務(wù))。實(shí)際上,無(wú)論是Lifecycle事務(wù)還是Callback事務(wù),它們都被封裝成了事務(wù)集的形式,并通過(guò)ClientTransaction中的schedule方法去進(jìn)一步處理。
ClientTransaction
ClientTransaction里的schedule方法非常簡(jiǎn)單,代碼如下所示:
public void schedule() throws RemoteException {
mClient.scheduleTransaction(this);
}
上述代碼片段中的mClient到底指的是什么?
從源碼的角度來(lái)看,mClient 是 ApplicationThread的一個(gè)實(shí)例。而 ApplicationThread 是ActivityThread的一個(gè)內(nèi)部類,作為ActivityThread 與外部溝通的橋梁。所有的事務(wù)集最終都會(huì)被派發(fā)到ActivityThread中統(tǒng)一處理。
ActivityThread.java
void scheduleTransaction(ClientTransaction transaction) {
transaction.preExecute(this);
sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction);
}
ActivityThread里首先調(diào)用了ClientTransaction中的preExecute方法,代碼片段如下:
public void preExecute(android.app.ClientTransactionHandler clientTransactionHandler) {
if (mActivityCallbacks != null) {
final int size = mActivityCallbacks.size();
for (int i = 0; i < size; ++i) {
mActivityCallbacks.get(i).preExecute(clientTransactionHandler, mActivityToken);
}
}
if (mLifecycleStateRequest != null) {
mLifecycleStateRequest.preExecute(clientTransactionHandler, mActivityToken);
}
}
可以看到,ClientTransaction先調(diào)用了 所有注冊(cè)的Callback事務(wù)的preExecute方法,然后調(diào)用了唯一的LifeCycle事務(wù)的preExecute方法。
在完成所有事務(wù)的preExecute邏輯后,ActivityThread發(fā)送了一條ActivityThread.H.EXECUTE_TRANSACTION的message,內(nèi)容如下:
mTransactionExecutor.execute(transaction);
if (isSystem()) {
transaction.recycle();
}
接下來(lái)由TransactionExecutor負(fù)責(zé)后續(xù)的邏輯處理。
TransactionExecutor
public void execute(ClientTransaction transaction) {
final IBinder token = transaction.getActivityToken();
if (token != null) {
final Map<IBinder, ClientTransactionItem> activitiesToBeDestroyed =
mTransactionHandler.getActivitiesToBeDestroyed();
final ClientTransactionItem destroyItem = activitiesToBeDestroyed.get(token);
if (destroyItem != null) {
if (transaction.getLifecycleStateRequest() == destroyItem) {
// It is going to execute the transaction that will destroy activity with the
// token, so the corresponding to-be-destroyed record can be removed.
activitiesToBeDestroyed.remove(token);
}
if (mTransactionHandler.getActivityClient(token) == null) {
// The activity has not been created but has been requested to destroy, so all
// transactions for the token are just like being cancelled.
Slog.w(TAG, tId(transaction) + "Skip pre-destroyed transaction:\n"
+ transactionToString(transaction, mTransactionHandler));
return;
}
}
}
executeCallbacks(transaction);
executeLifecycleState(transaction);
mPendingActions.clear();
}
execute中有一段對(duì)DestroyActivityItem特殊處理的邏輯,不太重要,我們忽略它。
我們分別來(lái)看一下executeCallbacks和executeLifecycleState兩個(gè)方法。
public void executeCallbacks(ClientTransaction transaction) {
final List<ClientTransactionItem> callbacks = transaction.getCallbacks();
if (callbacks == null || callbacks.isEmpty()) {
return;
}
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);
if (DEBUG_RESOLVER) Slog.d(TAG, tId(transaction) + "Resolving callback: " + item);
final int postExecutionState = item.getPostExecutionState();
final int closestPreExecutionState = mHelper.getClosestPreExecutionState(r,
item.getPostExecutionState());
if (closestPreExecutionState != UNDEFINED) {
cycleToPath(r, closestPreExecutionState, transaction);
}
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, transaction);
}
}
}
上述代碼主要做了以下幾件事:
- 獲取事務(wù)集的target lifecycle。
- 獲取事務(wù)集中最后一次Activity生命周期轉(zhuǎn)換的Callback索引。
- 遍歷所有的Callback事務(wù)。
- 獲取Callback事務(wù)的結(jié)束狀態(tài)值,如結(jié)束狀態(tài)值為onResume,檢查Activity當(dāng)前狀態(tài),判斷當(dāng)前的就近狀態(tài)(onStart/onPause),并將activity轉(zhuǎn)換到就近狀態(tài)。
- 執(zhí)行Callback事務(wù)的execute和postExecute邏輯。
- 跳過(guò)最后一個(gè)狀態(tài)轉(zhuǎn)換,改為通過(guò)顯式狀態(tài)變換去執(zhí)行。
google這段邏輯寫的極為繁雜啰嗦,讓人吐槽的點(diǎn)實(shí)在太多了,但還是要在此講一下它是怎么設(shè)計(jì)的,源碼中又哪里糟點(diǎn)。
首先是事務(wù)集的target lifecycle,它指的是事務(wù)集中唯一的Lifecycle事務(wù)(如果存在的話)的狀態(tài),表示事務(wù)集執(zhí)行完畢后,Activity最終的生命周期狀態(tài)。
第二點(diǎn),事務(wù)集中最后一次Activity生命周期轉(zhuǎn)換的Callback索引,這句話是什么含義呢?
Callback事務(wù)中有這么一個(gè)方法,getPostExecutionState,它表示在當(dāng)前Callback事務(wù)執(zhí)行完畢后Activity所需處于的生命周期狀態(tài),為方便敘述,下文稱其為結(jié)束狀態(tài)。將Callback事務(wù)列表從后向前遍歷,如果當(dāng)前事務(wù)存在結(jié)束狀態(tài)(即getPostExecutionState的值不為UNDEFINED),且與上一個(gè)結(jié)束狀態(tài)相同,記錄下此時(shí)事務(wù)在列表中的索引值,直到當(dāng)前結(jié)束狀態(tài)與上一個(gè)狀態(tài)不同為止。此時(shí),上一個(gè)事務(wù)的索引值即為事務(wù)集中最后一次Activity生命周期轉(zhuǎn)換的Callback索引。
假如某事務(wù)集有這樣一組Callback事務(wù)——ConfigurationChangeItem、NewIntentItem、ConfigurationChangeItem、NewIntentItem。其中ConfigurationChangeItem的結(jié)束狀態(tài)為UNDEFINED,NewIntentItem的結(jié)束狀態(tài)為ON_RESUME。
我們從后向前開(kāi)始遍歷:
- 最后一個(gè)事務(wù)為 NewIntentItem,結(jié)束狀態(tài)為ON_RESUME,記錄下此時(shí)的索引值 3。
- 倒數(shù)第二個(gè)事務(wù)為 ConfigurationChangeItem,不存在結(jié)束狀態(tài),跳過(guò)。
- 倒數(shù)第三個(gè)事務(wù)為 NewIntentItem,結(jié)束狀態(tài)為ON_RESUME,上一個(gè)結(jié)束狀態(tài)同樣也是 ON_RESUME,更新索引值 為 1。
- 倒數(shù)第四個(gè)事務(wù)為 ConfigurationChangeItem,不存在結(jié)束狀態(tài),跳過(guò)。
因此,此事務(wù)集中最后一次Activity生命周期轉(zhuǎn)換的Callback索引 為1。至于這個(gè)索引值有什么意義呢,待會(huì)再解釋。
然而,這段設(shè)計(jì)中還是有幾點(diǎn)需要吐槽一下:
- google官方在注釋中舉例的 事務(wù)是 Configuration - ActivityResult - Configuration - ActivityResult , 并且說(shuō)明ActivityResult 的結(jié)束狀態(tài)為RESUMED。讓我們看看ActivityResultItem的源碼:
public class ActivityResultItem extends ClientTransactionItem {
@UnsupportedAppUsage
private List<ResultInfo> mResultInfoList;
/* TODO(b/78294732)
@Override
public int getPostExecutionState() {
return ON_RESUME;
}*/
}
Excuse me? TODO state!! 實(shí)際上,這個(gè)TODO 一直拖到android 13 才被加上,en~~~~。
- 設(shè)計(jì)歸設(shè)計(jì),到android13 為止,framework里從來(lái)沒(méi)有過(guò)一個(gè)事務(wù)集里綁定多個(gè)Callback事務(wù)的用法,所以 這段邏輯設(shè)計(jì)的并沒(méi)有什么用。
第四點(diǎn),如果Callback事務(wù)的結(jié)束狀態(tài)為ON_RESUME,則判斷當(dāng)前Activity狀態(tài)是更靠近ON_START狀態(tài)還是ON_PAUSE狀態(tài),并將activity狀態(tài)轉(zhuǎn)換到就近狀態(tài)(ON_START or ON_PAUSE)。
這里判斷當(dāng)前Activity狀態(tài)更靠近ON_START還是ON_PAUSE,采用的是路徑長(zhǎng)度比較法。framework中為Activity定義了九種狀態(tài),具體如下:
public static final int UNDEFINED = -1;
public static final int PRE_ON_CREATE = 0;
public static final int ON_CREATE = 1;
public static final int ON_START = 2;
public static final int ON_RESUME = 3;
public static final int ON_PAUSE = 4;
public static final int ON_STOP = 5;
public static final int ON_DESTROY = 6;
狀態(tài)之間的轉(zhuǎn)換路徑如下表所示:

上表中置灰的單元格,表示不存在或禁止的狀態(tài)轉(zhuǎn)換,而單元格中A ~ B 這種寫法 表示 從 A到 B狀態(tài)之間的中間所有狀態(tài),如: start 狀態(tài)為 PRE_CREATE , finish 狀態(tài)為 DESTROY ,在上表中狀態(tài)轉(zhuǎn)換路徑為 create ~ destroy,表示 activity從 PRE_CREATE 狀態(tài)轉(zhuǎn)換到 DESTROY 狀態(tài),需要經(jīng)歷 create、start 、 resume 、pause 、stop 、 detroy ,即create到destroy之間所有的生命周期變換的過(guò)程。同時(shí),我們也稱 create~destroy 是 PRE_CREATE到DESTROY狀態(tài)路徑,它的路徑長(zhǎng)度為6。
如何判斷當(dāng)前生命周期是更靠近ON_START還是ON_PAUSE?我們舉個(gè)例子來(lái)看一下,假如當(dāng)前的生命周期為ON_STOP,由上述狀態(tài)路徑表可知,從ON_STOP狀態(tài)轉(zhuǎn)換到ON_START狀態(tài)的路徑為restart、start,長(zhǎng)度為2;而由ON_STOP狀態(tài)轉(zhuǎn)換到ON_PAUSE狀態(tài)的路徑為restart、start~pause,長(zhǎng)度為4。因此,當(dāng)前activity的狀態(tài)更靠近ON_START。
在路徑長(zhǎng)度算法的代碼里,google給凡是路徑中含有destroy狀態(tài)的長(zhǎng)度,賦予了一段懲罰長(zhǎng)度,讓它的長(zhǎng)度增加了10,具體代碼如下:
public int getClosestOfStates(ActivityClientRecord r, int[] finalStates) {
if (finalStates == null || finalStates.length == 0) {
return UNDEFINED;
}
final int currentState = r.getLifecycleState();
int closestState = UNDEFINED;
for (int i = 0, shortestPath = Integer.MAX_VALUE, pathLength; i < finalStates.length; i++) {
getLifecyclePath(currentState, finalStates[i], false /* excludeLastState */);
pathLength = mLifecycleSequence.size();
if (pathInvolvesDestruction(mLifecycleSequence)) {
//路徑中含有destroy狀態(tài),增加懲罰長(zhǎng)度
pathLength += DESTRUCTION_PENALTY;
}
if (shortestPath > pathLength) {
shortestPath = pathLength;
closestState = finalStates[i];
}
}
return closestState;
}
然而我們可以看一下表格中finish state為 START 和 PAUSE的兩列,所有的路徑中都不包含 destroy 狀態(tài),所以這個(gè)懲罰長(zhǎng)度的意義何在?
第五步開(kāi)始,正式執(zhí)行 事務(wù)的execute和postExecute邏輯。這里要談一下,為什么執(zhí)行結(jié)束狀態(tài)為 ON_RESUME的事務(wù)時(shí),先要在第四步將 狀態(tài)切換到 ON_START 或 ON_RESUME后,然后才開(kāi)始去執(zhí)行事務(wù)的邏輯呢?
在Android 10中,結(jié)束狀態(tài)為 ON_RESUME 的事務(wù)只有 NewIntentItem,其 excute 方法代碼片段如下:
NewIntentItem.java
public void execute(ClientTransactionHandler client, ActivityClientRecord r,
PendingTransactionActions pendingActions) {
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityNewIntent");
client.handleNewIntent(r, mIntents);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
}
它最終會(huì)調(diào)用到 activity的performNewIntent方法。
可以看到在這個(gè)過(guò)程中并沒(méi)有涉及到生命周期狀態(tài)的轉(zhuǎn)換。因此,google這段邏輯的意圖是:在執(zhí)行最終狀態(tài)為ON_RESUME的事務(wù)時(shí),先將activity生命周期狀態(tài)轉(zhuǎn)換到ON_RESUME的臨近狀態(tài),即ON_START或ON_PAUSE狀態(tài),然后再去執(zhí)行事務(wù),最后在事務(wù)執(zhí)行完畢后,將activity的狀態(tài)真正地切換到ON_RESUME。
第六步,跳過(guò)最后一個(gè)狀態(tài)轉(zhuǎn)換,改為通過(guò)顯式狀態(tài)變換去執(zhí)行。
這里做了一個(gè)判斷,如果事務(wù)組最后一次最終狀態(tài)與事務(wù)集的生命周期狀態(tài)相同,跳過(guò)此事務(wù)的最終狀態(tài)的轉(zhuǎn)換,改由 LifeCycle事務(wù)去執(zhí)行狀態(tài)轉(zhuǎn)換。
然而,我們來(lái)看這樣一組事務(wù),ConfigurationChangeItem、NewIntentItem、ConfigurationChangeItem、NewIntentItem,雖然實(shí)際編碼中并不會(huì)寫出這樣一組事務(wù),但仍可以用來(lái)吐槽一下google的這段代碼邏輯:
由第二步可知,上述的的事務(wù)組最后一次activity狀態(tài)轉(zhuǎn)換的Callback索引為 1。
final boolean shouldExcludeLastTransition =
i == lastCallbackRequestingState && finalState == postExecutionState;
cycleToPath(r, postExecutionState, shouldExcludeLastTransition, transaction);
可以看到,在第二個(gè)事務(wù),activity并不會(huì)切換到ON_RESUME狀態(tài)。
然而這段代碼最大的問(wèn)題是,這個(gè)判斷并不能達(dá)成顯式狀態(tài)變換的目標(biāo),因?yàn)樵诘谒膫€(gè)事務(wù)時(shí) activity會(huì)被切換到ON_REUSME的目標(biāo)狀態(tài)。
有讀者可能會(huì)提出異議了,作者你舉的這個(gè)例子是屬于特例,代碼中不可能這么寫。 然而,如果不需要考慮這種特殊情況的話,第二步的索引值計(jì)算又有什么作用呢?
executeLifecycleState
這個(gè)方法是對(duì)事務(wù)集中的LifeCycle事務(wù)的處理,其代碼具體如下:
private void executeLifecycleState(ClientTransaction transaction) {
...
// Cycle to the state right before the final requested state.
cycleToPath(r, lifecycleItem.getTargetState(), true /* excludeLastState */, transaction);
// Execute the final transition with proper parameters.
lifecycleItem.execute(mTransactionHandler, token, mPendingActions);
lifecycleItem.postExecute(mTransactionHandler, token, mPendingActions);
}
可以看到,cycleToPath是將activity切換到目標(biāo)生命周期狀態(tài)的關(guān)鍵方法:
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);
}
getLifecyclePath是獲取狀態(tài)路徑的方法,關(guān)于狀態(tài)路徑在上文中已經(jīng)有所介紹。
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);
switch (state) {
case ON_CREATE:
mTransactionHandler.handleLaunchActivity(r, mPendingActions,
null /* customIntent */);
break;
case ON_START:
mTransactionHandler.handleStartActivity(r, mPendingActions,
null /* activityOptions */);
break;
case ON_RESUME:
mTransactionHandler.handleResumeActivity(r, false /* finalStateRequest */,
r.isForward, "LIFECYCLER_RESUME_ACTIVITY");
break;
case ON_PAUSE:
mTransactionHandler.handlePauseActivity(r, false /* finished */,
false /* userLeaving */, 0 /* configChanges */, mPendingActions,
"LIFECYCLER_PAUSE_ACTIVITY");
break;
case ON_STOP:
mTransactionHandler.handleStopActivity(r, 0 /* configChanges */,
mPendingActions, false /* finalStateRequest */,
"LIFECYCLER_STOP_ACTIVITY");
break;
case ON_DESTROY:
mTransactionHandler.handleDestroyActivity(r, false /* finishing */,
0 /* configChanges */, false /* getNonConfigInstance */,
"performLifecycleSequence. cycling to:" + path.get(size - 1));
break;
case ON_RESTART:
mTransactionHandler.performRestartActivity(r, false /* start */);
break;
default:
throw new IllegalArgumentException("Unexpected lifecycle state: " + state);
}
}
}
}
獲取到狀態(tài)路徑后,開(kāi)始遍歷路徑,按順序依次切換路徑中的activity生命周期狀態(tài),直到到達(dá)目標(biāo)狀態(tài)為止。
在達(dá)到目標(biāo)路徑后,會(huì)調(diào)用Lifecycle事務(wù)的excute方法。這里會(huì)再一次調(diào)用切換到目標(biāo)狀態(tài)的邏輯,不過(guò)實(shí)際狀態(tài)切換時(shí),源碼里做了狀態(tài)判重的操作,并不會(huì)造成任何不良的影響。
以上就是Android10 客戶端事務(wù)管理ClientLifecycleManager源碼解析的詳細(xì)內(nèi)容,更多關(guān)于Android10 客戶端事務(wù)管理的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Android項(xiàng)目中引入aar包的正確方法介紹
生成aar之后下一步就是如何引用本地的aar文件,下面這篇文章主要給大家介紹了關(guān)于Android項(xiàng)目中引入aar包的相關(guān)資料,文中通過(guò)實(shí)例代碼介紹的非常詳細(xì),需要的朋友可以參考下2022-08-08
刷新Activity中的scrollview示例(局部ui刷新)
代碼很簡(jiǎn)單,但是很實(shí)用,適合在一個(gè)Activity中要刷新局部的UI,比如在掃描一維碼的時(shí)候,要把每次掃描的結(jié)果都顯示在界面上2014-01-01
TextView實(shí)現(xiàn)跑馬燈效果 就這么簡(jiǎn)單!
TextView實(shí)現(xiàn)跑馬燈效果,就這么簡(jiǎn)單輕松實(shí)現(xiàn),這篇文章介紹了TextView制作跑馬燈效果的方法,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2017-08-08
Android自定義View實(shí)現(xiàn)環(huán)形進(jìn)度條的思路與實(shí)例
最近看到豆瓣FM的音樂(lè)播放界面,有一個(gè)環(huán)形的進(jìn)度條挺不錯(cuò)的,最近有空就想著實(shí)現(xiàn)了,所以下面這篇文章主要給大家介紹了Android自定義View實(shí)現(xiàn)環(huán)形進(jìn)度條的思路與實(shí)例,需要的朋友可以參考借鑒,下面來(lái)一起看看吧。2017-04-04
Android程序開(kāi)發(fā)之防止密碼輸入錯(cuò)誤 密碼明文顯示功能
在使用App的時(shí)候,首次登錄都需要用戶輸入密碼的,有些朋友為了安全起見(jiàn)密碼設(shè)置的比較長(zhǎng),導(dǎo)致很多次密碼都輸入錯(cuò)誤,嚴(yán)重影響了用戶體驗(yàn)效果,下面通過(guò)本文給大家介紹Android程序開(kāi)發(fā)之防止密碼輸入錯(cuò)誤 密碼明文顯示功能,需要的朋友參考下2016-02-02
Android使用ItemTouchHelper實(shí)現(xiàn)側(cè)滑刪除和拖拽
這篇文章主要為大家詳細(xì)介紹了Android使用ItemTouchHelper實(shí)現(xiàn)側(cè)滑刪除和拖拽,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2018-08-08
Android Studio實(shí)現(xiàn)簡(jiǎn)易計(jì)算器
這篇文章主要為大家詳細(xì)介紹了Android Studio實(shí)現(xiàn)簡(jiǎn)易計(jì)算器,文中示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2018-07-07

