本文基于Android 13的代码。
以下是google官方对unsignaled-buffer-latch的部分介绍
https://source.android.google.cn/docs/core/graphics/unsignaled-buffer-latch?hl=zh-cn

背景

首先是千里马兄弟提出来了一个认知acquireFence只需要在HWC工作的之前signal就可以了，其实我也一直是这个认知，而且在
Android画面显示流程分析(3)-BufferQueue和Fence这篇文章中变相了提到了这点，如图中红色圈圈。但是他看了代码就感觉事实上如果buffer unsignaled，SurfaceFlinger无法放buffer过去给HWC，他自己的认知被颠覆，所以找我来确认，其实我第一眼代码也真的被颠覆了，后来经过我们两个晚上的不断讨论和抓trace分析，现在终于搞明白了。

26874665-0efd0e809cdd33c7.png

一、SurfaceFlinger对acquireFence unsignaled的buffer处理策略

首先有三种处理的策略，注释介绍很清楚

// Latch Unsignaled buffer behaviours
enum class LatchUnsignaledConfig {
    // All buffers are latched signaled.
    Disabled,

    // Latch unsignaled is permitted when a single layer is updated in a frame,
    // and the update includes just a buffer update (i.e. no sync transactions
    // or geometry changes).
    AutoSingleLayer,

    // All buffers are latched unsignaled. This behaviour is discouraged as it
    // can break sync transactions, stall the display and cause undesired side effects.
    Always,
};

对应这个策略有两个属性来控制debug.sf.latch_unsignaled和debug.sf.auto_latch_unsignaled

LatchUnsignaledConfig SurfaceFlinger::getLatchUnsignaledConfig() {
    if (base::GetBoolProperty("debug.sf.latch_unsignaled"s, false)) {
        return LatchUnsignaledConfig::Always;
    }

    if (base::GetBoolProperty("debug.sf.auto_latch_unsignaled"s, true)) {
        return LatchUnsignaledConfig::AutoSingleLayer;
    }

    return LatchUnsignaledConfig::Disabled;
}

总结成表格，大家可以看看手头的控制属性是什么，推断一下你的设备的LatchUnsignaledConfig。

LatchUnsignaledConfig	控制属性	配置说明
Disabled	debug.sf.latch_unsignaled = false debug.sf.auto_latch_unsignaled = false	所有的buffer必须是signaled
AutoSingleLayer	debug.sf.latch_unsignaled = false debug.sf.auto_latch_unsignaled = true	当这一帧中只简单的更新一个layer的buffer是时候， 允许使用unsignaled的buffer（换句话说，不支持sync transactions和layer的几何变化）
Always	debug.sf.latch_unsignaled = true	所有unsignaled buffer允许被使用，这个行为是不鼓励的， 因为会影响sync transactions功能，造成不希望的效果

二、代码解读

2.1 flushTransactionQueues

首先用一个图来表示主要逻辑，flushTransactionQueues的主要任务就是找到可以在这一帧被apply的事务

图中的4个步骤，正好对应以下代码中4步

bool SurfaceFlinger::flushTransactionQueues(int64_t vsyncId) {
    // to prevent onHandleDestroyed from being called while the lock is held,
    // we must keep a copy of the transactions (specifically the composer
    // states) around outside the scope of the lock
    std::vector<TransactionState> transactions;
    {
        Mutex::Autolock _l(mStateLock);
        {
            Mutex::Autolock _l(mQueueLock);
             ...
            //图中第1步
            transactionsPendingBarrier =
                    flushPendingTransactionQueues(transactions, bufferLayersReadyToPresent,
                            applyTokensWithUnsignaledTransactions, /*tryApplyUnsignaled*/ false);

            //图中第2步
            while (!mTransactionQueue.empty()) {
                auto& transaction = mTransactionQueue.front();
                const bool pendingTransactions =
                        mPendingTransactionQueues.find(transaction.applyToken) !=
                        mPendingTransactionQueues.end();
                const auto ready = [&]() REQUIRES(mStateLock) {
                    if (pendingTransactions) {
                        ATRACE_NAME("pendingTransactions");
                        return TransactionReadiness::NotReady;
                    }

                    return transactionIsReadyToBeApplied(transaction, transaction.frameTimelineInfo,
                                                         transaction.isAutoTimestamp,
                                                         transaction.desiredPresentTime,
                                                         transaction.originUid, transaction.states,
                                                         bufferLayersReadyToPresent,
                                                         transactions.size(),
                                                         /*tryApplyUnsignaled*/ false);
                }();
                ATRACE_INT("TransactionReadiness", static_cast<int>(ready));
                if (ready != TransactionReadiness::Ready) {
                    ....
                    mPendingTransactionQueues[transaction.applyToken].push(std::move(transaction));
                } else {
                    ....
                    transactions.emplace_back(std::move(transaction));
                }
                mTransactionQueue.pop_front();
                ATRACE_INT("TransactionQueue", mTransactionQueue.size());
            }
            ....
            //图中第3步
            if (enableLatchUnsignaledConfig != LatchUnsignaledConfig::Disabled) {
                flushUnsignaledPendingTransactionQueues(transactions, bufferLayersReadyToPresent,
                                                        applyTokensWithUnsignaledTransactions);
            }
            //图中第4步
            return applyTransactions(transactions, vsyncId);
        }
    }
}

int SurfaceFlinger::flushUnsignaledPendingTransactionQueues(
        std::vector<TransactionState>& transactions,
        std::unordered_map<sp<IBinder>, uint64_t, SpHash<IBinder>>& bufferLayersReadyToPresent,
        std::unordered_set<sp<IBinder>, SpHash<IBinder>>& applyTokensWithUnsignaledTransactions) {
    return flushPendingTransactionQueues(transactions, bufferLayersReadyToPresent,
                                         applyTokensWithUnsignaledTransactions,
                                         /*tryApplyUnsignaled*/ true);
}

这里有三个关键的数据结构

mTransactionQueue：当前这一帧的事务队列
mPendingTransactionQueues：pending未处理的事务队列
transactions：最后需要apply的事务队列

4步的解读

1.处理mPendingTransactionQueues的事务，这里就是前一帧未处理的事务，带入tryApplyUnsignaled=false，如果不是NotReady，就可以加入到了transactions。
2.处理mTransactionQueue的事务，带入tryApplyUnsignaled=false，NOT READY就加入到mPendingTransactionQueues，Ready就加入transactions
3.再次处理mPendingTransactionQueues的事务，这里包含了前一帧未处理的事务以及步骤2中NOT READY的事务，但是这次传入了tryApplyUnsignaled=true，如果不是NotReady，就可以加入到了transactions。
4.最后apply transactions中的事务。

其中1,2,3步都会调用transactionIsReadyToBeApplied，判断事务能否被apply，我们来分析transactionIsReadyToBeApplied

2.2 transactionIsReadyToBeApplied

对于2.1中flushTransactionQueues的前两个环节，可以知道tryApplyUnsignaled = false，所以allowLatchUnsignaled 肯定为false，如果fenceUnsignaled是true，就意味着肯定是NotReady，所以在前面两个步骤，不可能会有unsignaled的buffer对应的事务会被处理，只能寄托于第三个步骤了。

auto SurfaceFlinger::transactionIsReadyToBeApplied(TransactionState& transaction,
        const FrameTimelineInfo& info, bool isAutoTimestamp, int64_t desiredPresentTime,
        uid_t originUid, const Vector<ComposerState>& states,
        const std::unordered_map<
            sp<IBinder>, uint64_t, SpHash<IBinder>>& bufferLayersReadyToPresent,
        size_t totalTXapplied, bool tryApplyUnsignaled) const -> TransactionReadiness {

        ....

        const bool allowLatchUnsignaled = tryApplyUnsignaled &&
                shouldLatchUnsignaled(layer, s, states.size(), totalTXapplied);//如果tryApplyUnsignaled为 false，所以allowLatchUnsignaled 肯定为false

        if (fenceUnsignaled && !allowLatchUnsignaled) {
            if (!transaction.sentFenceTimeoutWarning &&
                queueProcessTime - transaction.queueTime > std::chrono::nanoseconds(4s).count()) {
                transaction.sentFenceTimeoutWarning = true;
                auto listener = s.bufferData->releaseBufferListener;
                if (listener) {
                    listener->onTransactionQueueStalled();
                }
            }

            ATRACE_NAME("fence unsignaled");
            return TransactionReadiness::NotReady;//如果fenceUnsignaled为true，那就返回TransactionReadiness::NotReady
        }
    }
    //如果tryApplyUnsignaled，shouldLatchUnsignaled，fenceUnsignaled 都为true，就可以得到TransactionReadiness::ReadyUnsignaled
    return fenceUnsignaled ? TransactionReadiness::ReadyUnsignaled : TransactionReadiness::Ready;
}

第三个环节中，传入的tryApplyUnsignaled = true，如果shouldLatchUnsignaled可以返回true，以及 fenceUnsignaled = true，就可以达到ReadyUnsignaled的条件，对于flushPendingTransactionQueues的流程，如果“不是NotReady“，然后就可以加入到transactions中。

2.3 flushPendingTransactionQueues

这就是我在第三个环节中讲的，如果“不是NotReady“，就可以加入到了transactions，ReadyUnsignaled就是“不是NotReady”

int SurfaceFlinger::flushPendingTransactionQueues(
        std::vector<TransactionState>& transactions,
        std::unordered_map<sp<IBinder>, uint64_t, SpHash<IBinder>>& bufferLayersReadyToPresent,
        std::unordered_set<sp<IBinder>, SpHash<IBinder>>& applyTokensWithUnsignaledTransactions,
        bool tryApplyUnsignaled) {
            ···
            if (ready == TransactionReadiness::NotReady) {
                setTransactionFlags(eTransactionFlushNeeded);
                break;
            }
            ···
            不是NotReady，所以ReadyUnsignaled就可以加入transactions
            transactions.emplace_back(std::move(transaction));
        }
}

2.4 shouldLatchUnsignaled

接下来继续回来看shouldLatchUnsignaled的代码了，这里前面LatchUnsignaledConfig::Disabled和LatchUnsignaledConfig::Always的条件返回的结果很简单。关键就看LatchUnsignaledConfig::AutoSingleLayer的情况下，也就是手机配置成了AutoSingleLayer，在什么条件下会返回true。

bool SurfaceFlinger::shouldLatchUnsignaled(const sp<Layer>& layer, const layer_state_t& state,
                                           size_t numStates, size_t totalTXapplied) const {
    if (enableLatchUnsignaledConfig == LatchUnsignaledConfig::Disabled) {
        ALOGV("%s: false (LatchUnsignaledConfig::Disabled)", __func__);
        return false;//永远不允许处理Unsignaled的buffer
    }

    if (enableLatchUnsignaledConfig == LatchUnsignaledConfig::Always) {
        ALOGV("%s: true (LatchUnsignaledConfig::Always)", __func__);
        return true;//永远允许处理Unsignaled的buffer
    }

    // 只允许处理single layer
    // We only want to latch unsignaled when a single layer is updated in this
    // transaction (i.e. not a blast sync transaction).
    if (numStates != 1) {
        ALOGV("%s: false (numStates=%zu)", __func__, numStates);
        return false;//第一关
    }

    if (enableLatchUnsignaledConfig == LatchUnsignaledConfig::AutoSingleLayer) {
        if (totalTXapplied > 0) {
            ALOGV("%s: false (LatchUnsignaledConfig::AutoSingleLayer; totalTXapplied=%zu)",
                  __func__, totalTXapplied);
            return false;//第二关
        }

        // We don't want to latch unsignaled if are in early / client composition
        // as it leads to jank due to RenderEngine waiting for unsignaled buffer
        // or window animations being slow.
        const auto isDefaultVsyncConfig = mVsyncModulator->isVsyncConfigDefault();
        if (!isDefaultVsyncConfig) {
            ALOGV("%s: false (LatchUnsignaledConfig::AutoSingleLayer; !isDefaultVsyncConfig)",
                  __func__);
            return false;//第三关
        }
    }

    if (!layer->simpleBufferUpdate(state)) {
        ALOGV("%s: false (!simpleBufferUpdate)", __func__);
        return false;//第四关
    }

    ALOGV("%s: true", __func__);
    return true;
}

如果手机配置成了AutoSingleLayer，可以看到要达到shouldLatchUnsignaled返回true，至少要闯过4关，其中第一和第四关分别对应就是注释中描述的i.e. no sync transactions or geometry changes。

numStates == 1 : 本次事务中是有一次layer，对应no sync transactions
totalTXapplied == 0 :transactions.size()为0，本次事务之前，还没有成功加入transactions的事务
isDefaultVsyncConfig == true : vsync的配置是默认
layer->simpleBufferUpdate(state) == true ：本次layer只有简单的buffer更新，不涉及layer的几何变化， 对应no geometry changes。

至此我们已经分析完成了，整个处理的逻辑，最后就是将transactions中所有保存的事务进行apply，开始这一帧的合成。

三、感悟

这两个晚上，我和千里马兄弟也是不断通过分析代码逻辑，猜测代码意图，再通过不同的属性值设置，以及抓了很多次trace来验证我们的猜想，两个人也是一起激烈的争论，真理总是越辩越明，最后终于把整个逻辑理顺，也许看了这个文章，你还是云里雾里的，整个逻辑的确不好理解，这次分析主要关注的就是在哪些情况下acquireFence unsignaled的buffer对应的事务可以被当前这一帧sf的合成处理，希望你按着这个思路去跟一下代码。

尾巴

这个问题讨论的意义在哪里呢，那就是画面的延迟问题，看下面这个trace，就差那么一丢丢，其实把图中GPU处理的这一个buffer放过去，sf的合成的时候acquireFence肯定完成signal了，但是因为这台机器上的策略，在当前情况下连续两次acquireFence的判断（紫色，绿色线），都无法将这次buffer放过去，最后只能空跑一帧，下一帧合成了，这样子就出现画面的延迟问题了。

官方的一段话，介绍为什么要使用AutoSingleLayer ，非常值得认真读几遍。

Android 13 添加了一项名为 AutoSingleLayer 的新配置，用于锁存无信号的缓冲区。此配置可让 SurfaceFlinger 在仅有单个层更新时锁存无信号的缓冲区，但不适用于跨层发生的情况，例如几何图形变化或同步事务。
在 Android 13 之前，AOSP 中的 debug.sf.latch_unsignaled 标志允许 SurfaceFlinger 锁存所有无信号的缓冲区（无论在何种使用情形下）。启用此配置会出现一些非预期的附带效应，例如在等待未完成的缓冲区期间破坏同步事务和冻结整个显示屏。
使用 AutoSingleLayer 模式时，只会更新相应帧中单个 Surface 的缓冲区。此模式让游戏和其他全屏应用可锁存无信号的缓冲区并减少应用卡顿，同时不受显示屏冻结的影响。