深入淺出Android BufferQueue-上

騰訊音樂技術發表於2019-04-12
Android

1. 背景

對業務開發來說，無法接觸到BufferQueue，甚至不知道BufferQueue是什麼東西。對系統來說，BufferQueue是很重要的傳遞資料的元件，Android顯示系統依賴於BufferQueue，只要顯示內容到“螢幕”(此處指抽象的螢幕，有時候還可以包含編碼器)，就一定需要用到BufferQueue，可以說在顯示/播放器相關的領域中，BufferQueue無處不在。即使直接呼叫Opengl ES來繪製，底層依然需要BufferQueue才能顯示到螢幕上。

弄明白BufferQueue，不僅可以增強對Android系統的瞭解，還可以弄明白/排查相關的問題，如為什麼Mediacodec呼叫dequeueBuffer老是返回-1？為什麼普通View的draw方法直接繪製內容即可，SurfaceView在draw完畢後還需要unlockCanvasAndPost？

注：本文分析的程式碼來自於Android6.0.1。

2. BufferQueue內部運作方式

BufferQueue是Android顯示系統的核心，它的設計哲學是生產者-消費者模型，只要往BufferQueue中填充資料，則認為是生產者，只要從BufferQueue中獲取資料，則認為是消費者。有時候同一個類，在不同的場景下既可能是生產者也有可能是消費者。如SurfaceFlinger，在合成並顯示UI內容時，UI元素作為生產者生產內容，SurfaceFlinger作為消費者消費這些內容。而在截圖時，SurfaceFlinger又作為生產者將當前合成顯示的UI內容填充到另一個BufferQueue，截圖應用此時作為消費者從BufferQueue中獲取資料並生產截圖。

以下是Android官網對其的介紹：

深入淺出Android BufferQueue-上


以下是常見的BufferQueue使用步驟：

  1. 初始化一個BufferQueue

  2. 圖形資料的生產者透過BufferQueue申請一塊GraphicBuffer，對應圖中的dequeueBuffer方法

  3. 申請到GraphicBuffer後，獲取GraphicBuffer，透過函式requestBuffer獲取

  4. 獲取到GraphicBuffer後，透過各種形式往GraphicBuffer中填充圖形資料後，然後將GraphicBuffer入隊到BufferQueue中，對應上圖中的queueBuffer方法

  5. 在新的GraphicBuffer入隊BufferQueue時，BufferQueue會透過回撥通知圖形資料的消費者，有新的圖形資料被生產出來了

  6. 然後消費者從BufferQueue中出隊一個GraphicBuffer，對應圖中的acquireBuffer方法

  7. 待消費者消費完圖形資料後，將空的GraphicBuffer還給BufferQueue以便重複利用，此時對應上圖中的releaseBuffer方法

  8. 此時BufferQueue再透過回撥通知圖形資料的生產者有空的GraphicBuffer了，圖形資料的生產者又可以從BufferQueue中獲取一個空的GraphicBuffer來填充資料

  9. 一直迴圈2-8步驟，這樣就有條不紊的完成了圖形資料的生產-消費


當然圖形資料的生產者可以不用等待BufferQueue的回撥再生產資料，而是一直生產資料然後入隊到BufferQueue，直到BufferQueue滿為止。圖形資料的消費者也可以不用等BufferQueue的回撥通知，每次都從BufferQueue中嘗試獲取資料，獲取失敗則嘗試，只是這樣效率比較低，需要不斷的輪訓BufferQueue（因為BufferQueue有同步阻塞和非同步阻塞兩種機種，在非同步阻塞機制下獲取資料失敗不會阻塞該執行緒直到有資料才喚醒該執行緒，而是直接返回-1）。

同時使用BufferQueue的生產者和消費者往往處在不同的程式，BufferQueue內部使用共享記憶體和Binder在不同的程式傳遞資料，減少資料複製提高效率。

和BufferQueue有關的幾個類分別是：

  1. BufferBufferCore：BufferQueue的實際實現

  2. BufferSlot：用來儲存GraphicBuffer

  3. BufferState：表示GraphicBuffer的狀態

  4. IGraphicBufferProducer：BufferQueue的生產者介面，實現類是BufferQueueProducer

  5. IGraphicBufferConsumer：BufferQueue的消費者介面，實現類是BufferQueueConsumer

  6. GraphicBuffer：表示一個Buffer，可以填充影像資料

  7. ANativeWindow_Buffer：GraphicBuffer的父類

  8. ConsumerBase：實現了ConsumerListener介面，在資料入佇列時會被呼叫到，用來通知消費者


BufferQueue中用BufferSlot來儲存GraphicBuffer，使用陣列來儲存一系列BufferSlot，陣列預設大小為64。

GraphicBuffer用BufferState來表示其狀態，有以下狀態：

  1. FREE：表示該Buffer沒有被生產者-消費者所使用，該Buffer的所有權屬於BufferQueue

  2. DEQUEUED：表示該Buffer被生產者獲取了，該Buffer的所有權屬於生產者

  3. QUEUED：表示該Buffer被生產者填充了資料，並且入隊到BufferQueue了，該Buffer的所有權屬於BufferQueue

  4. ACQUIRED：表示該Buffer被消費者獲取了，該Buffer的所有權屬於消費者


為什麼需要這些狀態呢？ 假設不需要這些狀態，實現一個簡單的BufferQueue，假設是如下實現：

BufferQueue{
    vector<GraphicBuffer> slots;
    void push(GraphicBuffer slot){
        slots.push(slot);
    }

    GraphicBuffer pull(){
        return slots.pull();
    }
}

生產者生產完資料後，透過呼叫BufferQueue的push函式將資料插入到vector中。消費者呼叫BufferQueue的pull函式出隊一個Buffer資料。

上述實現的問題在於，生產者每次都需要自行建立GraphicBuffer，而消費者每次消費完資料後的GraphicBuffer就被釋放了，GraphicBuffer沒有得到迴圈利用。而在Android中，由於BufferQueue的生產者-消費者往往處於不同的程式，GraphicBuffer內部是需要透過共享記憶體來連線生成者-消費者程式的，每次建立GraphicBuffer，即意味著需要建立共享記憶體，效率較低。

而BufferQueue中用BufferState來表示GraphicBuffer的狀態則解決了這個問題。每個GraphicBuffer都有當前的狀態，透過維護GraphicBuffer的狀態，完成GraphicBuffer的複用。

由於BufferQueue內部實現是BufferQueueCore，下文均用BufferQueueCore代替BufferQueue。先介紹下BufferQueueCore內部相應的資料結構，再介紹BufferQueue的狀態扭轉過程和生產-消費過程。

以下是Buffer的入隊/出隊操作和BufferState的狀態扭轉的過程，這裡只介紹非同步阻塞模式。

2.1 BufferQueueCore內部資料結構

核心資料結構如下：

BufferQueueDefs::SlotsType mSlots：用陣列存放的Slot，陣列預設大小為BufferQueueDefs::NUM_BUFFER_SLOTS,具體是64，代表所有的Slot
std::set<int> mFreeSlots：當前所有的狀態為FREE的Slot，這些Slot沒有關聯上具體的GraphicBuffer，後續用的時候還需要關聯上GraphicBuffer
std::list<int> mFreeBuffers：當前所有的狀態為FREE的Slot，這些Slot已經關聯上具體的GraphicBuffer，可以直接使用
Fifo mQueue：一個先進先出佇列，儲存了生產者生產的資料

在BufferQueueCore初始化時，由於此時佇列中沒有入隊任何資料，按照上面的介紹，此時mFreeSlots應該包含所有的Slot，元素大小和mSlots一致，初始化程式碼如下：

for (int slot = 0; slot < BufferQueueDefs::NUM_BUFFER_SLOTS; ++slot) {
        mFreeSlots.insert(slot);
    }

2.2 生產者dequeueBuffer

當生產者可以生產圖形資料時，首先向BufferQueue中申請一塊GraphicBuffer。呼叫函式BufferQueueProducer.dequeueBuffer，如果當前BufferQueue中有可用的GraphicBuffer，則返回其對用的索引；如果不存在，則返回-1，程式碼在BufferQueueProducer，流程如下：

status_t BufferQueueProducer::dequeueBuffer(int *outSlot,
        sp<android::Fence> *outFence, bool async,
        uint32_t width, uint32_t height, PixelFormat format, uint32_t usage) {

             //1. 尋找可用的Slot，可用指Buffer狀態為FREE
             status_t status = waitForFreeSlotThenRelock("dequeueBuffer", async,
                    &found, &returnFlags);
            if (status != NO_ERROR) {
                return status;
            }
            //2.找到可用的Slot，將Buffer狀態設定為DEQUEUED，由於步驟1找到的Slot狀態為FREE,因此這一步完成了FREE到DEQUEUED的狀態切換
            *outSlot = found;
            ATRACE_BUFFER_INDEX(found);
            attachedByConsumer = mSlots[found].mAttachedByConsumer;
            mSlots[found].mBufferState = BufferSlot::DEQUEUED;
            //3. 找到的Slot如果需要申請GraphicBuffer，則申請GraphicBuffer，這裡採用了懶載入機制，如果記憶體沒有申請，申請記憶體放在生產者來處理
            if (returnFlags & BUFFER_NEEDS_REALLOCATION) {
                status_t error;
                sp<GraphicBuffer> graphicBuffer(mCore->mAllocator->createGraphicBuffer(width, height, format, usage, &error));
                graphicBuffer->setGenerationNumber(mCore->mGenerationNumber);
                mSlots[*outSlot].mGraphicBuffer = graphicBuffer;
            }
}

關鍵在於尋找可用Slot，waitForFreeSlotThenRelock的流程如下：

status_t BufferQueueProducer::waitForFreeSlotThenRelock(const char* caller,
        bool async, int* found, status_t* returnFlags) const {

    //1. mQueue 是否太多
    bool tooManyBuffers = mCore->mQueue.size()> static_cast<size_t>(maxBufferCount);
        if (tooManyBuffers) {

        } else {
            // 2. 先查詢mFreeBuffers中是否有可用的，由2.1介紹可知，mFreeBuffers中的元素關聯了GraphicBuffer，直接可用
            if (!mCore->mFreeBuffers.empty()) {
                auto slot = mCore->mFreeBuffers.begin();
                *found = *slot;
                mCore->mFreeBuffers.erase(slot);
            } else if (mCore->mAllowAllocation && !mCore->mFreeSlots.empty()) {
                // 3. 再查詢mFreeSlots中是否有可用的，由2.1可知，初始化時會填充滿這個列表，因此第一次呼叫一定不會為空。同時用這個列表中的元素需要關聯上GraphicBuffer才可以直接使用，關聯的過程由外層函式來實現
                auto slot = mCore->mFreeSlots.begin();
                // Only return free slots up to the max buffer count
                if (*slot < maxBufferCount) {
                    *found = *slot;
                    mCore->mFreeSlots.erase(slot);
                }
            }
        }

         tryAgain = (*found == BufferQueueCore::INVALID_BUFFER_SLOT) ||
                   tooManyBuffers;
        //4. 如果找不到可用的Slot或者Buffer太多（同步阻塞模式下），則可能需要等
        if (tryAgain) {
            if (mCore->mDequeueBufferCannotBlock &&
                    (acquiredCount <= mCore->mMaxAcquiredBufferCount)) {
                return WOULD_BLOCK;
            }
            mCore->mDequeueCondition.wait(mCore->mMutex);
        }
}

waitForFreeSlotThenRelock函式會嘗試尋找一個可用的Slot，可用的Slot狀態一定是FREE（因為是從兩個FREE狀態的列表中獲取的），然後dequeueBuffer將狀態改變為DEQUEUED，即完成了狀態的扭轉。

waitForFreeSlotThenRelock返回可用的Slot分為兩種：

  1. 從mFreeBuffers中獲取到的，mFreeBuffers中的元素關聯了GraphicBuffer，直接可用

  2. 從mFreeSlots中獲取到的，沒有關聯上GraphicBuffer，因此需要申請GraphicBuffer並和Slot關聯上，透過createGraphicBuffer申請一個GraphicBuffer，然後賦值給Slot的mGraphicBuffer完成關聯


小結dequeueBuffer：嘗試找到一個Slot，並完成Slot與GraphicBuffer的關聯（如果需要），然後將Slot的狀態由FREE扭轉成DEQUEUED，返回Slot在BufferQueueCore中mSlots對應的索引。

2.3 生產者requestBuffer

dequeueBuffer函式獲取到了可用Slot的索引後，透過requestBuffer獲取到對應的GraphicBuffer。流程如下：

status_t BufferQueueProducer::requestBuffer(int slot, sp<GraphicBuffer>* buf) {

    // 1. 判斷slot引數是否合法
    if (slot < 0 || slot >= BufferQueueDefs::NUM_BUFFER_SLOTS) {
        BQ_LOGE("requestBuffer: slot index %d out of range [0, %d)",
                slot, BufferQueueDefs::NUM_BUFFER_SLOTS);
        return BAD_VALUE;
    } else if (mSlots[slot].mBufferState != BufferSlot::DEQUEUED) {
        BQ_LOGE("requestBuffer: slot %d is not owned by the producer "
                "(state = %d)", slot, mSlots[slot].mBufferState);
        return BAD_VALUE;
    }

    //2. 將mRequestBufferCalled置為true
    mSlots[slot].mRequestBufferCalled = true;
    *buf = mSlots[slot].mGraphicBuffer;
    return NO_ERROR;
}

這一步不是必須的，業務層可以直接透過Slot的索引獲取到對應的GraphicBuffer。

2.4 生產者queueBuffer

上文dequeueBuffer獲取到一個Slot後，就可以在Slot對應的GraphicBuffer上完成影像資料的生產了，可以是View的主執行緒Draw過程，也可以是SurfaceView的子執行緒繪製過程，甚至可以是MediaCodec的解碼過程。

填充完影像資料後，需要將Slot入隊BufferQueueCore（資料寫完了，可以傳給生產者-消費者佇列，讓消費者來消費了），入隊呼叫queueBuffer函式。queueBuffer的流程如下：

status_t BufferQueueProducer::queueBuffer(int slot,
        const QueueBufferInput &input, QueueBufferOutput *output) {

        // 1. 先判斷傳入的Slot是否合法
        if (slot < 0 || slot >= maxBufferCount) {
            BQ_LOGE("queueBuffer: slot index %d out of range [0, %d)",
                    slot, maxBufferCount);
            return BAD_VALUE;
        }

        //2. 將Buffer狀態扭轉成QUEUED，此步完成了Buffer的狀態由DEQUEUED到QUEUED的過程
        mSlots[slot].mFence = fence;
        mSlots[slot].mBufferState = BufferSlot::QUEUED;
        ++mCore->mFrameCounter;
        mSlots[slot].mFrameNumber = mCore->mFrameCounter;

        //3. 入隊mQueue
        if (mCore->mQueue.empty()) {
            mCore->mQueue.push_back(item);
            frameAvailableListener = mCore->mConsumerListener;
        } 

        // 4. 回撥frameAvailableListener，告知消費者有資料入隊了
        if (frameAvailableListener != NULL) {
            frameAvailableListener->onFrameAvailable(item);
        } else if (frameReplacedListener != NULL) {
            frameReplacedListener->onFrameReplaced(item);
        }
}


從上面的註釋可以看到，queueBuffer的主要步驟如下：

  1. 將Buffer狀態扭轉成QUEUED，此步完成了Buffer的狀態由DEQUEUED到QUEUED的過程

  2. 將Buffer入隊到BufferQueueCore的mQueue佇列中

  3. 回撥frameAvailableListener，告知消費者有資料入隊，可以來消費資料了，frameAvailableListener是消費者註冊的回撥


小結queueBuffer：將Slot的狀態扭轉成QUEUED，並新增到mQueue中，最後通知消費者有資料入隊。

2.5 消費者acquireBuffer

在消費者接收到onFrameAvailable回撥時或者消費者主動想要消費資料，呼叫acquireBuffer嘗試向BufferQueueCore獲取一個資料以供消費。消費者的程式碼在BufferQueueConsumer中，acquireBuffer流程如下：

status_t BufferQueueConsumer::acquireBuffer(BufferItem* outBuffer,
        nsecs_t expectedPresent, uint64_t maxFrameNumber) {

        //1. 如果佇列為空，則直接返回
        if (mCore->mQueue.empty()) {
            return NO_BUFFER_AVAILABLE;
        }

        //2. 取出mQueue佇列的第一個元素，並從佇列中移除
        BufferQueueCore::Fifo::iterator front(mCore->mQueue.begin());
           int slot = front->mSlot;
        *outBuffer = *front;
        mCore->mQueue.erase(front);

        //3. 處理expectedPresent的情況，這種情況可能會連續丟幾個Slot的“顯示”時間小於expectedPresent的情況,這種情況下這些Slot已經是“過時”的，直接走下文的releaseBuffer消費流程,程式碼比較長，忽略了
              

        //4. 更新Slot的狀態為ACQUIRED
        if (mCore->stillTracking(front)) {
            mSlots[slot].mAcquireCalled = true;
            mSlots[slot].mNeedsCleanupOnRelease = false;
            mSlots[slot].mBufferState = BufferSlot::ACQUIRED;
            mSlots[slot].mFence = Fence::NO_FENCE;
        }

        //5. 如果步驟3有直接releaseBuffer的過程，則回撥生產者，有資料被消費了
        if (listener != NULL) {
            for (int i = 0; i < numDroppedBuffers; ++i) {
                listener->onBufferReleased();
            }
        }

}

從上面的註釋可以看到，acquireBuffer的主要步驟如下：

  1. 從mQueue佇列中取出並移除一個元素

  2. 改變Slot對應的狀態為ACQUIRED

  3. 如果有丟幀邏輯，回撥告知生產者有資料被消費，生產者可以準備生產資料了


小結acquireBuffer：將Slot的狀態扭轉成ACQUIRED，並從mQueue中移除，最後通知生產者有資料出隊。

2.6 消費者releaseBuffer

消費者獲取到Slot後開始消費資料（典型的消費如SurfaceFlinger的UI合成），消費完畢後，需要告知BufferQueueCore這個Slot被消費者消費完畢了，可以給生產者重新生產資料，releaseBuffer流程如下：

status_t BufferQueueConsumer::releaseBuffer(int slot, uint64_t frameNumber,
        const sp<Fence>& releaseFence, EGLDisplay eglDisplay,EGLSyncKHR eglFence) {

         //1. 檢查Slot是否合法
        if (slot < 0 || slot >= BufferQueueDefs::NUM_BUFFER_SLOTS ||         
            return BAD_VALUE;
        }

        //2. 容錯處理：如果要處理的Slot存在於mQueue中，那麼說明這個Slot的來源不合法，並不是從2.5的acquireBuffer獲取的Slot，拒絕處理
        BufferQueueCore::Fifo::iterator current(mCore->mQueue.begin());
        while (current != mCore->mQueue.end()) {
            if (current->mSlot == slot) {
                return BAD_VALUE;
            }
            ++current;
        } 

         // 3. 將Slot的狀態扭轉為FREE，之前是ACQUIRED，並將該Slot新增到BufferQueueCore的mFreeBuffers列表中（mFreeBuffers的定義參考2.1的介紹）
         if (mSlots[slot].mBufferState == BufferSlot::ACQUIRED) {
                mSlots[slot].mEglDisplay = eglDisplay;
                mSlots[slot].mEglFence = eglFence;
                mSlots[slot].mFence = releaseFence;
                mSlots[slot].mBufferState = BufferSlot::FREE;
                mCore->mFreeBuffers.push_back(slot);
                listener = mCore->mConnectedProducerListener;
                BQ_LOGV("releaseBuffer: releasing slot %d", slot);
            }

           // 4. 回撥生產者，有資料被消費了
           if (listener != NULL) {
               listener->onBufferReleased();
           }
}

從上面的註釋可以看到，releaseBuffer的主要步驟如下：

  1. 將Slot的狀態扭轉為FREE

  2. 將被消費的Slot新增到mFreeBuffers供後續的生產者dequeueBuffer使用

  3. 回撥告知生產者有資料被消費，生產者可以準備生產資料了


小結releaseBuffer：將Slot的狀態扭轉成FREE，並新增到BufferQueueCore mFreeBuffers佇列中，最後通知生產者有資料出隊。

總結下狀態變化的過程：

深入淺出Android BufferQueue-上


本文主要介紹了BufferQueue的設計思想和內部實現。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31557897/viewspace-2641227/，如需轉載，請註明出處，否則將追究法律責任。

相關文章