Android客戶端事務(wù)管理ClientLifecycleManager源碼分析

本篇內(nèi)容主要講解“Android客戶端事務(wù)管理ClientLifecycleManager源碼分析”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“Android客戶端事務(wù)管理ClientLifecycleManager源碼分析”吧!

正文

生命周期管理是google在Android 9才引入的設(shè)計，在Android 9之前，activity 存在生命周期的概念，但并無生命周期管理這一說法。為了方便生命周期的切換以及相關(guān)業(yè)務(wù)的管理，google采用了事務(wù)的思想，將生命周期抽象為客戶端事務(wù)的一部分來統(tǒng)一管理。下圖是客戶端事務(wù)管理完整的UML圖：

相關(guān)類說明：

• ClientLifecycleManager： 客戶端事務(wù)管理類，包括且不限于處理Activity生命周期轉(zhuǎn)換事務(wù)，同時也包括 與客戶端相關(guān)的其他事務(wù)處理。

• ClientTransaction：事務(wù)集類，一個事務(wù)集可以存放一系列Callback事務(wù)及一個生命周期事務(wù)。

• TransactionExecutor：事務(wù)執(zhí)行器，讓事務(wù)以正確的順序執(zhí)行。

• BaseClientRequest ：事務(wù)的抽象類，定義了preExecute、execute、postExecute三個接口，分別代表事務(wù)執(zhí)行前、執(zhí)行中、執(zhí)行后三個階段的回調(diào)方法。

• ActivityLifecycleItem：abstract class，Activity生命周期事務(wù)類，其子類有DestroyActivityItem、PauseActivityItem、StopActivityItem、ResumeActivityItem，表示具體的activity生命周期轉(zhuǎn)換事務(wù)。

• ClientTransactionItem：abstract class,客戶端事務(wù)類，ActivityLifecycleItem是它的子類之一。除此之外，還有如下內(nèi)置的客戶端事務(wù)：

ClientLifecycleManager

ClientLifecycleManager在ActivityTaskManagerService中初始化了唯一的實例，所有的事務(wù)操作，必須通過ATMS中的實例來發(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對外暴露了三種事務(wù)調(diào)度方法：一是 直接調(diào)度一個事務(wù)集(ClientTransaction)；二是調(diào)度一個 Lifecycle事務(wù); 三是調(diào)用一個Callback事務(wù)（ps:除LifeCycle以外的事務(wù)，都屬于Callback事務(wù)）。實際上，無論是Lifecycle事務(wù)還是Callback事務(wù)，它們都被封裝成了事務(wù)集的形式，并通過ClientTransaction中的schedule方法去進(jìn)一步處理。

ClientTransaction

ClientTransaction里的schedule方法非常簡單，代碼如下所示：

    public void schedule() throws RemoteException {
        mClient.scheduleTransaction(this);
    }

上述代碼片段中的mClient到底指的是什么？

從源碼的角度來看，mClient 是 ApplicationThread的一個實例。而 ApplicationThread 是ActivityThread的一個內(nèi)部類，作為ActivityThread 與外部溝通的橋梁。所有的事務(wù)集最終都會被派發(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)用了 所有注冊的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();
   }

接下來由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中有一段對DestroyActivityItem特殊處理的邏輯，不太重要，我們忽略它。

我們分別來看一下executeCallbacks和executeLifecycleState兩個方法。

 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邏輯。

• 跳過最后一個狀態(tài)轉(zhuǎn)換，改為通過顯式狀態(tài)變換去執(zhí)行。

google這段邏輯寫的極為繁雜啰嗦，讓人吐槽的點實在太多了，但還是要在此講一下它是怎么設(shè)計的，源碼中又哪里糟點。

首先是事務(wù)集的target lifecycle，它指的是事務(wù)集中唯一的Lifecycle事務(wù)（如果存在的話）的狀態(tài)，表示事務(wù)集執(zhí)行完畢后，Activity最終的生命周期狀態(tài)。

第二點，事務(wù)集中最后一次Activity生命周期轉(zhuǎn)換的Callback索引,這句話是什么含義呢？

Callback事務(wù)中有這么一個方法，getPostExecutionState，它表示在當(dāng)前Callback事務(wù)執(zhí)行完畢后Activity所需處于的生命周期狀態(tài)，為方便敘述，下文稱其為結(jié)束狀態(tài)。將Callback事務(wù)列表從后向前遍歷，如果當(dāng)前事務(wù)存在結(jié)束狀態(tài)（即getPostExecutionState的值不為UNDEFINED），且與上一個結(jié)束狀態(tài)相同，記錄下此時事務(wù)在列表中的索引值，直到當(dāng)前結(jié)束狀態(tài)與上一個狀態(tài)不同為止。此時，上一個事務(wù)的索引值即為事務(wù)集中最后一次Activity生命周期轉(zhuǎn)換的Callback索引。

假如某事務(wù)集有這樣一組Callback事務(wù)——ConfigurationChangeItem、NewIntentItem、ConfigurationChangeItem、NewIntentItem。其中ConfigurationChangeItem的結(jié)束狀態(tài)為UNDEFINED，NewIntentItem的結(jié)束狀態(tài)為ON_RESUME。

我們從后向前開始遍歷:

• 最后一個事務(wù)為 NewIntentItem，結(jié)束狀態(tài)為ON_RESUME，記錄下此時的索引值 3。

• 倒數(shù)第二個事務(wù)為 ConfigurationChangeItem，不存在結(jié)束狀態(tài)，跳過。

• 倒數(shù)第三個事務(wù)為 NewIntentItem，結(jié)束狀態(tài)為ON_RESUME，上一個結(jié)束狀態(tài)同樣也是 ON_RESUME，更新索引值 為 1。

• 倒數(shù)第四個事務(wù)為 ConfigurationChangeItem，不存在結(jié)束狀態(tài)，跳過。

因此，此事務(wù)集中最后一次Activity生命周期轉(zhuǎn)換的Callback索引 為1。至于這個索引值有什么意義呢，待會再解釋。

然而，這段設(shè)計中還是有幾點需要吐槽一下：

• google官方在注釋中舉例的 事務(wù)是 Configuration - ActivityResult - Configuration - ActivityResult , 并且說明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!! 實際上，這個TODO 一直拖到android 13 才被加上，en~~~~。

• 設(shè)計歸設(shè)計，到android13 為止，framework里從來沒有過一個事務(wù)集里綁定多個Callback事務(wù)的用法，所以 這段邏輯設(shè)計的并沒有什么用。

第四點，如果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，采用的是路徑長度比較法。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之間所有的生命周期變換的過程。同時，我們也稱 create~destroy 是 PRE_CREATE到DESTROY狀態(tài)路徑，它的路徑長度為6。

如何判斷當(dāng)前生命周期是更靠近ON_START還是ON_PAUSE？我們舉個例子來看一下，假如當(dāng)前的生命周期為ON_STOP，由上述狀態(tài)路徑表可知，從ON_STOP狀態(tài)轉(zhuǎn)換到ON_START狀態(tài)的路徑為restart、start，長度為2；而由ON_STOP狀態(tài)轉(zhuǎn)換到ON_PAUSE狀態(tài)的路徑為restart、start~pause，長度為4。因此，當(dāng)前activity的狀態(tài)更靠近ON_START。

在路徑長度算法的代碼里，google給凡是路徑中含有destroy狀態(tài)的長度，賦予了一段懲罰長度，讓它的長度增加了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)，增加懲罰長度
                pathLength += DESTRUCTION_PENALTY;
            }
            if (shortestPath > pathLength) {
                shortestPath = pathLength;
                closestState = finalStates[i];
            }
        }
        return closestState;
    }

然而我們可以看一下表格中finish state為 START 和 PAUSE的兩列，所有的路徑中都不包含 destroy 狀態(tài)，所以這個懲罰長度的意義何在？

第五步開始，正式執(zhí)行 事務(wù)的execute和postExecute邏輯。這里要談一下，為什么執(zhí)行結(jié)束狀態(tài)為 ON_RESUME的事務(wù)時，先要在第四步將 狀態(tài)切換到 ON_START 或 ON_RESUME后，然后才開始去執(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);
    }

它最終會調(diào)用到 activity的performNewIntent方法。

可以看到在這個過程中并沒有涉及到生命周期狀態(tài)的轉(zhuǎn)換。因此，google這段邏輯的意圖是：在執(zhí)行最終狀態(tài)為ON_RESUME的事務(wù)時，先將activity生命周期狀態(tài)轉(zhuǎn)換到ON_RESUME的臨近狀態(tài)，即ON_START或ON_PAUSE狀態(tài)，然后再去執(zhí)行事務(wù)，最后在事務(wù)執(zhí)行完畢后，將activity的狀態(tài)真正地切換到ON_RESUME。

第六步，跳過最后一個狀態(tài)轉(zhuǎn)換，改為通過顯式狀態(tài)變換去執(zhí)行。

這里做了一個判斷，如果事務(wù)組最后一次最終狀態(tài)與事務(wù)集的生命周期狀態(tài)相同，跳過此事務(wù)的最終狀態(tài)的轉(zhuǎn)換，改由 LifeCycle事務(wù)去執(zhí)行狀態(tài)轉(zhuǎn)換。

然而，我們來看這樣一組事務(wù)，ConfigurationChangeItem、NewIntentItem、ConfigurationChangeItem、NewIntentItem，雖然實際編碼中并不會寫出這樣一組事務(wù)，但仍可以用來吐槽一下google的這段代碼邏輯：

由第二步可知，上述的的事務(wù)組最后一次activity狀態(tài)轉(zhuǎn)換的Callback索引為 1。

final boolean shouldExcludeLastTransition =
                        i == lastCallbackRequestingState && finalState == postExecutionState;
cycleToPath(r, postExecutionState, shouldExcludeLastTransition, transaction);

可以看到，在第二個事務(wù)，activity并不會切換到ON_RESUME狀態(tài)。

然而這段代碼最大的問題是，這個判斷并不能達(dá)成顯式狀態(tài)變換的目標(biāo)，因為在第四個事務(wù)時 activity會被切換到ON_REUSME的目標(biāo)狀態(tài)。

有讀者可能會提出異議了，作者你舉的這個例子是屬于特例，代碼中不可能這么寫。 然而，如果不需要考慮這種特殊情況的話，第二步的索引值計算又有什么作用呢？

executeLifecycleState

這個方法是對事務(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)路徑后，開始遍歷路徑，按順序依次切換路徑中的activity生命周期狀態(tài)，直到到達(dá)目標(biāo)狀態(tài)為止。

在達(dá)到目標(biāo)路徑后，會調(diào)用Lifecycle事務(wù)的excute方法。這里會再一次調(diào)用切換到目標(biāo)狀態(tài)的邏輯，不過實際狀態(tài)切換時，源碼里做了狀態(tài)判重的操作，并不會造成任何不良的影響。

到此，相信大家對“Android客戶端事務(wù)管理ClientLifecycleManager源碼分析”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！