WCT系列（四）：BLASTSyncEngine

WCT系列（一）：WindowContainerTransaction类详解
WCT系列（二）：SyncTransactionQueue类详解
WCT系列（三）：WindowOrganizerController
WCT系列（四）：BLASTSyncEngine

1、什么是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 will 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.
 */

根据定义，BLASTSyncEngine有这五个功能：
1）开启一个syncset，同时传递一个listener，int id startSyncSet(TransactionReadyListener) 这里的ID将会被放在一组准备好的WindowContainer中传递给TransactionListener。而这就意味着这些WindowContainer已经调用了onTransactionReady。
2）令每一个子容器加入addToSyncSet(int id, WindowContainer wc)
如果子容器将会被参数的改变说影响（即在其层次结构中有一个可见的窗口，那么我们会增加一个回调的计数器）。同时，容器的层次结构将会把pendingTransaction和他的子层次结构更新到同步引擎中；
3）应用你对WindowContainer的参数的修改；
4）告诉BLASTSyncEngine，SyncSet已经准备好了：通过setReady(int id)；
5）如果层次结构中没有子窗口在等待，这transactionReady将会被立即调用，否则所有窗口将会被送去重新绘制，且给WindowState#finishDrawing传送缓冲区。一旦绘制完成，所有transaction将被合并并且传送给 TransactionReadyListener。

2、同步流程解析：

这里就可以回到在WindowOrganizerController那里跳过的applySyncTransaction方法中继续分析了：

public int applySyncTransaction(WindowContainerTransaction t,
        IWindowContainerTransactionCallback callback) {
    if (t == null) {
        throw new IllegalArgumentException("Null transaction passed to applySyncTransaction");
    }
    enforceTaskPermission("applySyncTransaction()");
    final CallerInfo caller = new CallerInfo();
    final long ident = Binder.clearCallingIdentity();
    try {
        synchronized (mGlobalLock) {
            if (callback == null) {
                applyTransaction(t, -1 /* syncId*/, null /*transition*/, caller);
                return -1;
            }

            /**
             * 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.
             */
            final BLASTSyncEngine.SyncGroup syncGroup = prepareSyncWithOrganizer(callback);  //（1）
            final int syncId = syncGroup.mSyncId;
            if (!mService.mWindowManager.mSyncEngine.hasActiveSync()) {//(5)
                mService.mWindowManager.mSyncEngine.startSyncSet(syncGroup);  //(6)
                applyTransaction(t, syncId, null /*transition*/, caller);   //(7)
                setSyncReady(syncId);//(8)
            } else {
                // Because the BLAST engine only supports one sync at a time, queue the
                // transaction.
                mService.mWindowManager.mSyncEngine.queueSyncSet(
                        () -> mService.mWindowManager.mSyncEngine.startSyncSet(syncGroup),
                        () -> {
                            applyTransaction(t, syncId, null /*transition*/, caller);
                            setSyncReady(syncId);
                        });
            }
            return syncId;
        }
    } finally {
        Binder.restoreCallingIdentity(ident);
    }
}

1） prepareSyncWithOrganizer：

首先看到（1）出的prepareSyncWithOrganizer方法：

private BLASTSyncEngine.SyncGroup prepareSyncWithOrganizer(
        IWindowContainerTransactionCallback callback) {
    final BLASTSyncEngine.SyncGroup s = mService.mWindowManager.mSyncEngine
            .prepareSyncSet(this, "", BLASTSyncEngine.METHOD_BLAST);
    mTransactionCallbacksByPendingSyncId.put(s.mSyncId, callback);//（2）
    return s;
}

private final HashMap<Integer, IWindowContainerTransactionCallback>
        mTransactionCallbacksByPendingSyncId = new HashMap();

SyncGroup prepareSyncSet(TransactionReadyListener listener, String name, int method) {
    return new SyncGroup(listener, mNextSyncId++, name, method);
}

private SyncGroup(TransactionReadyListener listener, int id, String name, int method) { //(3)
    mSyncId = id;
    mSyncMethod = method;
    mListener = listener;
    mOnTimeout = () -> {
        Slog.w(TAG, "Sync group " + mSyncId + " timeout");
        synchronized (mWm.mGlobalLock) {
            onTimeout();
        }
    };
    if (Trace.isTagEnabled(TRACE_TAG_WINDOW_MANAGER)) {
        mTraceName = name + "SyncGroupReady";
        Trace.asyncTraceBegin(TRACE_TAG_WINDOW_MANAGER, mTraceName, id);
    }
}

private void onTimeout() {  //(4)
//如果激活的SyncGroup中没有id为mSyncId的SyncGroup则直接返回
    if (!mActiveSyncs.contains(mSyncId)) return;
//初始化allFinished参数
    boolean allFinished = true;
//遍历mRootMembers中的WindowContainer是否已经SyncFinished
    for (int i = mRootMembers.size() - 1; i >= 0; --i) {
        final WindowContainer<?> wc = mRootMembers.valueAt(i);
        if (!wc.isSyncFinished()) {
            allFinished = false;
            Slog.i(TAG, "Unfinished container: " + wc);
        }
    }
    if (allFinished && !mReady) {
//这块应该是一个异常模块，SyncGroup都finish了但是却没设置ready
        Slog.w(TAG, "Sync group " + mSyncId + " timed-out because not ready. If you see "
                + "this, please file a bug.");
    }
    finishNow();
}

该方法中，通过BLASTSyncEngine中的prepareSyncSet方法创建了一个SyncGroup类型的对象，并将他的mSyncId和传入的callback一同放入了mTransactionCallbacksByPendingSyncId这个map中。这里再回顾下上一节WindowOrganizerController中的知识点，这个callback呢就是一个SyncCallback类型的对象，主要是要调用其中的onTransactionReady回调函数。这里将mSyncId和callback放入map中以后，在系统侧完成了transaction应用后，就可以根据这个mSyncId找到对应的onTransactionReady回调。
而SyncGroup类是BLASTSyncEngine的一个内部类，其构造函数如上(3)处的代码，需要mSyncId（int）、mSyncMethod（int）、mListener（TransactionReadyListener
）和一个超时的mOnTimeOut（Runnable）。而且每个SyncGroup的mSyncId都是唯一的，因为在构建的时候会通过自增对其进行赋值。
其中超时Runnable就是防止某个WindowContainer长时间没完成isSyncFinished操作时，直接调用finishNow。而isSyncFinished的详细操作如下：

boolean isSyncFinished() {
//查看整个容器内各个WindowContainer的isVisibleRequested()返回结果
    if (!isVisibleRequested()) {
        return true;
    }
//如果state为SYNC_STATE_NONE，则遍历整个容器内的WindowContainer并执行
//其prepareSync函数
    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;
}

上面一下子讲的有点多，这里先回到（2）这个地方。在完成了SyncGroup的创建和保存后，会继续（1）处的代码执行。接下来来到（5）处，发现这里会检查BLASTSyncEngine中的mActiveSyncs的size是否为0。如果是0就会执行到（6）（7）（8）三个地方的方法。那这里就比较容易理解了，就是mActiveSyncs同时只能有一个正在执行呗。
于是再去看看mActiveSyncs是什么：

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

这一看就明白了，就是一个稀疏数组呗。那就看看什么时候会向这个数组中添加元素呢？

void startSyncSet(SyncGroup s, long timeoutMs) {
    if (mActiveSyncs.size() != 0) {
        // We currently only support one sync at a time, so start a new SyncGroup when there is
        // another may cause issue.
        ProtoLog.w(WM_DEBUG_SYNC_ENGINE,
                "SyncGroup %d: Started when there is other active SyncGroup", s.mSyncId);
    }
    mActiveSyncs.put(s.mSyncId, s);
    ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "SyncGroup %d: Started for listener: %s",
            s.mSyncId, s.mListener);
    scheduleTimeout(s, timeoutMs);
}

你看从这里就能看到We currently only support one sync at a time.这不就是证明了（5）处的理解是对的了嘛。 然后这个方法中会向mActiveSyncs中添加元素，而其元素为SyncGroup对象的mSyncId和SyncGroup对象本身组成的键值对。
而调用startSyncSet的地方就是（6）处。所以在当前mActiveSyncs为空时，就会向其中添加我们刚刚构建的一个SyncGroup对象。然后在（8）处，我们会调用setSyncReady方法，并将前面构建的SyncGroup对象的mSyncId传进去。
当然（5）处检查mActiveSyncs是否为空时，也可能会出现当前不为空的状态。那么这时候就会进入else语句，然后调用BLASTSyncEngine的queueSyncSet方法：

void queueSyncSet(@NonNull Runnable startSync, @NonNull Runnable applySync) {
    final PendingSyncSet pt = new PendingSyncSet();
    pt.mStartSync = startSync;
    pt.mApplySync = applySync;
    mPendingSyncSets.add(pt);
}

而该方法这是将startSyncSet和applySyncTransaction两个操作分别封装为两个Runnable对象，然后放入mPendingSyncSets（ArrayList类型）之中暂存起来。其会在finishNow方法中被执行。

2） addToSyncSet

在执行applyTransaction的过程中，当syncId（还是刚刚构建的SyncGroup对象的mSyncId）大于0时，会调用一个函数，addToSyncSet。那这里继续查看其具体实现：

void addToSyncSet(int syncId, WindowContainer wc) {
    mService.mWindowManager.mSyncEngine.addToSyncSet(syncId, wc);
}

BLASTSyncEngine.java
void addToSyncSet(int id, WindowContainer wc) {
    getSyncGroup(id).addToSync(wc);
}

private SyncGroup getSyncGroup(int id) {
    final SyncGroup syncGroup = mActiveSyncs.get(id);
    if (syncGroup == null) {
        throw new IllegalStateException("SyncGroup is not started yet id=" + id);
    }
    return syncGroup;
}

private void addToSync(WindowContainer wc) {
    if (!mRootMembers.add(wc)) { //（9）
        return;
    }
    ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "SyncGroup %d: Adding to group: %s", mSyncId, wc);
    wc.setSyncGroup(this);  //(10)
    wc.prepareSync();  //(11)
    if (mReady) {
        mWm.mWindowPlacerLocked.requestTraversal();
    }
}
final ArraySet<WindowContainer> mRootMembers = new ArraySet<>();

如上：该方法就是在mActiveSyncs中找到指定id的SyncGroup，然后向其中添加WindowContainer。而这个WindowContainer则是添加到了SyncGroup的mRootMembers（ArraySet类型）成员变量中了。并且在添加的过程中，还会将这个WindowContainer对象的SyncGroup设置为当前SyncGroup。如果已经setReady这里甚至会直接请求绘制新一帧。 前面的WindowOrganizerController章节已经讲过了，applyTransaction方法，这里就是遍历了所有参与的WindowContainer，并将其添加到了SyncGroup当中。

至于addToSyncSet方法，可不止在这一处执行，还有1、applyHierarchyOP方法中也执行了这个方法；2、reparentChildrenTaskHierarchyOp方法中；3、applyTransaction方法中。
都是将相关的WindowContainer添加到对应的SyncGroup中。而（9）处这个判断则是为了防止这三处对WindowContainer的重复添加。

a) 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) {
            // This can still happen if WMCore starts a new transition when there is ongoing
            // sync transaction from Shell. Please file a bug if it happens.
            throw new IllegalStateException("Can't sync on 2 engines simultaneously"
                    + " currentSyncId=" + mSyncGroup.mSyncId + " newSyncId=" + group.mSyncId);
        }
    }
    mSyncGroup = group;
}

在这里可以看到，就是简单将当前的WindowContainer的mSyncGroup指向我们指定的SyncGroup对象。但是如果当前WindowContainer对象已经有了mSyncGroup并且还是与当前指定的对象不同，那就得抛出异常了。而这个mSyncGroup如果已经被赋值，则说明这个WindowContainer正在被这个SyncGroup等待。如果他没被赋值，则只会被他的福WindowContainer等待（当他在SyncGroup中时）

b) prepareSync

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;///（12）
    return true;
}

这里又出现了一个变量，mSyncState，对于这个变量，我们可以根据其定义进行了解：

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 {}
@SyncState int mSyncState = SYNC_STATE_NONE;

从上面可知，他只能取0/1/2三个值，而这三个值分别对应着：0->当前WindowContainer没有参与到一次同步操作中； 1->当前WindowContainer正在等待自身的绘制； 2->当前的WindowContainer已经绘制完成，但是其子WindowContainer可能未完成绘制。

所以在同步开始前，需要将其状态置为2；即（12）处的操作。当然这里可能会有点疑问，为什么这里什么也没操作就直接置为ready了呢？因为我们的WindowContainer是所有窗口类的父类，还会有不同的子类对其进行重写。而这里只是在其子WindowContainer完成prepareSync之后，即可置为ready，所以子WindowContainer的prepareSync其实才是关键所在。这里找到WindowState的prepareSync方法看一下。
如（13）处可见，这个WindowState的mSyncState的状态是从SYNC_STATE_WAITING_FOR_DRAW开始的，而不是上来就只为ready。

boolean prepareSync() {
    if (!mDrawHandlers.isEmpty()) {
        Slog.w(TAG, "prepareSync with mDrawHandlers, " + this + ", " + Debug.getCallers(8));
    }
    if (!super.prepareSync()) {
        return false;
    }
    if (mIsWallpaper) {
        // TODO(b/233286785): Add sync support to wallpaper.
        return false;
    }
    mSyncState = SYNC_STATE_WAITING_FOR_DRAW;  //(13)

    if (mPrepareSyncSeqId > 0) {
        ProtoLog.d(WM_DEBUG_SYNC_ENGINE, "Preparing to sync a window that was already in the"
                        + " sync, so try dropping buffer. win=%s", this);
        dropBufferFrom(mSyncTransaction);
    }

    mSyncSeqId++;
    if (getSyncMethod() == BLASTSyncEngine.METHOD_BLAST) {
        mPrepareSyncSeqId = mSyncSeqId;
    }
    requestRedrawForSync();
    return true;
}

不过问题又来了，WindowState的初始状态既然不是SYNC_STATE_READY，那么他在什么时候被设置为SYNC_STATE_READY的呢？这个问题放到下面的5）onTransactionReady模块再讲。

3） 将WindowContainerTransaction应用到WindowContainer

这个地方在WindowOrganizerController那篇博客已经讲解过了，这里就先不赘述了。

4） setReady：

回到（8）处，继续讲回到applySyncTransaction方法中，在确定了当前的mActiveSyncs中无元素时（5），将创建好的SyncGroup对象通过startSyncSet方法，放入mActiveSyncs之中（6），然后应用本次WindowContainerTransaction包含的所有修改（7）。 最后执行完所有的任务后，执行到（8）处setSyncReady(syncId);
这个方法有什么用呢？于是我们跟随代码一步一步的深挖下去。

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

BLASTSyncEngine.java
void setReady(int id, boolean ready) {
    getSyncGroup(id).setReady(ready);
}

void setReady(int id) {
    setReady(id, true);
}

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

通过代码可见，setSyncReady(syncId)方法最终调到了BLASTSyncEngine内部类SyncGroup中的setReady方法，这个方法的具体功能就是将mActiveSyncs中mSyncId为（8）处传入的syncId的SyncGroup对象的mReady设置为true，表示着本次WindowContainerTransaction中的修改已经全部应用完成了，并在最后请求一次界面刷新。

5） TransactionReady

在刷新界面的时候，RootWindowContainer中的performSurfacePlacementNoTrace会调用一次BLASTSyncEngine的onSurfacePlacement方法。这里也可以看到，在上面将SyncGroup的mReady置为true之后，这里（14）处才能继续执行下去。

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

private void onSurfacePlacement() {
    if (!mReady) return; //（14）
    ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "SyncGroup %d: onSurfacePlacement checking %s", mSyncId, mRootMembers);
    for (int i = mRootMembers.size() - 1; i >= 0; --i) { //(15)
        final WindowContainer wc = mRootMembers.valueAt(i); //(16)
        if (!wc.isSyncFinished()) {  //(17)
            ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "SyncGroup %d:  Unfinished container: %s", mSyncId, wc);
            return;
        }
    }
    finishNow();   //(18)
}

在上述代码的（15）和（16）处，就是去遍历mRootMembers中的WindowContainers，并确认其是否isSyncFinished。mRootMembers中的元素，前面讲过，就是在addToSync的时候进行填充的。而isSyncFinished返回的结果表示的是当前的WindowContainer是否已经完成同步了。那isSyncFinished具体做了哪些操作呢？这个函数在2、1）中就已经初步看了下，但是当时没有详细分析，现在对其进行详细的拆解：

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;
}

而根据前面的分析2、2）、b）中，在prepareSync的时候，主要是看WindowState容器是否被设置为SYNC_STATE_READY即可，因为父WindowContainer都是在等子WindowContainer的prepareSync操作而已。而WindowState的prepareSync则是将其状态设置为SYNC_STATE_WAITING_FOR_DRAW，那么什么时候会将其置为SYNC_STATE_READY呢？在代码中搜索将状态置为SYNC_STATE_READY的地方，只找到了一处：

boolean onSyncFinishedDrawing() {
    if (mSyncState == SYNC_STATE_NONE) return false;
    mSyncState = SYNC_STATE_READY;
    mSyncMethodOverride = BLASTSyncEngine.METHOD_UNDEFINED;
    ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "onSyncFinishedDrawing %s", this);
    return true;
}

那又是哪里调用的onSyncFinshedDrawing方法呢？继续寻找：

boolean isSyncFinished() {
    if (!isVisibleRequested()) {
        // Don't wait for invisible windows. However, we don't alter the state in case the
        // window becomes visible while the sync group is still active.
        return true;
    }
    if (mSyncState == SYNC_STATE_WAITING_FOR_DRAW && mWinAnimator.mDrawState == HAS_DRAWN
            && !mRedrawForSyncReported && !mWmService.mResizingWindows.contains(this)) {
        // Complete the sync state immediately for a drawn window that doesn't need to redraw.
        onSyncFinishedDrawing();
    }
    return super.isSyncFinished();
}

而这里的finishDrawing方法，根据调用栈能看到，是从ViewRootImpl.reportDrawFinished -> Session.finshDrawing -> WMS.finshDrawingWindow -> WindowState.finishDrawing -> WindowContainer.onSyncFinishedDrawing这一套流程调用过来的。 在之前关于WindowManagerService的相关博客中，我已经讲解过了，Session类的作用，主要就是应用侧与系统侧沟通的桥梁，应用侧可以通过Session来调用WMS的一些功能。 所以那就是说，finishDrawing就是应用侧绘制完成后主动通知系统侧，这时候才能将对应的WindowState的mSyncState设置为SYNC_STATE_READY了。
当然这里还有另一个条件，必须满足这一个条件，isSyncFinished才能返回true：

• 所有的子窗口的isSyncFinished也是true，并且所有窗口都要显示，并且能够覆盖到他的parent窗口，则返回true；
• 如果找到一个子窗口的isSyncFinished为false的话，则返回false；
• 如果遍历完所有子窗口，但是上述两个条件都不满足，那也可以返回true；

从这里也可以看出，只有mRootMembers中的所有元素完成了同步，这时候才能进入finshNow流程，即代码中的（18）处。 接下来就看下finshNow中具体执行了什么流程。

private void finishNow() {
    if (mTraceName != null) {
        Trace.asyncTraceEnd(TRACE_TAG_WINDOW_MANAGER, mTraceName, mSyncId);
    }
    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 */);
    }

    final ArraySet<WindowContainer> wcAwaitingCommit = new ArraySet<>();
    for (WindowContainer wc : mRootMembers) {
        wc.waitForSyncTransactionCommit(wcAwaitingCommit);
    }
    class CommitCallback implements Runnable {
        boolean ran = false;
        public void onCommitted() {
            synchronized (mWm.mGlobalLock) {
                if (ran) {
                    return;
                }
                mWm.mH.removeCallbacks(this);
                ran = true;
                SurfaceControl.Transaction t = new SurfaceControl.Transaction();
                for (WindowContainer wc : wcAwaitingCommit) {
                    wc.onSyncTransactionCommitted(t);
                }
                t.apply();
                wcAwaitingCommit.clear();
            }
        }
        @Override
        public void run() {
            Trace.traceBegin(TRACE_TAG_WINDOW_MANAGER, "onTransactionCommitTimeout");
            Slog.e(TAG, "WM sent Transaction to organized, but never received" +
                   " commit callback. Application ANR likely to follow.");
            Trace.traceEnd(TRACE_TAG_WINDOW_MANAGER);
            onCommitted();

        }
    };
    CommitCallback callback = new CommitCallback();
    merged.addTransactionCommittedListener((r) -> { r.run(); }, callback::onCommitted);
    mWm.mH.postDelayed(callback, BLAST_TIMEOUT_DURATION);

    Trace.traceBegin(TRACE_TAG_WINDOW_MANAGER, "onTransactionReady");
    mListener.onTransactionReady(mSyncId, merged);
    Trace.traceEnd(TRACE_TAG_WINDOW_MANAGER);
    mActiveSyncs.remove(mSyncId);
    mWm.mH.removeCallbacks(mOnTimeout);

    // Immediately start the next pending sync-transaction if there is one.
    if (mActiveSyncs.size() == 0 && !mPendingSyncSets.isEmpty()) {
        ProtoLog.v(WM_DEBUG_SYNC_ENGINE, "PendingStartTransaction found");
        final PendingSyncSet pt = mPendingSyncSets.remove(0);
        pt.mStartSync.run();
        if (mActiveSyncs.size() == 0) {
            throw new IllegalStateException("Pending Sync Set didn't start a sync.");
        }
        // Post this so that the now-playing transition setup isn't interrupted.
        mWm.mH.post(() -> {
            synchronized (mWm.mGlobalLock) {
                pt.mApplySync.run();
            }
        });
    }
}

不过finishNow流程还是比较复杂的，这里就看下几个核心的地方：

a）存放所有Transaction的容器merged：

SurfaceControl.Transaction merged = mWm.mTransactionFactory.get();
if (mOrphanTransaction != null) {
    merged.merge(mOrphanTransaction); //(19)
}
for (WindowContainer wc : mRootMembers) {
    wc.finishSync(merged, false /* cancel */);//(20)
}

首先是这一块流程，这里可见首先新建了一个Transaction对象：merged，然后将mOrphanTransation放入其中。但是mOrphanTransation又是什么东西呢？根据调用关系，可以看到只有在onSyncReparent中，（21）处对其进行了操作，这里从函数名就可以推测出就是用来将当前WindowContainer重新放到另一个parent下的方法。再根据finishSync方法就可以看到，主要就是将当前WindowContainer和其子WindowContainer的mSyncTransaction（其中存放的就是对该WindowContainer的一些修改）放到mOrphanTransation。 这里的目的就是在SyncGroup中的WindowContainer的父WindowContainer发生变化时，会将他的mSyncTransaction放入mOrphanTransation，避免在reparent的过程中保存在WindowContainer的mSyncTransaction中的修改会丢失。

private void onSyncReparent(WindowContainer oldParent, WindowContainer newParent) {
…………………………………………………………………
        if (newParent == null || newParent.mSyncState == SYNC_STATE_NONE) {
……………………………………………………………………
            if (newParent == null) {
                // This is getting removed.
                if (oldParent.mSyncState != SYNC_STATE_NONE) {
                    // In order to keep the transaction in sync, merge it into the parent.
                    finishSync(oldParent.mSyncTransaction, true /* cancel */);
                } else if (mSyncGroup != null) {
                    // This is watched directly by the sync-group, so merge this transaction into
                    // into the sync-group so it isn't lost
                    finishSync(mSyncGroup.getOrphanTransaction(), true /* cancel */);   //（21）
                } else {
                    throw new IllegalStateException("This container is in sync mode without a sync"
                            + " group: " + this);
                }
                return;
…………………………………………………………………
}

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);
    }
    if (cancel && mSyncGroup != null) mSyncGroup.onCancelSync(this);
    mSyncState = SYNC_STATE_NONE;
    mSyncMethodOverride = BLASTSyncEngine.METHOD_UNDEFINED;
    mSyncGroup = null;
}

b）finishSync：

在(20)处又调用了finishSync方法，将mRootMembers中的WindowContainer及其子WindowContainer中的mSyncTransaction都放到了merged当中， 而且最终还会将每个WindowContainer的mSyncState置为SYNC_STATE_NONE，mSyncGroup也会置为null，这就意味着将这些WindowContainer的状态复位了。

c）CmmitCallback：

class CommitCallback implements Runnable {
    // Can run a second time if the action completes after the timeout.
    boolean ran = false;
    public void onCommitted() {
        synchronized (mWm.mGlobalLock) {
            if (ran) {
                return;
            }
            mWm.mH.removeCallbacks(this);
            ran = true;
            SurfaceControl.Transaction t = new SurfaceControl.Transaction();
            for (WindowContainer wc : wcAwaitingCommit) {
                wc.onSyncTransactionCommitted(t);
            }
            t.apply();
            wcAwaitingCommit.clear();
        }
    }

    // Called in timeout
    @Override
    public void run() {
        Trace.traceBegin(TRACE_TAG_WINDOW_MANAGER, "onTransactionCommitTimeout");
	Slog.e(TAG, "WM sent Transaction to organized, but never received" + " commit callback. Application ANR likely to follow.");
        Trace.traceEnd(TRACE_TAG_WINDOW_MANAGER);
        onCommitted();
    }
};
CommitCallback callback = new CommitCallback();
merged.addTransactionCommittedListener((r) -> { r.run(); }, callback::onCommitted);
mWm.mH.postDelayed(callback, BLAST_TIMEOUT_DURATION);

public Transaction addTransactionCommittedListener(
        @NonNull @CallbackExecutor Executor executor,
        @NonNull TransactionCommittedListener listener) {
    TransactionCommittedListener listenerInner =
            () -> executor.execute(listener::onTransactionCommitted);
    nativeAddTransactionCommittedListener(mNativeObject, listenerInner);
    return this;
}

public interface TransactionCommittedListener {
    void onTransactionCommitted();
}

这里具体的原因不是很清楚，主要的操作是：申明一个内部类CommitCallback，然后通过merged注册一个CommittedListener，这个TransactionCommittedListener函数的功能，主要是在merged这个对象执行Committed的时候触发，然后新起一个线程，执行listener对象的onTransactionCommitted方法。 那listener对象的onTransactionCommitted方法体是什么呢？ 根据调用处发现这个listener对象是用lambda表达式写的：callback::onCommitted； 而TransactionCommittedListener类也是一个接口，所以定义的时候，按照传统的方式，这里应该是写成下面的方式：

merged.addTransactionCommittedListener((r) -> {
    r.run();
}, new SurfaceControl.TransactionCommittedListener() {
    @Override
    public void onTransactionCommitted() {
        callback.onCommitted();
    }
});

继而在上述函数的基础上进一步简化：

merged.addTransactionCommittedListener((r) -> {
    r.run();
}, () -> {
    callback.onCommitted();
});

最后就可简化成merged.addTransactionCommittedListener(® -> { r.run(); }, callback::onCommitted); 这种形式，不过有一说一，lambda表达式虽然能让代码变得更简洁，但是也确实降低了代码的可读性。
而这里就看一下callback的onCommitted的方法到底是干嘛的，其实根据代码的解读，就是简单的将mRootMembers中的WindowContainer的mSyncTransaction全部放到一个新的Transaction中，然后apply。
而merged是什么会执行commit方法呢？这里就涉及到一些Transaction的知识，一般来说Transaction都是通过binder发送至SystemUI侧，然后经过一些处理后，再由binder发送至SurfaceFlinger侧。而在提交到SurfaceFlinger的时候就会触发commit操作，这时候TransactionCommittedListener的onTransactionCommitted回调就会被触发。
所以这个流程就是在merged被commit的时候，系统侧会同时apply mRootMembers中所有WindowContainer的mSyncTransactions。

d）onTransactionReady：

mListener.onTransactionReady(mSyncId, merged);
在finishNow中，还有一个比较熟悉的方法，就是这个onTransactionReady方法，这个onTransactionReady其实就是WindowOrganizerController中的那个，最终的还是跨进程调用的SyncTransactionQueue.java中的onTransactionReady，这个前面已经讲过了。

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);
}

e）移除SyncGroup

mActiveSyncs.remove(mSyncId);
在执行完上面的所有操作后，在最后，会根据mSyncId从mActiveSyncs中移除这个对应SyncGroup。而到了这里，所有对WindowContainers的修改都合并到了merged中，并且也传输到了systemUI侧（通过onTransactionReady），最后也会在SyncTransactionQueue里的SyncCallback中的onTransactionReady中apply这些修改。

6） 总结：

有一说一BLASTSyncEngine这个类功能有点多，想通过看一遍博客就了解是很难的，前面讲了这么多，如果真的想深入的理解，还得自己跟着代码一个一个的看，并将相关的思路都记录下来。

首先对我们本篇博客进行一个总结，我们首先讲解了SyncGroup类，然后顺着上一篇博客WindowOrganizerController的流程，讲解其中和BLASTSyncEngine相关的内容。
1、 在applySyncTransaction中通过prepareSyncWithOrganizer创建一个SyncGroup；
2、 检查当前mActiveSyncs中是否有SyncGroup对象，其实如果为空，那就执行接下来的操作，不为空就是将接下来的操作暂存起来，等待时机执行；
3、 在applyTransaction时，通过addToSyncSet方法将WindowContainerTransaction中相关的WindowContainer放入mRootMembers中，并将WindowContainer的子窗口WindowState的mSyncState标志位置为SYNC_STATE_WAITING_FOR_DRAW，并应用WindowContainerTransaction中包含的所有修改；
4、 执行完步骤3之后，将SyncGroup的mReady状态置为true；
5、 在之后的界面刷新时，通过onSurfacePlacement方法，不断检查SyncGroup中的WindowContainer是否全部同步完成（主要是通过isSyncFinished，只有应用侧完成finishDrawing才会将WindowState的状态设置为SYNC_STATE_READY）；
6、 一旦完成同步，finishSync将SyncGroup的mRootMembers中所有的参与同步WindowContainer的相关mSyncTransaction和SyncGroup的mOrphanTransaction合并到一个Transaction对象merged中，最后通过onTransactionReady发送至systemUI侧，并apply，最后将mSyncState置为SYNC_STATE_NONE。