[093]SurfaceSyncer的致命缺陷

背景

我遇到一個很有意思的ANR問題，從trace分析來看，Launcher應用在不斷地queuebuffer，但是SurfaceFlinger對應的buffer的數量沒有增加，也就意味著buffer無法被消費，等到3個buffer都是用掉了，應用也就dequeuebuffer不出來了，雖然dequeuebuffer的timeout時間是4s小于anr的5s，但是還是有可能觸發(fā)anr。

一、應用在不斷地queuebuffer，但是SurfaceFlinger對應的buffer的數量沒有增加

因為BlastBufferQueue被引入之后，queuebuffer之后，需要在調用Transaction的apply才能讓SurfaceFlinger對應的buffer數量增加，才能被消費

void BLASTBufferQueue::acquireNextBufferLocked(
        const std::optional<SurfaceComposerClient::Transaction*> transaction) {
    ....
    t->setBuffer(mSurfaceControl, buffer, fence, bufferItem.mFrameNumber, releaseBufferCallback);
    ....
    if (applyTransaction) {//情況一、常規(guī)的情況
        // All transactions on our apply token are one-way. See comment on mAppliedLastTransaction
        t->setApplyToken(mApplyToken).apply(false, true);//sf就會立馬更新buffer的數量
        mAppliedLastTransaction = true;
        mLastAppliedFrameNumber = bufferItem.mFrameNumber;
    } else {//情況二、特殊的情況
        //sf不會立馬更新，而是需要等sync機制，等所有窗口ready之后才能apply Transaction
        t->setBufferHasBarrier(mSurfaceControl, mLastAppliedFrameNumber);
        mAppliedLastTransaction = false;
    }
}

很明顯Trace中就是應該走了上面代碼中情況二，我一開始懷疑是我之前[076]SHELL TRANSITIONS
這個文章中講的BLASTSyncEngine機制導致了這個問題，然后我就嘗試打開這個日志。

adb shell wm logging enable-text WM_DEBUG_SYNC_ENGINE

但是事實并不如人意，沒有出現我預料中的WindowManager: SyncGroup的日志，然后我就繼續(xù)跟代碼，有沒有別的機制可以也走情況二

二、反向跟代碼

2.1 applyTransaction在什么情況下為false

2.1.1中首先acquireNextBufferLocked中transaction不為空，繼續(xù)反推
2.1.2中syncTransactionSet為true，也就說mTransactionReadyCallback不為空
2.1.3中有人調用了syncNextTransaction最后設置了mTransactionReadyCallback。

frameworks/native/libs/gui/BLASTBufferQueue.cpp
//2.1.1
void BLASTBufferQueue::acquireNextBufferLocked(
        const std::optional<SurfaceComposerClient::Transaction*> transaction) {
    SurfaceComposerClient::Transaction localTransaction;
    bool applyTransaction = true;
    SurfaceComposerClient::Transaction* t = &localTransaction;
    if (transaction) {//transaction不為空
        t = *transaction;
        applyTransaction = false;
    }
}
//2.1.2
void BLASTBufferQueue::onFrameAvailable(const BufferItem& item) {
    SurfaceComposerClient::Transaction* prevTransaction = nullptr;
    {
        BBQ_TRACE();
        std::unique_lock _lock{mMutex};
        const bool syncTransactionSet = mTransactionReadyCallback != nullptr;//mTransactionReadyCallback不為空

        if (syncTransactionSet) {//syncTransactionSet為true
            acquireNextBufferLocked(mSyncTransaction);

        } else if (!mWaitForTransactionCallback) {
            acquireNextBufferLocked(std::nullopt);
        }
    }
    if (prevCallback) {
        prevCallback(prevTransaction);
    }
}
//2.1.3
void BLASTBufferQueue::syncNextTransaction(
        std::function<void(SurfaceComposerClient::Transaction*)> callback,
        bool acquireSingleBuffer) {
        BBQ_TRACE();
        mTransactionReadyCallback = callback;//設置了callback
}

3.2 誰會調用syncNextTransaction

因為出問題的是app，我不信他會直接調用BLASTBufferQueue.cpp的syncNextTransaction，肯定調用BLASTBufferQueue.java的syncNextTransaction
調用的流程如下：
BLASTBufferQueue.java.syncNextTransaction->
android_graphics_BLASTBufferQueue.cpp.nativeSyncNextTransaction->
BLASTBufferQueue.cpp.syncNextTransaction

frameworks/base/graphics/java/android/graphics/BLASTBufferQueue.java
    public void syncNextTransaction(boolean acquireSingleBuffer,
            Consumer<SurfaceControl.Transaction> callback) {
        nativeSyncNextTransaction(mNativeObject, callback, acquireSingleBuffer);//跳轉到3.2.1
    }

    public void syncNextTransaction(Consumer<SurfaceControl.Transaction> callback) {
        syncNextTransaction(true /* acquireSingleBuffer */, callback);
    }


frameworks/base/core/jni/android_graphics_BLASTBufferQueue.cpp
//3.2.1
static void nativeSyncNextTransaction(JNIEnv* env, jclass clazz, jlong ptr, jobject callback,
                                      jboolean acquireSingleBuffer) {
    sp<BLASTBufferQueue> queue = reinterpret_cast<BLASTBufferQueue*>(ptr);
    JavaVM* vm = nullptr;
    LOG_ALWAYS_FATAL_IF(env->GetJavaVM(&vm) != JNI_OK, "Unable to get Java VM");
    if (!callback) {
        queue->syncNextTransaction(nullptr, acquireSingleBuffer);
    } else {
        auto globalCallbackRef =
                std::make_shared<JGlobalRefHolder>(vm, env->NewGlobalRef(callback));
        queue->syncNextTransaction(
                [globalCallbackRef](SurfaceComposerClient::Transaction* t) {
                    JNIEnv* env = getenv(globalCallbackRef->vm());
                    env->CallVoidMethod(globalCallbackRef->object(), gTransactionConsumer.accept,
                                        env->NewObject(gTransactionClassInfo.clazz,
                                                       gTransactionClassInfo.ctor,
                                                       reinterpret_cast<jlong>(t)));
                },
                acquireSingleBuffer);
    }
}

接下來那就搜源碼中所有調用BLASTBufferQueue.java的syncNextTransaction的代碼，好在結果不多，憑借我十年的工作經驗，繼續(xù)跟registerCallbacksForSync

2.3 onReadyToSync最終觸發(fā)了syncNextTransaction

繼續(xù)反推代碼
2.3.1中syncBuffer和syncBufferCallback不為空
2.3.2中mSyncBufferCallback是不為空的
2.3.3和2.3.4中SurfaceSyncer.SyncTarget將會調用onReadyToSync然后設置mSyncBufferCallback ，接下來就看誰調用了onReadyToSync。

我準備用這條神奇日志來跟蹤，因為繼續(xù)反向跟太累了

Log.v("kobewang", "onReadyToSync", new Exception("kobewang"));

frameworks/base/core/java/android/view/ViewRootImpl.java
    //2.3.1
    private void registerCallbacksForSync(boolean syncBuffer,
            final SurfaceSyncer.SyncBufferCallback syncBufferCallback) {
       
        mAttachInfo.mThreadedRenderer.registerRtFrameCallback(new FrameDrawingCallback() {
            @Override
            public void onFrameDraw(long frame) {
            }

            @Override
            public HardwareRenderer.FrameCommitCallback onFrameDraw(int syncResult, long frame) {
                //開始繪制的時候設置syncBufferCallback
                if (syncBuffer) {
                    mBlastBufferQueue.syncNextTransaction(syncBufferCallback::onBufferReady);
                }
            }
        }
    }
   //2.3.2
    private boolean performDraw() {
        boolean usingAsyncReport = isHardwareEnabled() && mSyncBufferCallback != null;//mSyncBufferCallback不為空 
        if (usingAsyncReport) {
            registerCallbacksForSync(mSyncBuffer, mSyncBufferCallback);
        } else if (mHasPendingTransactions) {
           
        }
    }

    //2.3.3
    private void readyToSync(SurfaceSyncer.SyncBufferCallback syncBufferCallback) {
        mSyncBufferCallback = syncBufferCallback;

    }
    //2.3.4
    public final SurfaceSyncer.SyncTarget mSyncTarget = new SurfaceSyncer.SyncTarget() {
        @Override
        public void onReadyToSync(SurfaceSyncer.SyncBufferCallback syncBufferCallback) {
            Log.v("kobewang", "onReadyToSync", new Exception("kobewang"));//我添加了一個日志
            readyToSync(syncBufferCallback);//最后設置了syncBufferCallback
        }

        @Override
        public void onSyncComplete() {
            mHandler.postAtFrontOfQueue(() -> {
                if (--mNumSyncsInProgress == 0 && mAttachInfo.mThreadedRenderer != null) {
                    HardwareRenderer.setRtAnimationsEnabled(true);
                }
            });
        }
    };

2.4 神奇的日志發(fā)揮了神奇的作用

堆棧中的行數可能對應不上，因為我屏蔽了一些我們公司的代碼，我用AOSP的代碼來表達意思

12-07 17:57:29.435  8956  8956 V kobewang: onReadyToSync
12-07 17:57:29.435  8956  8956 V kobewang: java.lang.Exception: kobewang
12-07 17:57:29.435  8956  8956 V kobewang:  at android.view.ViewRootImpl$9.onReadyToSync(ViewRootImpl.java:11501)
12-07 17:57:29.435  8956  8956 V kobewang:  at android.window.SurfaceSyncer$SyncSet.addSyncableSurface(SurfaceSyncer.java:352)
12-07 17:57:29.435  8956  8956 V kobewang:  at android.window.SurfaceSyncer.addToSync(SurfaceSyncer.java:231)
12-07 17:57:29.435  8956  8956 V kobewang:  at android.window.SurfaceSyncer.addToSync(SurfaceSyncer.java:210)
12-07 17:57:29.435  8956  8956 V kobewang:  at com.android.systemui.animation.ViewRootSync.synchronizeNextDraw(ViewRootSync.kt:7)
12-07 17:57:29.435  8956  8956 V kobewang:  at com.android.systemui.animation.ViewRootSync.synchronizeNextDraw(ViewRootSync.kt:11)
12-07 17:57:29.435  8956  8956 V kobewang:  at com.android.launcher3.taskbar.TaskbarLauncherStateController.onIconAlignmentRatioChanged(TaskbarLauncherStateController.java:88)

最關鍵的代碼onIconAlignmentRatioChanged，很明顯Launcher希望mLauncher.getHotseat()和mControllers.taskbarActivityContext.getDragLayer()這兩個View在下一幀同時顯示，利用的機制就是SurfaceSyncer。

    private void onIconAlignmentRatioChanged(Supplier<Float> alignmentSupplier) {
        // Sync the first frame where we swap taskbar and hotseat.
        if (firstFrameVisChanged && mCanSyncViews && !Utilities.IS_RUNNING_IN_TEST_HARNESS) {
            ViewRootSync.synchronizeNextDraw(mLauncher.getHotseat(),
                    mControllers.taskbarActivityContext.getDragLayer(),
                    () -> {});
        }
    }


    frameworks/base/packages/SystemUI/animation/src/com/android/systemui/animation/ViewRootSync.kt
    object ViewRootSync {
        private var surfaceSyncer: SurfaceSyncer? = null
    
        /**
         * Synchronize the next draw between the view roots of [view] and [otherView], then run [then].
         *
         * Note that in some cases, the synchronization might not be possible (e.g. WM consumed the
         * next transactions) or disabled (temporarily, on low ram devices). In this case, [then] will
         * be called without synchronizing.
         */
        fun synchronizeNextDraw(
            view: View,
            otherView: View,
            then: () -> Unit
        ) {
            if (!view.isAttachedToWindow || view.viewRootImpl == null ||
                !otherView.isAttachedToWindow || otherView.viewRootImpl == null ||
                view.viewRootImpl == otherView.viewRootImpl) {
                // No need to synchronize if either the touch surface or dialog view is not attached
                // to a window.
                then()
                return
            }
    
            surfaceSyncer = SurfaceSyncer().apply {
                val syncId = setupSync(Runnable { then() })
                addToSync(syncId, view)
                addToSync(syncId, otherView)
                markSyncReady(syncId)
            }//利用SurfaceSyncer實現兩個view的同一幀顯示
        }
    
        /**
         * A Java-friendly API for [synchronizeNextDraw].
         */
        @JvmStatic
        fun synchronizeNextDraw(view: View, otherView: View, then: Runnable) {
            synchronizeNextDraw(view, otherView, then::run)
        }
    }

mLauncher.getHotseat()就是最開頭背景中trace中dequeue timeout窗口，mControllers.taskbarActivityContext.getDragLayer()就是對應Taskbar，所以目前來看問題就出在了為什么Taskbar沒有完成繪制。

三、為什么Taskbar沒有完成繪制

當我把Taskbar也加進來的時候，和Launcher的主線程加進來，真相大白，原來某個service stop導致了原來Taskbar被銷毀了。


現場還原

一開始調用以下代碼希望trace中mLauncher.getHotseat()其實就是QuickstepLauncher與Taskbar利用SurfaceSyncer的功能進行同步顯示。

ViewRootSync.synchronizeNextDraw(mLauncher.getHotseat(),
                    mControllers.taskbarActivityContext.getDragLayer(),
                    () -> {});

雖然有一定的窗口銷毀的判斷。

if (!view.isAttachedToWindow || view.viewRootImpl == null ||
                !otherView.isAttachedToWindow || otherView.viewRootImpl == null ||
                view.viewRootImpl == otherView.viewRootImpl) {
                // No need to synchronize if either the touch surface or dialog view is not attached
                // to a window.
                then()
                return
            }

但是窗口銷毀恰好發(fā)生在這個判斷之后，所以等mLauncher.getHotseat()繪制完了，Taskbar因為窗口被銷毀了，導致沒有繪制完，最終導致了mLauncher.getHotseat()一直在等舊的Taskbar繪制完成，這怎么可能還等的到呢。

四、SurfaceSyncer連這種情況就沒有考慮到嘛？

一開始我還覺得不可能google工程師沒有考慮到這個問題，但是我看了SurfaceSyncer的代碼，的確發(fā)現SurfaceSyncer就是沒考慮這種情況。
當時我和同事溝通就覺得，應該有個timeout機制，例如1s以后需要同步顯示的Surface其中一個沒有繪制完成，剩下的Surface對應的Transation就應該apply出去。

4.1 相同的app在android 14上會界面卡，但是不會anr

新的線索，然后我去看android 14的代碼，結果發(fā)現SurfaceSyncer已經被SurfaceSyncGroup代替了，然后我就憑直覺搜了timeout，果然命中。
一旦timeout觸發(fā)，就會調用4.1.1中runnable的代碼， mPendingSyncs.clear()之后調用4.1.2的markSyncReady，然后調用4.1.3中checkIfSyncIsComplete，最后調用4.1.4中transaction.apply()，這樣子就可以解決問題中這種情況。

    frameworks/base/core/java/android/window/SurfaceSyncGroup.java

    public static final int TRANSACTION_READY_TIMEOUT = 1000 * Build.HW_TIMEOUT_MULTIPLIER;

    //4.1.1
    private void addTimeout() {
        Looper looper = null;
        synchronized (sHandlerThreadLock) {
            if (sHandlerThread == null) {
                sHandlerThread = new HandlerThread("SurfaceSyncGroupTimer");
                sHandlerThread.start();
            }

            looper = sHandlerThread.getLooper();
        }

        synchronized (mLock) {
            if (mTimeoutAdded || mTimeoutDisabled || looper == null) {
                // We only need one timeout for the entire SurfaceSyncGroup since we just want to
                // ensure it doesn't stay stuck forever.
                return;
            }

            if (mHandler == null) {
                mHandler = new Handler(looper);
            }

            mTimeoutAdded = true;
        }

        Runnable runnable = () -> {
            Log.e(TAG, "Failed to receive transaction ready in " + TRANSACTION_READY_TIMEOUT
                    + "ms. Marking SurfaceSyncGroup(" + mName + ") as ready");
            // Clear out any pending syncs in case the other syncs can't complete or timeout due to
            // a crash.
            synchronized (mLock) {
                mPendingSyncs.clear();//timeout時間到了就把mPendingSyncs清空
            }
            markSyncReady();//重新觸發(fā)sync的確認，因為mPendingSyncs已經為空了，就可以觸發(fā)
        };
        mHandler.postDelayed(runnable, this, TRANSACTION_READY_TIMEOUT);
    }
    //4.1.2
    public void markSyncReady() {
        if (DEBUG) {
            Log.d(TAG, "markSyncReady " + mName);
        }
        if (Trace.isTagEnabled(Trace.TRACE_TAG_VIEW)) {
            Trace.instantForTrack(Trace.TRACE_TAG_VIEW, mTrackName, "markSyncReady");
        }
        synchronized (mLock) {
            if (mHasWMSync) {
                try {
                    WindowManagerGlobal.getWindowManagerService().markSurfaceSyncGroupReady(mToken);
                } catch (RemoteException e) {
                }
            }
            mSyncReady = true;
            checkIfSyncIsComplete();//確認是否已經sync ready
        }
    }

    //4.1.3
    private void checkIfSyncIsComplete() {
        if (mFinished) {
            if (DEBUG) {
                Log.d(TAG, "SurfaceSyncGroup=" + mName + " is already complete");
            }
            mTransaction.apply();
            return;
        }

        if (Trace.isTagEnabled(Trace.TRACE_TAG_VIEW)) {
            Trace.instantForTrack(Trace.TRACE_TAG_VIEW, mTrackName,
                    "checkIfSyncIsComplete mSyncReady=" + mSyncReady
                            + " mPendingSyncs=" + mPendingSyncs.size());
        }

        if (!mSyncReady || !mPendingSyncs.isEmpty()) { //mPendingSyncs.isEmpty()為true
            if (DEBUG) {
                Log.d(TAG, "SurfaceSyncGroup=" + mName + " is not complete. mSyncReady="
                        + mSyncReady + " mPendingSyncs=" + mPendingSyncs.size());
            }
            return;
        }

        if (DEBUG) {
            Log.d(TAG, "Successfully finished sync id=" + mName);
        }
        mTransactionReadyConsumer.accept(mTransaction);//這里就會apply了
        mFinished = true;
        if (mTimeoutAdded) {
            mHandler.removeCallbacksAndMessages(this);
        }
    }

    //4.1.4
    mTransactionReadyConsumer = (transaction) -> {
        if (Trace.isTagEnabled(Trace.TRACE_TAG_VIEW)) {
            Trace.asyncTraceForTrackBegin(Trace.TRACE_TAG_VIEW, mTrackName,
                    "Invoke transactionReadyCallback="
                            + transactionReadyCallback.hashCode(), hashCode());
        }
        lastCallback.accept(null);

        try {
            transactionReadyCallback.onTransactionReady(transaction);
        } catch (RemoteException e) {
            transaction.apply();//這里就會apply了
        }
        if (Trace.isTagEnabled(Trace.TRACE_TAG_VIEW)) {
            Trace.asyncTraceForTrackEnd(Trace.TRACE_TAG_VIEW, mTrackName, hashCode());
        }
    };

五、總結

回到問題的最開始，現在你覺得這個bug是系統(tǒng)的問題還是應用的問題，可能覺得多數情況下，這類問題就是應用組和系統(tǒng)組之間互相扯皮。
應用組：為什么14是好的，13有問題。
系統(tǒng)組：為什么就你Launcher有問題，別的應用沒問題。
誰都不愿意仔細去分析，運氣好呢，可能這個bug在別的改動下影響service stop的時機，導致無法復現這個問題，最后就不了了之了。

如果說[011]一個看似是系統(tǒng)問題的應用問題的解決過程這個問題是多年學習Binder之后的體現，那這個問題就是我多年學習整個Android顯示框架之后的體現，整個過程，其實我沒有拿到出問題的機器，只能讓同事幫忙加日志，抓trace，自己在跟蹤代碼分析，整個分析過程并沒有文章中的那么順暢，也走了很多岔路，其實這個問題在一年前別項目已經報出過了，但是由于當時無法找到必現路徑，而且當時這問題也沒到我頭上分析，一直沒有找到root cause，這次總算把這個問題根因找到了，很開心，從中也學到了很多東西。

尾巴

最后同事問我有沒有整體的一個刷新流程圖，從input事件到顯示的教程，以及看Trace的技巧，我真的很難回答這個問題，我只能讓他去看我的B站視頻以及https://www.androidperformance.com/中介紹的trace的技巧，但是事實上就算看過了，去解決實際問題的時候，任何一個知識點的欠缺就需要你去補，養(yǎng)兵千日，用在一時，知識學習也是一樣，平時不斷地積累，然后工作中不斷對已經學習知識點深入理解，鞏固，最后才能不斷地進步。

最后編輯于 ：
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成，瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發(fā)布，文章內容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關閱讀更多精彩內容

  • 最近在準備android面試，整理了下相關的面試題，分為如下三個部分：android部分、Java部分、算法面試題...
    JasmineBen閱讀 7,485評論 10贊 137
  • 努比亞技術團隊原創(chuàng)內容，轉載請務必注明出處。當用戶抱怨手機在使用過程中存在卡頓問題的時候，會嚴重影響用戶對手機品牌...
    努比亞技術團隊閱讀 37,366評論 12贊 175
  • 努比亞技術團隊原創(chuàng)內容，轉載請務必注明出處。 Android卡頓掉幀問題分析之原理篇[https://www.ji...
    努比亞技術團隊閱讀 24,431評論 3贊 58
  • 別人的總結不一定適合自己，所以盡量多做一些自己的總結，針對自己的薄弱點重點說明，適當的借鑒別人，少走一些彎路。最重...
    renkuo閱讀 7,592評論 2贊 48
  • 前言 成為一名優(yōu)秀的Android開發(fā)，需要一份完備的知識體系[https://github.com/JsonCh...
    我卡蘇總我閱讀 1,680評論 0贊 1

友情鏈接更多精彩內容