BufferQueue 的管理

1），對buffer的管理符合“生產者-消費者”模型，這里有以下幾個相關的類：

BufferQueueProducer.cpp是IGraphicBufferProducer對應服務端的實現，負責緩沖區的申請。

BufferQueueConsumer.cpp是IGraphicBufferProducer對應的服務端的實現，是buffer消費者。

BufferQueueCore.cpp，可以看作是Buffer的中樞，一方面BufferqueueProducer對buffer的申請也是通過BufferQueueCore來實現的，具體是BufferQueueCore中的GraphicBufferAlloc。另一方面，當有可以消費的buffer時，是通過BufferQueueCore通知到BufferQueueConsumer，具體是通過ConsumerListener來實現的。

GraphicBufferAlloc.cpp是IGraphicBufferAlloc對應的服務端的實現，負責GraphicBuffer的申請。

既然說BufferQueueCore中的GraphicBufferAlloc負責GraphicBuffer的申請，先來看下誰生成的GraphicBufferAlloc實例。

BufferQueueCore::BufferQueueCore(const sp<IGraphicBufferAlloc>& allocator) :mAllocator(allocator)@BufferQueueCore.cpp{if (allocator == NULL) { //這里返回的 ISurfaceComposer類型的對象 composer，實際就是SurfaceFinger，最終 IGraphicBufferAlloc的實例生成還是由SurfaceFinger來完成的。 ComposerService類是SurfaceComposerClient.cpp的內部類。sp<ISurfaceComposer> composer(ComposerService::getComposerService());mAllocator = composer->createGraphicBufferAlloc();} }

可以看到這里創建的是一個GraphicBufferAlloc對象。

sp<IGraphicBufferAlloc> SurfaceFlinger::createGraphicBufferAlloc()@SurfaceFlinger.cpp {sp<GraphicBufferAlloc> gba(new GraphicBufferAlloc());return gba; }

在BufferQueueCore的初始化列表中雖然給IGraphicBufferAlloc做了賦值：mAllocator(allocator)，但實際這個值是null的，因為它是由BufferQueue.cpp的默認參數傳過來的，而這默認參數初始值是null的，所以需要在構造函數中重新生成IGraphicBufferAlloc實例。

BufferQueueCore中有一個重要的成員數組BufferQueueDefs::SlotsTypemSlots;

前面在說的surface中也有一個同名的成員數組BufferSlotmSlots[NUM_BUFFER_SLOTS];都是BufferSlot類型，只是定義有差別。

這是Surface中的BufferSlot的定義，是一個結構體。

Surface.hstruct BufferSlot {sp<GraphicBuffer> buffer;Region dirtyRegion;}; BufferSlot mSlots[NUM_BUFFER_SLOTS];

下面是BufferQueueCore中的Bufferslot中的定義：

BufferSlot.h struct BufferSlot { // mGraphicBuffer指向一個slot所分配的buffer，如果buffer還沒分配，值為null。sp<GraphicBuffer> mGraphicBuffer; //標示一個buffer slot的當前狀態。BufferState mBufferState; }

一個buffer可以有5中狀態。

struct BufferState {

	mShared	mDequeueCount	mQueueCount	mAcquireCount
FREE	false	0	0	0
DEQUEUED	False	1	0	0
QUEUED	False	0	1	0
ACQUIRED	False	0	0	1
SHARED	True	Any	Any	any

FREE表明緩沖區當前可用，可以被生產者dequeued，這個slots的owner是BufferQueue，當dequeueBuffer后會轉變為DEQUEUED。

DEQUEUED表明這個buffer已經被生產者dequeued，但是還沒被queued或者canceled，生產者可以修改這個buffer的內容，現在buffer的owner是producer（應用程序），可以通過調用queueBuffer或attachBuffer轉成QUEUED，也可以通過調用cancelBuffer或detachBuffer轉成FREE。

QUEUED表明這個buffer已經被Producer填充了數據，可以被consumer使用，現在buffer的owner是BufferQueue，可以通過調用acquireBuffer轉成ACQUIRED，

ACQUIRED表明這個buffer已經被consumeracquired了，現在的owner是consumer，通過releasebuffer可以轉成FREE。

SHARED表明這個buffer被用于sharedbuffer mode。在同一時間，它可以是除FREE外的其他的狀態的集合。

}

通過上面buffer的各個狀態的介紹，對buffer的管理主要有BufferQueue，Producer，Consumer，三個對象。BufferQueue的實現者就是BufferQueueCore，它是一個中心，Producer想要獲取一個buffer，是通過BufferQueueCore完成的，同樣的當有一個buffer可以被consumer消費時，也是通過BufferQueueCore來通知到到consumer的。

Producer通常是指應用程序，應用程序不斷刷新UI，把產生的顯示數據寫到buffer中，當Producer需要一塊buffer時，先向bufferQueue發起dequeue申請，然后才能對制定的緩沖區進行填充操作，當填充完成后，通過調用queueBuffer把這個buffer入隊到Bufferqueue中，由BufferQueuecore通知consumer有可以別消費的buffer了。

具體怎么通知到consumer的，還要介紹一個類ConsumerListener，介紹了這個類的幾個主要接口，就知道是怎么通知到consumer的了。

class ConsumerListener : public virtual RefBase { //當一幀對消費者來說可用時就會調用這個函數，virtual void onFrameAvailable(const BufferItem& item) = 0; /* Asynchronous */ //這個函數會去通知consumer，BufferQueue已經釋放了一個或多個GraphicBuffers的引用，consumer應該調用getReleasedBuffers去檢索這個buffer列表。virtual void onBuffersReleased() = 0; }

2），BufferQueue緩沖區的分配。

分析緩沖區的分配，就是分析BufferSlot數組中的指針mGraphicBuffer的空間分配。這個指針一開始是null，下面看什么情況下為mSlots數組中的一個slot分配實際空間。

整個需求的起點是Producer對buffer的dequeueBuffer，所以從分析這個函數開始：

BufferQueueProducer.cpp status_t BufferQueueProducer::dequeueBuffer(int *outSlot,sp<android::Fence> *outFence, uint32_t width,uint32_t height, QueueBufferOutput *output) @BufferQueueProducer.cpp{ //step1，這個while循環，查找一個可用的slot，具體是通過 waitForFreeSlotThenRelock函數實現，也就是found的有效值。int found = BufferItem::INVALID_BUFFER_SLOT;while (found == BufferItem::INVALID_BUFFER_SLOT) {status_t status = waitForFreeSlotThenRelock(FreeSlotCaller::Dequeue,&found); //如果不允許分配新的buffers， waitForFreeSlotThenRelock還必須返回一個包含buffer的slot，如果這個buffer需要充分配才能滿足要求，就要先把它free了，然后嘗試再獲取一個。const sp<GraphicBuffer>& buffer(mSlots[found].mGraphicBuffer);if (!mCore->mAllowAllocation) {if (buffer->needsReallocation(width, height, format, usage)) {mCore->mFreeSlots.insert(found);mCore->clearBufferSlotLocked(found);found = BufferItem::INVALID_BUFFER_SLOT;continue;}}} //step2，成功找到slot序號，接下來對這個bufferslot對象做初始化。還要判斷要不要為這個slot重新分配空間。*outSlot = found;mSlots[found].mBufferState.dequeue();if ((buffer == NULL) ||buffer->needsReallocation(width, height, format, usage)){mSlots[found].mAcquireCalled = false;mSlots[found].mGraphicBuffer = NULL;mSlots[found].mFence = Fence::NO_FENCE;mCore->mIsAllocating = true;returnFlags |= BUFFER_NEEDS_REALLOCATION;} //step3，上一步的判斷結果需要重新分配空間，調用 createGraphicBuffer分配空間。if (returnFlags & BUFFER_NEEDS_REALLOCATION) {sp<GraphicBuffer> graphicBuffer(mCore->mAllocator->createGraphicBuffer(width, height, format, usage,{mConsumerName.string(), mConsumerName.size()} , &error)); //分配的空間，賦值給了slot，這里的mSlots實質是BufferQueueCore中的變量。mSlots[*outSlot].mGraphicBuffer = graphicBuffer;} }

對其中關鍵步驟做詳細分析：

step1，怎么找到一個可用的slot。found指的是這個Bufferslot在mSlots數組中的序號。

status_t BufferQueueProducer::waitForFreeSlotThenRelock(FreeSlotCaller caller,int* found) const {bool tryAgain = true;while (tryAgain) { // mActiveBuffers這個集合中包含所有非free的buffer。然后分別統計dequeued的個數，acquired的個數。for (int s : mCore->mActiveBuffers) {if (mSlots[s].mBufferState.isDequeued()) {++dequeuedCount;}if (mSlots[s].mBufferState.isAcquired()) {++acquiredCount;}} //不允許Producersdequeue的數量的超過 mMaxDequeuedBufferCount，這個判斷只在buffer已經被queued的情況下。 mMaxDequeuedBufferCount是Producer一次可以dequeue的buffers的數量，默認是1，可以通過setMaxDequeuedBufferCount來修改。if (mCore->mBufferHasBeenQueued &&dequeuedCount >= mCore->mMaxDequeuedBufferCount) {return INVALID_OPERATION;} //如果在shared buffer mode，并且有一個shared buffer存在，就返回這個slot。if (mCore->mSharedBufferMode && mCore->mSharedBufferSlot !=BufferQueueCore::INVALID_BUFFER_SLOT) {*found = mCore->mSharedBufferSlot;}else { //slot的獲取，主要來自兩個集合，mFreeSlots和mFreeBuffers， //mFreeSlots包含的是所有狀態是free,并且沒有attached的slots， //mFreeBuffers包含所有狀態是free，但是已經attached的slots。if (caller == FreeSlotCaller::Dequeue) { //如果調用來自與dequeue，優先選擇mFreeBuffers中的。int slot = getFreeBufferLocked();if (slot != BufferQueueCore::INVALID_BUFFER_SLOT) {*found = slot;}else{*found = getFreeSlotLocked();}}else{ //如果調用來自于attache，優先選擇mFreeSlots中的。int slot = getFreeSlotLocked();if (slot != BufferQueueCore::INVALID_BUFFER_SLOT) {*found = slot;}else{*found = getFreeBufferLocked();}}} //如果沒有找到符合要求的buffer，或者queue的buffers還有太多沒有完成，就要等待這個buffer被acquired或者released，或者修改最大的buffer數量。這里使用條件變量mDequeueCondition進入wait，當有buffer被釋放時，這個條件就會滿足，然后繼續查找。if (tryAgain) {mCore->mDequeueCondition.wait(mCore->mMutex);}}//while(tryAgain)return NO_ERROR; }

Step2，找到可用的slot，還要判斷是否要重新分配空間，即needsReallocation，如果buffer的屬性跟要求的屬性不符（主要指寬，高，格式，usage），就要重新分配，最后的返回值會加上returnFlags|= BUFFER_NEEDS_REALLOCATION;標記。

Step3，調用IGraphicBufferAlloc的方法createGraphicBuffer方法分配GraphicBuffer。IGraphicBufferAlloc對應的服務端的實現是GraphicBufferAlloc.cpp，所以這個方法的實現就到了GraphicBufferAlloc.cpp中，這里new了一個GraphicBuffer，這個GraphicBuffer會賦值給BufferQueueCore中的變量mSlots中的slot的mGraphicBuffer。

sp<GraphicBuffer> GraphicBufferAlloc::createGraphicBuffer(uint32_t width,uint32_t height, PixelFormat format, uint32_t usage,std::string requestorName, status_t* error) @GraphicBufferAlloc.cpp{sp<GraphicBuffer> graphicBuffer(new GraphicBuffer(width, height, format, usage, std::move(requestorName)));status_t err = graphicBuffer->initCheck();*error = err;if (err != 0 || graphicBuffer->handle == 0) {if (err == NO_MEMORY) {GraphicBuffer::dumpAllocationsToSystemLog();}return 0;}return graphicBuffer; }

BufferQueueProducer.cpp中的dequeueBuffer的源頭是在surface中調用的dequeueBuffer，所以BufferQueueProducer.cpp這邊執行完會返回到Surface.cpp中，

int Surface::dequeueBuffer(android_native_buffer_t** buffer, int* fenceFd) @Surface.cpp{ //BufferQueueProducer.cpp的dequeueBuffer是從這里開始的。status_t result = mGraphicBufferProducer->dequeueBuffer(&buf, &fence,reqWidth, reqHeight, reqFormat, reqUsage); //如果返回值帶有BUFFER_NEEDS_REALLOCATION，還要調用 requestBuffer。if ((result & IGraphicBufferProducer::BUFFER_NEEDS_REALLOCATION) || gbuf == 0) {result = mGraphicBufferProducer->requestBuffer(buf, &gbuf);} }

調用requestBuffer是獲取最新的buffer地址，BufferQueueProducer中分配的buffer是在服務端進程空間的，而surface需要的buffer是要在客戶端進程，也就是應用進程空間使用的，這兩塊buffer應該指向同一塊物理內存，怎么實現讓兩塊buffer指向同一塊物理內存的，這就是requestbuffer的作用。

//這個方法是BpGraphicBufferProducer中的方法：

virtual status_t requestBuffer(int bufferIdx, sp<GraphicBuffer>* buf) @IGraphicBufferProducer.cpp{Parcel data, reply; //只傳了在mSlots中的序號 bufferIdx，第二個參數* buf實際是一個出參。data.writeInt32(bufferIdx); //開始跨進程操作。status_t result =remote()->transact(REQUEST_BUFFER, data, &reply); //讀取服務端返回的信息，在執行跨進程操作時，client端會被掛起，等服務端處理完成返回結果時，在喚醒client繼續執行。bool nonNull = reply.readInt32();if (nonNull) { //這里生成一個GraphicBuffer實例，實際是一個空殼，要通過服務端的返回值來填充。*buf = new GraphicBuffer(); //使用服務端的返回的結果填充**buf ，這個**buf具體指的什么？從surface.cpp傳入的參數說起： //sp<GraphicBuffer>& gbuf(mSlots[buf].buffer);這個gbuf 是一個指向 mSlots[buf].buffer的引用，//傳入requestBuffer中的實參是&gbuf，也就是說*buf指針指向的是 gbuf 的地址，所以**buf指向的就是 gbuf代表的內容，也就是 mSlots[buf].buffer。result = reply.read(**buf);}result = reply.readInt32(); }

相應client請求的代碼如下：

status_t BnGraphicBufferProducer::onTransact(uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags){switch(code) { //匹配請求的業務碼 REQUEST_BUFFER。case REQUEST_BUFFER: { //讀取要處理的slot序號。int bufferIdx = data.readInt32();sp<GraphicBuffer> buffer;int result = requestBuffer(bufferIdx, &buffer); //寫入本地端是否成功獲取到了對應的GraphicBuffer，這個GraphicBuffer就是dequeuebuffer中申請//的，也即是BufferQueueCore中的mSlots[slot].mGraphicBuffer。reply->writeInt32(buffer != 0);if (buffer != 0) { //把 mGraphicBuffer寫入reply，等待客戶端讀取。reply->write(*buffer);}reply->writeInt32(result);return NO_ERROR;}} }

上面的實現中，清晰的描述了一個怎樣跨進程傳遞一個對象。

能夠通過Binder跨進程傳遞的對象，在java層的通常要繼承Parcelable，如Bundle.java，需要實現的接口是writeToParcel，readFromParcel；

在native層通常要繼承Flattenable，如這里的GraphicBuffer.cpp，需要實現的接口是flatten，unflatten。

只要看下GraphicBuffer的flatten，unflatten的函數實現，就可以清楚客戶端、服務端的兩塊buffer是不是指向的同一塊物理空間了。

status_t GraphicBuffer::flatten(void*& buffer, size_t& size, int*& fds, size_t& count) const @GraphicBuffer.cpp{int32_t* buf = static_cast<int32_t*>(buffer); //handle的類型是buffer_handle_t* handle，它是在生成GraphicBuffer實例時，//由GraphicBufferAllocator在申請真實的物理內存時賦值的，代表了代表了一塊共享緩沖區的句柄。if (handle) { //寫入緩沖區相關的數據，client端也會按相同的格式讀取。buf[9] = handle->numFds;buf[10] = handle->numInts;memcpy(fds, handle->data,static_cast<size_t>(handle->numFds) * sizeof(int));memcpy(&buf[11], handle->data + handle->numFds,static_cast<size_t>(handle->numInts) * sizeof(int));} }
status_t GraphicBuffer::unflatten(void const*& buffer, size_t& size, int const*& fds, size_t& count) @GraphicBuffer.cpp{const size_t numFds = static_cast<size_t>(buf[9]);const size_t numInts = static_cast<size_t>(buf[10]);if (numFds || numInts) { //通過生成一個本地層 native_handle實例，把相關的數據復制過來。這塊物理空間跟BufferQueueCore中指向的物理空間是一致的。這就實現了client和服務端之間緩沖區的共享。native_handle* h = native_handle_create(static_cast<int>(numFds), static_cast<int>(numInts));memcpy(h->data, fds, numFds * sizeof(int));memcpy(h->data + numFds, &buf[11], numInts * sizeof(int));} }

在surface執行dequeuebuffer的過程中，如果需要重新分配空間，就要調用requestbuffer就是來更新client端mSlots中相應的緩沖區信息的。這樣就保證了Surface和bufferQueuecore之前在數據緩沖區上的一致。

3)應用程序跟BufferQueue的關系。

應用程序不會直接使用BufferQueue，接下來分析應用程序跟bufferQueue之間怎么配合完成圖形繪制的。

分析這個過程需要一個切入點，可以從一個常見的應用程序的啟動入手，經過ViewrootImpl.java的setView，到WindowManagerService.java的relayoutWindow，然后轉到createSurface的分析。這個過程要從java層進過jni到本地層相對繁瑣，不利于直觀跟BufferQueue的關系。所以借助系統的一段本地層的測試代碼來分析,為什么要用這段代碼？我們知道surfaceflinger是借助于opengles來完成繪圖的，很多應用程序也是借助于opengles來完成UI顯示的，比如圖庫的圖片展示，相機的預覽界面等，當然也有應用程序是借助于skia這個圖形庫。下面這段代碼不僅展示了應用程序跟BufferQueue的通信過程，還展示了opengles和egl的使用流程。

frameworks/native/libs/gui/tests/GLTest.cpp void GLTest::SetUp() { //獲取默認的物理屏幕。mEglDisplay = eglGetDisplay(EGL_DEFAULT_DISPLAY); //初始化。eglInitialize(mEglDisplay, &majorVersion, &minorVersion); //選取最佳的config。eglChooseConfig(mEglDisplay, getConfigAttribs(), &mGlConfig, 1, &numConfigs); //生成一個SurfaceComposerClient實例，它是應用程序與surfaceflinger之間的通信橋梁，不過SurfaceComposerClient只是一個封裝，實質是通過內部的ISurfaceComposerClient來執行的，ISurfaceComposerClient對應的服務端實現是Client。mComposerClient = new SurfaceComposerClient;mComposerClient→initCheck(); //生成一個surface，surface是由surfaceControl來管理的，所以這里返回的是SurfaceControl。mSurfaceControl = mComposerClient->createSurface(String8("Test Surface"), getSurfaceWidth(), getSurfaceHeight(),PIXEL_FORMAT_RGB_888, 0); //設置layer的層級，層級越大越靠近用戶。mSurfaceControl->setLayer(0x7FFFFFFF);mSurfaceControl→show(); //從surfacecontrol中取出surface，得到了egl需要的本地窗口。sp<ANativeWindow> window = mSurfaceControl→getSurface(); //通過本地窗口window創建surface。mEglSurface = createWindowSurface(mEglDisplay, mGlConfig, window); //創建、設置當前context環境。mEglContext = eglCreateContext(mEglDisplay, mGlConfig, EGL_NO_CONTEXT,getContextAttribs());eglMakeCurrent(mEglDisplay, mEglSurface, mEglSurface,mEglContext)); }

SurfaceComposerClient是一個封裝，具體功能實現是通過其內部的ISurfaceComposerClient來實現的，而ISurfaceComposerClient對應服務端的實現是Client.cpp，所以上面的createSurface的實現就在Client中。這里涉及ipc，具體細節就不列出代碼了。

SurfaceComposerClient.cpp

sp<SurfaceControl> SurfaceComposerClient::createSurface(const String8& name,uint32_t w,uint32_t h,PixelFormat format,uint32_t flags)@SurfaceComposerClient.cpp{sp<IBinder> handle;sp<IGraphicBufferProducer> gbp; //調用服務端的實現，實質是創建了一個layer，通過這個layer獲取 IGraphicBufferProducer。status_t err = mClient->createSurface(name, w, h, format, flags,&handle, &gbp); //生成一個 SurfaceControl，由他管理surface。sur = new SurfaceControl(this, handle, gbp);return sur; }

接著看服務端的實現，createSurface這個方法只能在GL線程中調用，這樣它才能范文GL的上下文環境。

Client.cpp

status_t Client::createSurface(const String8& name,uint32_t w, uint32_t h, PixelFormat format, uint32_t flags,sp<IBinder>* handle,sp<IGraphicBufferProducer>* gbp){class MessageCreateLayer : public MessageBase {SurfaceFlinger* flinger; //這個client表明，這個消息來自于那個client，Client* client; //與這個layer對應的handle和gbp。sp<IBinder>* handle;sp<IGraphicBufferProducer>* gbp;status_t result;const String8& name;uint32_t w, h;PixelFormat format;uint32_t flags;virtual bool handler() { //這里是由surfaceFlinger來執行操作。result = flinger->createLayer(name, client, w, h, format, flags,handle, gbp);return true;}} //把請求通過一個同步函數把msg放入隊列，等到有結果再返回。sp<MessageBase> msg = new MessageCreateLayer(mFlinger.get(),name, this, w, h, format, flags, handle, gbp);mFlinger->postMessageSync(msg);return static_cast<MessageCreateLayer*>( msg.get() )->getResult(); }
SurfaceFlinger.cpp status_t SurfaceFlinger::createLayer(const String8& name,const sp<Client>& client,uint32_t w, uint32_t h, PixelFormat format, uint32_t flags,sp<IBinder>* handle, sp<IGraphicBufferProducer>* gbp)@SurfaceFlinger.cpp{sp<Layer> layer;switch (flags & ISurfaceComposerClient::eFXSurfaceMask) { //根據flag，創建不同的layer，這里是創建普通的layer，代表了一個畫面。case IsurfaceComposerClient::eFXSurfaceNormal:result = createNormalLayer(client,name, w, h, flags, format,handle, gbp, &layer);break;} //將layer，gbp添加到全局的管理中。result = addClientLayer(client, *handle, *gbp, layer); }
SurfaceFlinger.cpp status_t SurfaceFlinger::createNormalLayer(const sp<Client>& client,const String8& name, uint32_t w, uint32_t h, uint32_t flags, PixelFormat& format,sp<IBinder>* handle, sp<IGraphicBufferProducer>* gbp, sp<Layer>* outLayer)@SurfaceFlinger.cpp{ //創建一個layer，同時給他設置緩沖區。*outLayer = new Layer(this, client, name, w, h, flags);status_t err = (*outLayer)->setBuffers(w, h, format, flags); //通過layer獲取IGraphicBufferProducer。*handle = (*outLayer)→getHandle();*gbp = (*outLayer)->getProducer(); }

//addClientLayer函數的實現。

status_t SurfaceFlinger::addClientLayer(const sp<Client>& client,const sp<IBinder>& handle,const sp<IGraphicBufferProducer>& gbc,const sp<Layer>& lbc)@SurfaceFlinger.cpp{ //把layer添加到當前state的列表中。把gbc添加到全局變量中。mCurrentState.layersSortedByZ.add(lbc);mGraphicBufferProducerList.add(IInterface::asBinder(gbc)); //讓layer與client產生關聯，也就是添加到client的mLayers成員變量中。client->attachLayer(handle, lbc); }

//再回頭看下*handle= (*outLayer)→getHandle();其中的handle是什么類型，又起了什么作用呢？

Layer.cpp

//創建了一個handle對象，并傳入的surfaceflinger。

sp<IBinder> Layer::getHandle() @Layer.cpp{return new Handle(mFlinger, this); }

//這個handle只是傳給client端的一個BBbinder，當客戶端釋放了這個引用時，會調用其析構函數，那么它的析構函數做了什么事情呢？Handle本身沒寫析構函數，所以要做的事情就在其父類LayerCleaner的析構函數中。

class Layer::Handle : public BBinder, public LayerCleaner {Handle(const sp<SurfaceFlinger>& flinger, const sp<Layer>& layer): LayerCleaner(flinger, layer), owner(layer) {} };

//LayerCleaner的析構函數，調用了surfaceflinger的onLayerDestroyed，把layer從surfaceflinger的全局變量mCurrentState.layersSortedByZ中移除。

Layer::LayerCleaner::~LayerCleaner() {mFlinger->onLayerDestroyed(mLayer); }

//Layer中很多變量的實例化，都是在onFirstRef中完成的，當Layer實例第一次被引用時會執行onFirstRef函數。

Layer.cpp void Layer::onFirstRef() {sp<IGraphicBufferProducer> producer;sp<IGraphicBufferConsumer> consumer; //通過BufferQueue創建BufferQueueProducer，BufferQueueConsumer，這樣標識了 IGraphicBufferProducer對應的服務端是BufferQueueProducer， IGraphicBufferConsumer對應的服務端是 BufferQueueConsumer，同時BufferQueueProducer、 BufferQueueConsumer的構造函數中都有一個BufferQueueCore實例，生成者，消費者的對緩沖區的操作都會經過BufferQueueCore。BufferQueue::createBufferQueue(&producer, &consumer); //這里返回給client端的并不是 IGraphicBufferProducer，而是對它的封裝類 MonitoredProducer， //MonitoredProducer并沒有增加新的功能，只是在 IGraphicBufferProducer被銷毀時，通知 // Surfaceflinger做些操作。mProducer = new MonitoredProducer(producer, mFlinger);mSurfaceFlingerConsumer = new SurfaceFlingerConsumer(consumer, mTextureName,this); }

//我們只關注MonitoredProducer的構造函數，看在IGraphicBufferProducer被銷毀時，它要做什么。

MonitoredProducer.cpp

MonitoredProducer::~MonitoredProducer() @MonitoredProducer.cpp{ //這里使用了跟Client.cpp中調用surfaceflinger創建layer類似的方式，不同的是這里是異步的消息機制。class MessageCleanUpList : public MessageBase {virtual bool handler() { //把IGraphicBufferProducer從surfaceflinger的列表中刪除，這個操作是異步執行的，因為不知道會從哪里調用這個析構函數。還記得 mProducer是什么時候添加到這個列表中的嗎？是在surfaceflinger的createLayer中，當創建一個layer之后，調用addClientLayer來添加的。mFlinger->mGraphicBufferProducerList.remove(mProducer);}}mFlinger->postMessageAsync(new MessageCleanUpList(mFlinger, asBinder(this))); }

在Layer中還有一個重要的變量SurfaceFlingerConsumer。

SurfaceFlingerConsumer是GLConsumer的簡單的包裝類，把IGraphicBufferConsumer實例傳給了GLConsumer。

SurfaceFlingerConsumer.cpp class SurfaceFlingerConsumer : public GLConsumer {SurfaceFlingerConsumer(const sp<IGraphicBufferConsumer>& consumer,uint32_t tex, const Layer* layer): GLConsumer(consumer, tex, GLConsumer::TEXTURE_EXTERNAL, false, false),mPrevReleaseFence(Fence::NO_FENCE), mLayer(layer){} }

class GLConsumer :public ConsumerBase {}

class ConsumerBase :public virtual RefBase,protected ConsumerListener {}

GLConsumer有繼承自ConsumerBase，間接繼承了ConsumerListener。

接下來逐層分析逐個繼承關系。

GLConsumer會消費來自BufferQueue的緩沖區或者叫圖形數據，并把他們轉做texture為opengl使用。一個典型的使用方式是使用所需要的選項設置GLConsumer，然后當有一幀需要時，調用updateTexImage，這個函數會獲取最近queued的buffer，然后綁定這個buffer到GLtexture，如果這一幀是可用的，texture會被更新，如果不可用，前一幀的內容會被保留。

ConsumerBase是BufferQueue消費者的基類，它處理一些通用任務，比如到BufferQueue的連接，buffer池的管理，其中的成員變量sp<IGraphicBufferConsumer>mConsumer;就是SurfaceFlingerConsumer傳過來的，ConsumerBase是通過IGraphicBufferConsumer對象來對BufferQueue執行操作的。

簡單做個總結：

1）應用程序通過BufferQueue執行繪圖，surfaceflinger會把系統中所有應用程序最終的繪圖結果進行混合，然后送到物理屏幕顯示。應用程序跟surfaceflinger之間的通信橋梁是IsurfaceComposrClient。

這個類被封裝在SurfaceComposerClient中。

2）應用程序通過SurfaceComposerClient調用CreateSurface的過程中，除了得到IGraphicBufferProducer實例外，還創建了一個layer。把控制這個layer的handle，IGraphicBufferProducer對象，連同SurfaceComposerClient自身都保存在應用端的Surfacecontrol中。

3）Surface，應用程序通過Surfacecontrol的getSurface獲取，其內部持有IGraphicBufferProducer對象，即BufferQueueProducer的實現接口。如果egl想通過Surface這個本地窗口完成某個功能，Surface實際上是利用IGraphicBufferProducer取得遠程端的服務，完成egl的請求。

4）應用程序跟layer應該是一對多的關系，因為createSurface是可以被調用多次的，并且，一個應用程序申請的多個layer可以通過addClientLayer添加到一個全局變量mLayers中。應用程序申請的layer，一方面要記錄都各個Client的內部變量mLayers中，另一方面還要告知SurfaceFlinger，這個操作也是在addClientLayer函數中完成的，即把layer添加到全局變量mCurrentState.layerSortByZ，Surfaceflinger會對這個列表中的所有layer排序，排序的結果直接影響了屏幕顯示的畫面。

5）每個layer對應一個BufferQueue，所以一個應用程序可能對應多個BufferQueue。layer并沒有直接持有BufferQueue對象，而是通過其內部的IGraphicBufferProducer，mSurfaceFlingerConsumer來管理。

總結

以上是生活随笔為你收集整理的Android 7.1 GUI系统-BufferQueue 的管理（三）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。