寸_铁

这个屌丝很懒，什么也没留下！

热门标签

4【Android 12】【WCT的同步】BLASTSyncEngine

作者：寸_铁 | 2024-08-18 04:45:14

踩

blastsyncengine

在这里插入图片描述

一、BLASTSyncEngine定义

/**
 * Utility class for collecting WindowContainers that will merge transactions.
 * For example to use to synchronously resize all the children of a window container
 *   1. Open a new sync set, and pass the listener that will be invoked
 *        int id startSyncSet(TransactionReadyListener)
 *      the returned ID will be eventually passed to the TransactionReadyListener in combination
 *      with a set of WindowContainers that are ready, meaning onTransactionReady was called for
 *      those WindowContainers. You also use it to refer to the operation in future steps.
 *   2. Ask each child to participate:
 *       addToSyncSet(int id, WindowContainer wc)
 *      if the child thinks it will be affected by a configuration change (a.k.a. has a visible
 *      window in its sub hierarchy, then we wi`ll increment a counter of expected callbacks
 *      At this point the containers hierarchy will redirect pendingTransaction and sub hierarchy
 *      updates in to the sync engine.
 *   3. Apply your configuration changes to the window containers.
 *   4. Tell the engine that the sync set is ready
 *       setReady(int id)
 *   5. If there were no sub windows anywhere in the hierarchy to wait on, then
 *      transactionReady is immediately invoked, otherwise all the windows are poked
 *      to redraw and to deliver a buffer to {@link WindowState#finishDrawing}.
 *      Once all this drawing is complete, all the transactions will be merged and delivered
 *      to TransactionReadyListener.
 *
 * This works primarily by setting-up state and then watching/waiting for the registered subtrees
 * to enter into a "finished" state (either by receiving drawn content or by disappearing). This
 * checks the subtrees during surface-placement.
 */
class BLASTSyncEngine
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

渣翻：

用于收集将merge transactions的WindowContainers 的工具类。

例如用于同步调整一个WindowContainer下的所有子WindowContainer的尺寸：

1)、打开一个新的同步集，并传递将被调用的listener：

int id startSyncSet(TransactionReadyListener) 
1

返回的ID最终会与一组准备好的WindowContainers一起传递给TransactionReadyListener，这意味那些WindowContainers已经调用了onTransactionReady。您还可以使用它来指代以后步骤中的操作。

2)、要求每个子容器参与：

 addToSyncSet(int id, WindowContainer wc)
1

如果子容器认为它会受到Configuration更改的影响（也就是在其子层次结构中有一个可见的窗口，那么我们将增加一个预期的计数器回调）。此时，容器层次结构会将 pendingTransaction 和子层次结构更新重定向到同步引擎。

3)、将configurationchanges应用到WindowContainers。

4)、告诉BLASTSyncEngine同步集已准备好：

setReady(int id)
1

5)、如果层次结构中的任何地方都没有子窗口等待，则立即调用transactionReady，否则所有窗口都将被推动去重绘和去给WindowState#finishDrawing传送缓冲区。一旦所有这些绘制完成，所有transaction将被合并并且交付给 TransactionReadyListener。

这主要通过设置状态然后观察/等待注册的子树进入“完成”状态（通过接收绘制的内容或消失）来工作。这会在surface-placement期间检查子树。

根据WindowOrganizerController的情况看下1-5条的执行情况。

二、同步流程分析

在分析WindowContainerTransaction的应用时，关于WindowContainerTransaction#applySyncTransaction方法，当时是跳过了很多内容直接去分析WindowContainerTransaction是如何应用到WindowContainer上了，那些跳过的内容也就是和同步机制相关的，这次就来跟踪下同步的流程。

    @Override
    public int applySyncTransaction(WindowContainerTransaction t,
            IWindowContainerTransactionCallback callback) {
        enforceTaskPermission("applySyncTransaction()");
        if (t == null) {
            throw new IllegalArgumentException("Null transaction passed to applySyncTransaction");
        }
        final long ident = Binder.clearCallingIdentity();
        try {
            synchronized (mGlobalLock) {
                /**
                 * If callback is non-null we are looking to synchronize this transaction by
                 * collecting all the results in to a SurfaceFlinger transaction and then delivering
                 * that to the given transaction ready callback. See {@link BLASTSyncEngine} for the
                 * details of the operation. But at a high level we create a sync operation with a
                 * given ID and an associated callback. Then we notify each WindowContainer in this
                 * WindowContainer transaction that it is participating in a sync operation with
                 * that ID. Once everything is notified we tell the BLASTSyncEngine "setSyncReady"
                 * which means that we have added everything to the set. At any point after this,
                 * all the WindowContainers will eventually finish applying their changes and notify
                 * the BLASTSyncEngine which will deliver the Transaction to the callback.
                 */
                int syncId = -1;
                if (callback != null) {
                    syncId = startSyncWithOrganizer(callback);
                }
                applyTransaction(t, syncId, null /*transition*/);
                if (syncId >= 0) {
                    setSyncReady(syncId);
                }
                return syncId;
            }
        } finally {
            Binder.restoreCallingIdentity(ident);
        }
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

1 调用BLASTSyncEngine#startSyncSet创建SyncGroup

WindowOrganizerController#applyTransaction的根据之前的分析，已经知道了，就是为WindowContainer应用WindowContainerTransaction中的设置。

在applyTransaction之前，有这样一个操作：

    @Override
    public int applySyncTransaction(WindowContainerTransaction t,
            IWindowContainerTransactionCallback callback) {
	    ......
        try {
            synchronized (mGlobalLock) {
                /**
                 * If callback is non-null we are looking to synchronize this transaction by
                 * collecting all the results in to a SurfaceFlinger transaction and then delivering
                 * that to the given transaction ready callback. See {@link BLASTSyncEngine} for the
                 * details of the operation. But at a high level we create a sync operation with a
                 * given ID and an associated callback. Then we notify each WindowContainer in this
                 * WindowContainer transaction that it is participating in a sync operation with
                 * that ID. Once everything is notified we tell the BLASTSyncEngine "setSyncReady"
                 * which means that we have added everything to the set. At any point after this,
                 * all the WindowContainers will eventually finish applying their changes and notify
                 * the BLASTSyncEngine which will deliver the Transaction to the callback.
                 */
                int syncId = -1;
                if (callback != null) {
                    syncId = startSyncWithOrganizer(callback);
                }
                applyTransaction(t, syncId, null /*transition*/);
			   ......
            }
        } finally {
            Binder.restoreCallingIdentity(ident);
        }
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

这里，如果是通过WindowOrganizer#applyTransaction，那么这里传入callback的就是null。

如果是WindowOrganizer#applySyncTransaction，就会传入一个callback，之前分析WCT的发送的时候，知道这里的callback是一个SyncCallback类型的回调。接下来看下callback不为空的情况。

    @VisibleForTesting
    int startSyncWithOrganizer(IWindowContainerTransactionCallback callback) {
        int id = mService.mWindowManager.mSyncEngine.startSyncSet(this);
        mTransactionCallbacksByPendingSyncId.put(id, callback);
        return id;
    }
1
2
3
4
5
6

这里调用了BLASTSyncEngine#startSyncSet，BLASTSyncEngine#startSyncSet返回了一个唯一的ID，接着把这个ID和callback存储到HashMp类型的mTransactionCallbacksByPendingSyncId中去，那么可以知道ID和callback应该是一一对应的关系。后续当WM端的transaction完成后，在WindowOrganizerController#onTransactionReady中会根据ID再取回callback。

接着看下BLASTSyncEngine#startSyncSet都干了什么。

    int startSyncSet(TransactionReadyListener listener) {
        final int id = mNextSyncId++;
        final SyncGroup s = new SyncGroup(listener, id);
        mActiveSyncs.put(id, s);
        ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "SyncGroup %d: Started for listener: %s", id, listener);
        return id;
    }
1
2
3
4
5
6
7

1)、将mNextSyncId赋值给id，然后自增1。

private int mNextSyncId = 0;
1

这里看到，mNextSyncId是BLASTSyncEngine的成员变量，由于BLASTSyncEngine只在WMS的构造器中创建了一次，唯一实例由WMS持有，那么可以知道mNextSyncId也是全局唯一一份，每次BLASTSyncEngine#startSyncSet都会自增1，保证了ID的唯一性。

2)、以这个唯一ID和传入的WindowOrganizerController对象为基础，创建了一个SyncGroup对象。

        private SyncGroup(TransactionReadyListener listener, int id) {
            mSyncId = id;
            mListener = listener;
        }
1
2
3
4

SyncGroup是BLASTSyncEngine的内部类，创建的唯一位置便是在BLASTSyncEngine#startSyncSet。

3)、将ID和创建的SyncGroup对象加入到mActiveSyncs队列中。

private final SparseArray<SyncGroup> mActiveSyncs = new SparseArray<>();
1

mActiveSyncs是BLASTSyncEngine的成员变量。

4)、最后，将这个具有唯一性的ID返回。

那么这个ID的值是唯一的，对应了一个SyncGroup对象，也对应了一个callback。

2 调用BLASTSyncEngine#addToSyncSet将所有参与同步的WindowContainer添加到SyncGroup中

在WindowOrganizerController#startSyncWithOrganizer之后，便是调用WindowOrganizerController#applyTransaction来为WindowContainer应用WindowContainerTransaction设置的修改（即Configuration更改，层级调整之类的）：

    /**
     * @param syncId If non-null, this will be a sync-transaction.
     * @param transition A transition to collect changes into.
     */
    private void applyTransaction(@NonNull WindowContainerTransaction t, int syncId,
            @Nullable Transition transition) {
		......
        try {
			......
            Iterator<Map.Entry<IBinder, WindowContainerTransaction.Change>> entries =
                    t.getChanges().entrySet().iterator();
            while (entries.hasNext()) {
				......
                // Make sure we add to the syncSet before performing
                // operations so we don't end up splitting effects between the WM
                // pending transaction and the BLASTSync transaction.
                if (syncId >= 0) {
                    addToSyncSet(syncId, wc);
                }
                if (transition != null) transition.collect(wc);

                int containerEffect = applyWindowContainerChange(wc, entry.getValue());
			   ......
            }
			......
        } finally {
            mService.continueWindowLayout();
        }
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

然而在调用WindowOrganizerController#applyWindowContainerChange方法应用之前修改之前，还有一个重要的步骤：

                // Make sure we add to the syncSet before performing
                // operations so we don't end up splitting effects between the WM
                // pending transaction and the BLASTSync transaction.
                if (syncId >= 0) {
                    addToSyncSet(syncId, wc);
                }
1
2
3
4
5
6

这个方法目前看到有三处需要执行，一是在WindowOrganizerController#applyWindowContainerChange之前，二是在WindowOrganizerController#reparentChildrenTasksHierarchyOp之前，三是在WindowOrganizerController#sanitizeAndApplyHierarchyOp之前。

接下来分析WindowOrganzierController#addToSyncSet的内容：

    @VisibleForTesting
    void addToSyncSet(int syncId, WindowContainer wc) {
        mService.mWindowManager.mSyncEngine.addToSyncSet(syncId, wc);
    }
1
2
3
4

WindowOrganizerController#addToSyncSet调用了BLASTSyncEngine#addToSyncSet。

    void addToSyncSet(int id, WindowContainer wc) {
        mActiveSyncs.get(id).addToSync(wc);
    }
1
2
3

在第一小节中我们创建了SyncGroup对象，并且和ID是一一对应，保存在了BLASTSyncEngine的成员变量mActiveSyncs中，所以这里就可以通过ID从mActiveSyncs中拿到对应的SyncGroup。

那么这里调用的就是SyncGroup#addToSyncSet：

        private void addToSync(WindowContainer wc) {
            if (!mRootMembers.add(wc)) {
                return;
            }
            ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "SyncGroup %d: Adding to group: %s", mSyncId, wc);
            wc.setSyncGroup(this);
            wc.prepareSync();
            mWm.mWindowPlacerLocked.requestTraversal();
        }
1
2
3
4
5
6
7
8
9

接下来的内容就是，之前BLASTSyncEngine注释中所提到的，将所有参与同步的WindowContainer都加入到同步集中，参与同步的WindowContainer，也就是WindowContainerTransaction中保存的那些客户端指定的WindowContainer。

逐步分析SyncGroup#addToSync的内容。

2.1 将传入的WindowContainer加入到SyncGroup的mRootMembers队列

            if (!mRootMembers.add(wc)) {
                return;
            }
1
2
3

mRootMembers是SyncGroup的成员变量：

final ArraySet<WindowContainer> mRootMembers = new ArraySet<>();
1

这里使用ArraySet保证WindowContainer只会被添加一次，毕竟我们上面看到，入口有三处。

后续SyncGroup通过遍历mRootMembers队列来判断所有参与同步的WindowContainer是否完成同步。

2.2 WindowContainer#setSyncGroup

    void setSyncGroup(@NonNull BLASTSyncEngine.SyncGroup group) {
        ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "setSyncGroup #%d on %s", group.mSyncId, this);
        if (group != null) {
            if (mSyncGroup != null && mSyncGroup != group) {
                throw new IllegalStateException("Can't sync on 2 engines simultaneously");
            }
        }
        mSyncGroup = group;
    }
1
2
3
4
5
6
7
8
9

很简单，将WindowContainer.mSyncGroup指向当前SyncGroup。

WindowContainer的成员变量mSyncGroup的定义是：

    /**
     * If non-null, references the sync-group directly waiting on this container. Otherwise, this
     * container is only being waited-on by its parents (if in a sync-group). This has implications
     * on how this container is handled during parent changes.
     */
    BLASTSyncEngine.SyncGroup mSyncGroup = null;
1
2
3
4
5
6

如果非空，说明其SyncGroup正在等待此WindowContainer。否则，这个WindowCOntainer只会被它的父WindowContainer等待（如果在SyncGroup中）。这会影响在父WindowContainer更改期间这个WindowContainer要如何被处理。

2.3 WindowContainer#prepareSync

    /**
     * Prepares this container for participation in a sync-group. This includes preparing all its
     * children.
     *
     * @return {@code true} if something changed (eg. this wasn't already in the sync group).
     */
    boolean prepareSync() {
        if (mSyncState != SYNC_STATE_NONE) {
            // Already part of sync
            return false;
        }
        for (int i = getChildCount() - 1; i >= 0; --i) {
            final WindowContainer child = getChildAt(i);
            child.prepareSync();
        }
        mSyncState = SYNC_STATE_READY;
        return true;
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

这里新增了一个WindowContainer.mSyncState的概念：

    /** This isn't participating in a sync. */
    public static final int SYNC_STATE_NONE = 0;

    /** This is currently waiting for itself to finish drawing. */
    public static final int SYNC_STATE_WAITING_FOR_DRAW = 1;

    /** This container is ready, but it might still have unfinished children. */
    public static final int SYNC_STATE_READY = 2;

    @IntDef(prefix = { "SYNC_STATE_" }, value = {
            SYNC_STATE_NONE,
            SYNC_STATE_WAITING_FOR_DRAW,
            SYNC_STATE_READY,
    })
    @interface SyncState {}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

SYNC_STATE_NONE表示当前WindowContainer没有参与到一次同步操作中。

SYNC_STATE_WAITING_FOR_DRAW表示当前WindowContainer正在等待自身绘制完成。

SYNC_STATE_READY表示当前WindowContainer已经绘制完成，但是其子WindowContainer中可能还有没有完成同步的。

可以看到，在同步之前，需要将mSyncState置为SYNC_STATE_READY。如果mSyncState不是SYNC_STATE_NONE，表示当前WindowContainer仍然处于同步过程中。并且这里还调用了子容器的prepareSync方法，这一步将使得所有子容器的mSyncState都被置为SYNC_STATE_READY。

这里可能会比较疑惑，为什么直接就把WindowContainer的mSyncState的状态设置为SYNC_STATE_READY了，同步不是才刚开始？我们看到，除了WindowContainer有prepareSync方法之外，WindowState也重写了这个方法：

    @Override
    boolean prepareSync() {
        if (!super.prepareSync()) {
            return false;
        }
        // In the WindowContainer implementation we immediately mark ready
        // since a generic WindowContainer only needs to wait for its
        // children to finish and is immediately ready from its own
        // perspective but at the WindowState level we need to wait for ourselves
        // to draw even if the children draw first our don't need to sync, so we start
        // in WAITING state rather than READY.
        mSyncState = SYNC_STATE_WAITING_FOR_DRAW;
        requestRedrawForSync();

        mWmService.mH.removeMessages(WINDOW_STATE_BLAST_SYNC_TIMEOUT, this);
        mWmService.mH.sendNewMessageDelayed(WINDOW_STATE_BLAST_SYNC_TIMEOUT, this,
            BLAST_TIMEOUT_DURATION);
        return true;
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

这里的注释也可以解答我们刚刚的疑问：

在WindowContainer的实现中，我们直接将mSyncState置为SYNC_STATE_READY，因为对于一个通用的WindowContainer而言，它只需要等待它的子WindowContainer完成同步，如果它有子WindowContainer完成同步，那么对它自己而言它也就完成同步处于就绪状态了。

但是在WindowState这一层，每一个WindowState都需要等待自己绘制完成，即使子窗口先绘制完成。所以对于WindowState，是以SYNC_STATE_WAITING_FOR_DRAW状态开始而不是SYNC_STATE_READY状态。

3 将WindowContainerTransaction应用到WindowContainer

    @Override
    public int applySyncTransaction(WindowContainerTransaction t,
            IWindowContainerTransactionCallback callback) {
        ......
        try {
            synchronized (mGlobalLock) {
			   ......
                applyTransaction(t, syncId, null /*transition*/);
			   ......
            }
        } finally {
            Binder.restoreCallingIdentity(ident);
        }
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14

这一步的具体内容在分析WCT的应用的时候有比较系统的介绍过了。

4 BLASTSyncTransaction#setReady标记SyncGroup已经准备就绪

    @Override
    public int applySyncTransaction(WindowContainerTransaction t,
            IWindowContainerTransactionCallback callback) {
        ......
        try {
            synchronized (mGlobalLock) {
			   ......
                applyTransaction(t, syncId, null /*transition*/);
                if (syncId >= 0) {
                    setSyncReady(syncId);
                }
                return syncId;
            }
        } finally {
            Binder.restoreCallingIdentity(ident);
        }
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

这一步发生在WindowOrganizerController#applyTransaction之后，即WindowContainerTransaction中的设置都已经应用到WindowContainer上了。

    @VisibleForTesting
    void setSyncReady(int id) {
        ProtoLog.v(WM_DEBUG_WINDOW_ORGANIZER, "Set sync ready, syncId=%d", id);
        mService.mWindowManager.mSyncEngine.setReady(id);
    }

    @VisibleForTesting
    void addToSyncSet(int syncId, WindowContainer wc) {
        mService.mWindowManager.mSyncEngine.addToSyncSet(syncId, wc);
    }
1
2
3
4
5
6
7
8
9
10

WindowOrganizerController#setSyncReady调用BLASTSyncEngine#setReady。

    void setReady(int id, boolean ready) {
        mActiveSyncs.get(id).setReady(ready);
    }

    void setReady(int id) {
        setReady(id, true);
    }
1
2
3
4
5
6
7

BLASTSyncEngine#setReady调用SyncGroup#setReady。

        private void setReady(boolean ready) {
            ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "SyncGroup %d: Set ready", mSyncId);
            mReady = ready;
            if (!ready) return;
            mWm.mWindowPlacerLocked.requestTraversal();
        }
1
2
3
4
5
6

将SyncGroup的成员变量mReady置为true，表示所有WindowContainerTransaction都已经应用完成，然后请求一次界面刷新。

5 等待窗口绘制完成后调用transactionReady

每次刷新界面的时候，RootWindowContainer#performSurfacePlacementNoTrace会调用BLASTSyncEngine#onSurfacePlacement。

    void onSurfacePlacement() {
        // backwards since each state can remove itself if finished
        for (int i = mActiveSyncs.size() - 1; i >= 0; --i) {
            mActiveSyncs.valueAt(i).onSurfacePlacement();
        }
    }
1
2
3
4
5
6

这里又调用了SyncGroup#onSurfacePlacement。

        private void onSurfacePlacement() {
            if (!mReady) return;
            ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "SyncGroup %d: onSurfacePlacement checking %s",
                    mSyncId, mRootMembers);
            for (int i = mRootMembers.size() - 1; i >= 0; --i) {
                final WindowContainer wc = mRootMembers.valueAt(i);
                if (!wc.isSyncFinished()) {
                    ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "SyncGroup %d:  Unfinished container: %s",
                            mSyncId, wc);
                    return;
                }
            }
            finishNow();
        }
1
2
3
4
5
6
7
8
9
10
11
12
13
14

这里会对加入到mRootMembers的WindowContainer进行遍历，mRootMembers里的数据是之前调用addToSync的时候填充的。WindowContainer#isSyncFinished返回true表示当前WindowContainer同步完成。只有当mRootMembers中所有的WindowContainer都同步完成，本次同步才算结束，才可以调用SyncGroup#finishNow。

由于这个方法在每次界面刷新的时候都会调用，所以这里的工作就是不断检查当前SyncGroup中的所有WindowContainer是否同步完成，一旦同步完成，就去调用SyncGroup#finishNow。

这里先跳过WindowContainer#isSyncFinished，看下SyncGroup#finishNow：

        private void finishNow() {
            ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "SyncGroup %d: Finished!", mSyncId);
            SurfaceControl.Transaction merged = mWm.mTransactionFactory.get();
            if (mOrphanTransaction != null) {
                merged.merge(mOrphanTransaction);
            }
            for (WindowContainer wc : mRootMembers) {
                wc.finishSync(merged, false /* cancel */);
            }
            mListener.onTransactionReady(mSyncId, merged);
            mActiveSyncs.remove(mSyncId);
        }
1
2
3
4
5
6
7
8
9
10
11
12

SyncGroup#finishNow做了以下几件事：

5.1 取得一个存放最终结果的Transaction

            SurfaceControl.Transaction merged = mWm.mTransactionFactory.get();
            if (mOrphanTransaction != null) {
                merged.merge(mOrphanTransaction);
            }
1
2
3
4

将mOrphanTransaction合并到此Transaction中，mOrphanTransactionon从调用的地方来看，当SyncGroup中的WindowContainer的父WindowContainer发生变化时，会将该WindowContainer的mSyncTransaction合入到mOrphanTransactionon，避免该WindowContainer的mSyncTransaction保存的修改在parent更改的时候丢失。

5.2 调用WindowContainer#finishSync

    /**
     * Recursively finishes/cleans-up sync state of this subtree and collects all the sync
     * transactions into `outMergedTransaction`.
     * @param outMergedTransaction A transaction to merge all the recorded sync operations into.
     * @param cancel If true, this is being finished because it is leaving the sync group rather
     *               than due to the sync group completing.
     */
    void finishSync(Transaction outMergedTransaction, boolean cancel) {
        if (mSyncState == SYNC_STATE_NONE) return;
        ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "finishSync cancel=%b for %s", cancel, this);
        outMergedTransaction.merge(mSyncTransaction);
        for (int i = mChildren.size() - 1; i >= 0; --i) {
            mChildren.get(i).finishSync(outMergedTransaction, cancel);
        }
        mSyncState = SYNC_STATE_NONE;
        if (cancel && mSyncGroup != null) mSyncGroup.onCancelSync(this);
        mSyncGroup = null;
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

这里传入的5.1中创建的存放最终结果的outMergedTransaction。

1)、将当前WindowContainer自身的mSyncTransaction合入到outMergedTransaction。

2)、WindowContainer#finishSync递归调用所有子WindowContainer#finishSync，最终将WindowContainerTransaction带来的所有Transaction变化全部都合并到outMergedTransaction。

3)、将mSyncState重置为同步前的状态SYNC_STATE_NONE，mSyncGroup置空。

5.3 调用TransactionReadyListener#onTransactionReady

mListener.onTransactionReady(mSyncId, merged);
1

这里的TransactionReadyListener就是WindowOrganizerController，是在WindowOrganizerController调用startSyncSet创建SyncGroup的时候传入的，所以这里调用的是WindowOrganizerController#onTransactionReady：

    @Override
    public void onTransactionReady(int syncId, SurfaceControl.Transaction t) {
        ProtoLog.v(WM_DEBUG_WINDOW_ORGANIZER, "Transaction ready, syncId=%d", syncId);
        final IWindowContainerTransactionCallback callback =
                mTransactionCallbacksByPendingSyncId.get(syncId);

        try {
            callback.onTransactionReady(syncId, t);
        } catch (RemoteException e) {
            // If there's an exception when trying to send the mergedTransaction to the client, we
            // should immediately apply it here so the transactions aren't lost.
            t.apply();
        }

        mTransactionCallbacksByPendingSyncId.remove(syncId);
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

所有参与到此次同步的WindowContainer都完成同步后，会由WindowOrganizerController根据syncId从mTransactionCallbacksByPendingSyncId中找到对应的回调对象，即SyncCallback，然后调用SyncCallback#onTransactionReady，并且传入存放了最终同步结果的Transaction。

5.4 将ID从mActiveSyncs中移除。

mActiveSyncs.remove(mSyncId);
1

直到这里，本次同步操作在WM端的部分才算完成了，所有configuration更改引起的Transaction变化全部都合并到了一个Transaction中，并且传给了SystemUI，后续需要SystemUI的SyncTransactionQueue那边进行apply，之前对SyncTransactionQueue的分析中也有讲过。

5.5 WindowContainer何时被视为同步完成

上面跳过了一个重要环节，在BLASTSyncEngine#onSurfacePlacement中，会对参与本次同步的所有WindowContainer调用WindowContainer#isSyncFinished判断其是否同步完成。只有SyncGroup中的所有WindowContainer都同步完成，才会调用SyncGroup#finishNow。

当时跳过了WindowContainer#isSyncFinished的分析，这一节来详细分析一下。

    /**
     * Checks if the subtree rooted at this container is finished syncing (everything is ready or
     * not visible). NOTE, this is not const: it will cancel/prepare itself depending on its state
     * in the hierarchy.
     *
     * @return {@code true} if this subtree is finished waiting for sync participants.
     */
    boolean isSyncFinished() {
        if (!isVisibleRequested()) {
            return true;
        }
        if (mSyncState == SYNC_STATE_NONE) {
            prepareSync();
        }
        if (mSyncState == SYNC_STATE_WAITING_FOR_DRAW) {
            return false;
        }
        // READY
        // Loop from top-down.
        for (int i = mChildren.size() - 1; i >= 0; --i) {
            final WindowContainer child = mChildren.get(i);
            final boolean childFinished = child.isSyncFinished();
            if (childFinished && child.isVisibleRequested() && child.fillsParent()) {
                // Any lower children will be covered-up, so we can consider this finished.
                return true;
            }
            if (!childFinished) {
                return false;
            }
        }
        return true;
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

判断一个WindowContainer是否完成同步，不仅当前WindowContainer的mSyncState得是SYNC_STATE_READY，它的子WindowContainer也要有完成同步的。

根据之前对WindowContaIner#prepareSync的分析，非WindowState类型的容器，在同步开始的时候都已经在WindowContainer#prepareSync中设置其mSyncState为SYNC_STATE_READY了，所以这里只需要看WindowState类型的子容器有没有就绪就好了，其它类型的WIndowContainer都不需要关注。

另外WindowState类型的容器一开始在WindowState#prepareSync中将mSyncState设置为SYNC_STATE_WAITING_FOR_DRAW，那么对于WindowState来说，isSyncFinished方法能够返回true，首要条件就是，mSyncState必须在后续被设置为SYNC_STATE_READY，这一步只能在WindowContainer#onSyncFinishedDrawing：

    /**
     * Call this when this container finishes drawing content.
     *
     * @return {@code true} if consumed (this container is part of a sync group).
     */
    boolean onSyncFinishedDrawing() {
        if (mSyncState == SYNC_STATE_NONE) return false;
        mSyncState = SYNC_STATE_READY;
        mWmService.mWindowPlacerLocked.requestTraversal();
        ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "onSyncFinishedDrawing %s", this);
        return true;
    }
1
2
3
4
5
6
7
8
9
10
11
12

WindowContainer#onSyncFinishedDrawing唯一调用的地方又在WindowState#finishDrawing：

    boolean finishDrawing(SurfaceControl.Transaction postDrawTransaction) {
        if (mOrientationChangeRedrawRequestTime > 0) {
            final long duration =
                    SystemClock.elapsedRealtime() - mOrientationChangeRedrawRequestTime;
            Slog.i(TAG, "finishDrawing of orientation change: " + this + " " + duration + "ms");
            mOrientationChangeRedrawRequestTime = 0;
        } else if (mActivityRecord != null && mActivityRecord.mRelaunchStartTime != 0
                && mActivityRecord.findMainWindow() == this) {
            final long duration =
                    SystemClock.elapsedRealtime() - mActivityRecord.mRelaunchStartTime;
            Slog.i(TAG, "finishDrawing of relaunch: " + this + " " + duration + "ms");
            mActivityRecord.mRelaunchStartTime = 0;
        }

        executeDrawHandlers(postDrawTransaction);
        if (!onSyncFinishedDrawing()) {
            return mWinAnimator.finishDrawingLocked(postDrawTransaction);
        }

        if (postDrawTransaction != null) {
            mSyncTransaction.merge(postDrawTransaction);
        }

        mWinAnimator.finishDrawingLocked(null);
        // We always want to force a traversal after a finish draw for blast sync.
        return true;
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

这个方法唯一的调用栈是从APP端调过来的：

ViewRootImpl#reportedDrawFinished

-> Session#finishDrawing

	（跨进程）

	-> WMS#finishDrawingWindow

		-> WindowState#finishDrawing

			-> WindowContainer#onSyncFinishedDrawing
1
2
3
4
5
6
7
8
9

那么也就是说，只有APP端完成了界面绘制并且通知到了WM端，当前WindowState才能设置其mSyncState为SYNC_STATE_READY。

然而这个还是条件之一，判断一个WindowContainer是否完成同步，还有其他限制：

        // READY
        // Loop from top-down.
        for (int i = mChildren.size() - 1; i >= 0; --i) {
            final WindowContainer child = mChildren.get(i);
            final boolean childFinished = child.isSyncFinished();
            if (childFinished && child.isVisibleRequested() && child.fillsParent()) {
                // Any lower children will be covered-up, so we can consider this finished.
                return true;
            }
            if (!childFinished) {
                return false;
            }
        }
        return true;
1
2
3
4
5
6
7
8
9
10
11
12
13
14

1)、如果我们能先找到一个已经完成绘制的子窗口，并且该子窗口后续要显示，且能够覆盖的了它下面的所有子窗口，那么可以认为当前WindowContainer绘制完成。

2)、如果我们找不到一个满足条件1的子窗口，但是所有窗口都已经绘制完成，那么也可以认为当前WindowContainer绘制完成；

3)、如果我们在找到一个满足条件1的子窗口之前，先找到一个没有完成绘制的子窗口，那么就认为当前WindowContainer没有绘制完成。

三、总结

1 BLASTSyncEngine机制流程

1)、在WindowOrganizerController#applyTransaction之前，调用BLASTSyncEngine#startSyncSet，创建一个拥有唯一ID的SyncGroup对象：

WindowOrganizerController#startSyncWithOrganizer

-> BLASTSyncEngine#startSyncSet
1

2)、在WindowContainerTransaction中的设置应用到各个WindowContainer之前，调用BLASTSyncEngine#addToSyncSet将这些要应用WindowContainerTransaction的WindowContainer加入到SyncGroup中，并且调用WindowContainer#prepareSync为这些WindowContainer设置初始状态：

WindowOrganizerController#addToSyncSet

-> BLASTSyncEngine#addToSyncSet 

	-> SyncGroup#addToSync 

		-> WindowContainer#prepareSync
1
2
3
4
5

3)、所有参与同步的WindowContainer应用WindowContainerTransaction。

4)、所有参与同步的WindowContainer应用WindowContainerTransaction之后，通知BLASTSyncEngineSyncGroup已经准备就绪，可以开始请求绘制。

WindowOrganizerController#setSyncReady

-> BLASTSyncEngine#setReady 

	-> BLASTSyncEngine#setReady 

		-> SyncGroup#setReady
1
2
3
4
5

随后在每次界面刷新时，都会调用BLASTSyncEngine#onSurfacePlacement，不断去检查本次SyncGroup中的所有WindowContainer是否已经全部完成同步：

RootWindowContainer#performSurfacePlacementNoTrace

-> BLASTSyncEngine#onSurfacePlacement 

	-> SyncGroup#onSurfacePlacement
1
2
3

5)、一旦所有的容器都已经同步完成，那么调用WindowContainer#finishSync将所有参与同步WindowContainer的有关于Transaction改动，即WindowContainer的成员变量mSyncTransaction和SyncGroup的成员变量mOrphanTransaction，合入到一个Transaction中，再将该Transaction传给WindowOrganizerController，最终发送给客户端（这里就是SyncCallback）：

SyncGroup#onSurfacePlacement

-> SyncGroup#finishNow 

	-> WindowOrganizerController#onTransactionReady 

		（跨进程）

		-> SyncCallback#onTransactionReady
1
2
3
4
5
6
7

2 WindowContainer同步状态mSyncState

有三种状态：SYNC_STATE_NONE、SYNC_STATE_WAITING_FOR_DRAW和SYNC_STATE_READY，看下都是在什么时候设置的。

1)、同步开始，所有非WindowState类型的WindowContainer的mSyncState会被设置为SYNC_STATE_READY：

    /**
     * Prepares this container for participation in a sync-group. This includes preparing all its
     * children.
     *
     * @return {@code true} if something changed (eg. this wasn't already in the sync group).
     */
    boolean prepareSync() {
        if (mSyncState != SYNC_STATE_NONE) {
            // Already part of sync
            return false;
        }
        for (int i = getChildCount() - 1; i >= 0; --i) {
            final WindowContainer child = getChildAt(i);
            child.prepareSync();
        }
        mSyncState = SYNC_STATE_READY;
        return true;
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

WindowState类型的容器mSyncState会被设置为SYNC_STATE_WAITING_FOR_DRAW：

    @Override
    boolean prepareSync() {
        if (!super.prepareSync()) {
            return false;
        }
        // In the WindowContainer implementation we immediately mark ready
        // since a generic WindowContainer only needs to wait for its
        // children to finish and is immediately ready from its own
        // perspective but at the WindowState level we need to wait for ourselves
        // to draw even if the children draw first our don't need to sync, so we start
        // in WAITING state rather than READY.
        mSyncState = SYNC_STATE_WAITING_FOR_DRAW;
        requestRedrawForSync();

        mWmService.mH.removeMessages(WINDOW_STATE_BLAST_SYNC_TIMEOUT, this);
        mWmService.mH.sendNewMessageDelayed(WINDOW_STATE_BLAST_SYNC_TIMEOUT, this,
            BLAST_TIMEOUT_DURATION);
        return true;
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

2)、窗口绘制完成，对于WindowState，mSyncState被设置为SYNC_STATE_READY：

    /**
     * Call this when this container finishes drawing content.
     *
     * @return {@code true} if consumed (this container is part of a sync group).
     */
    boolean onSyncFinishedDrawing() {
        if (mSyncState == SYNC_STATE_NONE) return false;
        mSyncState = SYNC_STATE_READY;
        mWmService.mWindowPlacerLocked.requestTraversal();
        ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "onSyncFinishedDrawing %s", this);
        return true;
    }
1
2
3
4
5
6
7
8
9
10
11
12

3)、同步结束，所有WindowContainer的mSyncState被重置为SYNC_STATE_NONE：

    /**
     * Recursively finishes/cleans-up sync state of this subtree and collects all the sync
     * transactions into `outMergedTransaction`.
     * @param outMergedTransaction A transaction to merge all the recorded sync operations into.
     * @param cancel If true, this is being finished because it is leaving the sync group rather
     *               than due to the sync group completing.
     */
    void finishSync(Transaction outMergedTransaction, boolean cancel) {
        if (mSyncState == SYNC_STATE_NONE) return;
        ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "finishSync cancel=%b for %s", cancel, this);
        outMergedTransaction.merge(mSyncTransaction);
        for (int i = mChildren.size() - 1; i >= 0; --i) {
            mChildren.get(i).finishSync(outMergedTransaction, cancel);
        }
        mSyncState = SYNC_STATE_NONE;
        if (cancel && mSyncGroup != null) mSyncGroup.onCancelSync(this);
        mSyncGroup = null;
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

3 同步完成的本质

要看一个WindowContainer（一般是Task）是否同步完成，其实是看它包含的ActivityRecord对应的窗口是否绘制完成：

ViewRootImpl#reportedDrawFinished

-> Session#finishDrawing

	（跨进程）

	-> WMS#finishDrawingWindow

		-> WindowState#finishDrawing

			-> WindowContainer#onSyncFinishedDrawing
1
2
3
4
5
6
7
8
9

这个依赖于APP端界面的绘制情况。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/寸_铁/article/detail/995994