深入浅出Android BufferQueue
對業務開發來說,無法接觸到BufferQueue,甚至不知道BufferQueue是什么東西。對系統來說,BufferQueue是很重要的傳遞數據的組件,Android顯示系統依賴于BufferQueue,只要顯示內容到“屏幕”(此處指抽象的屏幕,有時候還可以包含編碼器),就一定需要用到BufferQueue,可以說在顯示/播放器相關的領悟中,BufferQueue無處不在。即使直接調用Opengl?ES來繪制,底層依然需要BufferQueue才能顯示到屏幕上。
弄明白BufferQueue,不僅可以增強對Android系統的了解,還可以弄明白/排查相關的問題,如為什么Mediacodec調用dequeueBuffer老是返回-1?為什么普通View的draw方法直接繪制內容即可,SurfaceView在draw完畢后還需要unlockCanvasAndPost?
注:本文分析的代碼來自于Android6.0.1。
BufferQueue是Android顯示系統的核心,它的設計哲學是生產者-消費者模型,只要往BufferQueue中填充數據,則認為是生產者,只要從BufferQueue中獲取數據,則認為是消費者。有時候同一個類,在不同的場景下既可能是生產者也有可能是消費者。如SurfaceFlinger,在合成并顯示UI內容時,UI元素作為生產者生產內容,SurfaceFlinger作為消費者消費這些內容。而在截屏時,SurfaceFlinger又作為生產者將當前合成顯示的UI內容填充到另一個BufferQueue,截屏應用此時作為消費者從BufferQueue中獲取數據并生產截圖。
以下是Android官網對其的介紹:
以下是常見的BufferQueue使用步驟:
初始化一個BufferQueue
圖形數據的生產者通過BufferQueue申請一塊GraphicBuffer,對應圖中的dequeueBuffer方法
申請到GraphicBuffer后,獲取GraphicBuffer,通過函數requestBuffer獲取
獲取到GraphicBuffer后,通過各種形式往GraphicBuffer中填充圖形數據后,然后將GraphicBuffer入隊到BufferQueue中,對應上圖中的queueBuffer方法
在新的GraphicBuffer入隊BufferQueue時,BufferQueue會通過回調通知圖形數據的消費者,有新的圖形數據被生產出來了
然后消費者從BufferQueue中出隊一個GraphicBuffer,對應圖中的acquireBuffer方法
待消費者消費完圖形數據后,將空的GraphicBuffer還給BufferQueue以便重復利用,此時對應上圖中的releaseBuffer方法
此時BufferQueue再通過回調通知圖形數據的生產者有空的GraphicBuffer了,圖形數據的生產者又可以從BufferQueue中獲取一個空的GraphicBuffer來填充數據
一直循環2-8步驟,這樣就有條不紊的完成了圖形數據的生產-消費
當然圖形數據的生產者可以不用等待BufferQueue的回調再生產數據,而是一直生產數據然后入隊到BufferQueue,直到BufferQueue滿為止。圖形數據的消費者也可以不用等BufferQueue的回調通知,每次都從BufferQueue中嘗試獲取數據,獲取失敗則嘗試,只是這樣效率比較低,需要不斷的輪訓BufferQueue(因為BufferQueue有同步阻塞和非同步阻塞兩種機種,在非同步阻塞機制下獲取數據失敗不會阻塞該線程直到有數據才喚醒該線程,而是直接返回-1)。
同時使用BufferQueue的生產者和消費者往往處在不同的進程,BufferQueue內部使用共享內存和Binder在不同的進程傳遞數據,減少數據拷貝提高效率。
和BufferQueue有關的幾個類分別是:
BufferBufferCore:BufferQueue的實際實現
BufferSlot:用來存儲GraphicBuffer
BufferState:表示GraphicBuffer的狀態
IGraphicBufferProducer:BufferQueue的生產者接口,實現類是BufferQueueProducer
IGraphicBufferConsumer:BufferQueue的消費者接口,實現類是BufferQueueConsumer
GraphicBuffer:表示一個Buffer,可以填充圖像數據
ANativeWindow_Buffer:GraphicBuffer的父類
ConsumerBase:實現了ConsumerListener接口,在數據入隊列時會被調用到,用來通知消費者
BufferQueue中用BufferSlot來存儲GraphicBuffer,使用數組來存儲一系列BufferSlot,數組默認大小為64。
GraphicBuffer用BufferState來表示其狀態,有以下狀態:
FREE:表示該Buffer沒有被生產者-消費者所使用,該Buffer的所有權屬于BufferQueue
DEQUEUED:表示該Buffer被生產者獲取了,該Buffer的所有權屬于生產者
QUEUED:表示該Buffer被生產者填充了數據,并且入隊到BufferQueue了,該Buffer的所有權屬于BufferQueue
ACQUIRED:表示該Buffer被消費者獲取了,該Buffer的所有權屬于消費者
為什么需要這些狀態呢??假設不需要這些狀態,實現一個簡單的BufferQueue,假設是如下實現:
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內部數據結構
核心數據結構如下:
在BufferQueueCore初始化時,由于此時隊列中沒有入隊任何數據,按照上面的介紹,此時mFreeSlots應該包含所有的Slot,元素大小和mSlots一致,初始化代碼如下:
2.2 生產者dequeueBuffer
當生產者可以生產圖形數據時,首先向BufferQueue中申請一塊GraphicBuffer。調用函數是BufferQueueProducer.dequeueBuffer,如果當前BufferQueue中有可用的GraphicBuffer,則返回其對用的索引,如果不存在,則返回-1,代碼在BufferQueueProducer,流程如下:
//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的流程如下:
//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分為兩種:
從mFreeBuffers中獲取到的,mFreeBuffers中的元素關聯了GraphicBuffer,直接可用
從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。流程如下:
// 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的流程如下:
// 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的主要步驟如下:
將Buffer狀態扭轉成QUEUED,此步完成了Buffer的狀態由DEQUEUED到QUEUED的過程
將Buffer入隊到BufferQueueCore的mQueue隊列中
回調frameAvailableListener,告知消費者有數據入隊,可以來消費數據了,frameAvailableListener是消費者注冊的回調
小結queueBuffer:將Slot的狀態扭轉成QUEUED,并添加到mQueue中,最后通知消費者有數據入隊。
2.5 消費者acquireBuffer
在消費者接收到onFrameAvailable回調時或者消費者主動想要消費數據,調用acquireBuffer嘗試向BufferQueueCore獲取一個數據以供消費。消費者的代碼在BufferQueueConsumer中,acquireBuffer流程如下:
//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的主要步驟如下:
從mQueue隊列中取出并移除一個元素
改變Slot對應的狀態為ACQUIRED
如果有丟幀邏輯,回調告知生產者有數據被消費,生產者可以準備生產數據了
小結acquireBuffer:將Slot的狀態扭轉成ACQUIRED,并從mQueue中移除,最后通知生產者有數據出隊。
2.6 消費者releaseBuffer
消費者獲取到Slot后開始消費數據(典型的消費如SurfaceFlinger的UI合成),消費完畢后,需要告知BufferQueueCore這個Slot被消費者消費完畢了,可以給生產者重新生產數據,releaseBuffer流程如下:
//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的主要步驟如下:
將Slot的狀態扭轉為FREE
將被消費的Slot添加到mFreeBuffers供后續的生產者dequeueBuffer使用
回調告知生產者有數據被消費,生產者可以準備生產數據了
小結releaseBuffer:將Slot的狀態扭轉成FREE,并添加到BufferQueueCore?mFreeBuffers隊列中,最后通知生產者有數據出隊。
總結下狀態變化的過程:
上面主要介紹了BufferQueue的設計思想和內部實現。
下面將繼續介紹BufferQueue,著重介紹Android中對于BufferQueue的常用封裝,以及SurfaceView中使用BufferQueue的具體實現。
在實際應用中,除了直接使用BuferQueue外,更多的是使用Surface/SurfaceTexture,其對BufferQueue做了包裝,方便業務更方便的使用BufferQueue。Surface作為BufferQueue的生產者,SurfaceTexture作為BufferQueue的消費者。
3.1 Surface
Surface的構造函數如下:
構造函數需要傳入一個生產者的引用,和BufferQueue的交互均有這個生產者的引用來完成。dequeueBuffer的流程如下:
// 1. 調用mGraphicBufferProducer的dequeueBuffer方法,嘗試獲取一個Slot索引 int buf = -1; sp<Fence> fence; status_t result = mGraphicBufferProducer->dequeueBuffer(&buf, &fence, swapIntervalZero, reqWidth, reqHeight, reqFormat, reqUsage);
if (result < 0) { ALOGV("dequeueBuffer:?IGraphicBufferProducer::dequeueBuffer(%d,?%d,?%d,?%d,?%d)" "failed:?%d", swapIntervalZero, reqWidth, reqHeight, reqFormat, reqUsage, result); return result; } // 2. 調用mGraphicBufferProducer的requestBuffer方法,嘗試獲取Slot sp<GraphicBuffer>& gbuf(mSlots[buf].buffer); if?((result?&?IGraphicBufferProducer::BUFFER_NEEDS_REALLOCATION)?||?gbuf?==?0) { result = mGraphicBufferProducer->requestBuffer(buf, &gbuf); if?(result?!=?NO_ERROR)?{ ALOGE("dequeueBuffer:?IGraphicBufferProducer::requestBuffer?failed:?%d", result); mGraphicBufferProducer->cancelBuffer(buf, fence); return result; } }
// 3. 返回GraphicBuffer *buffer = gbuf.get();}
queueBuffer也是如下,流程如下:
????IGraphicBufferProducer::QueueBufferOutput?output;????IGraphicBufferProducer::QueueBufferInput input(timestamp, isAutoTimestamp, mDataSpace, crop, mScalingMode, mTransform ^ mStickyTransform, mSwapIntervalZero, fence, mStickyTransform); // 1. 直接調用mGraphicBufferProducer的queueBuffer方法即可 status_t err = mGraphicBufferProducer->queueBuffer(i, input, &output); if?(err?!=?OK)??{ ALOGE("queueBuffer:?error?queuing?buffer?to?SurfaceTexture,?%d", err); }}
Surface還提供了lock函數,用來支持雙緩沖,內部也是調用dequeueBuffer方法獲取最新的Buffer:
ANativeWindowBuffer* out; int fenceFd = -1; //1. 獲取實際Buffer status_t err = dequeueBuffer(&out, &fenceFd);
//2. 處理雙緩沖 if (canCopyBack) { // copy the area that is invalid and not repainted this round const Region copyback(mDirtyRegion.subtract(newDirtyRegion)); if?(!copyback.isEmpty()) copyBlt(backBuffer, frontBuffer, copyback); }}
Surface也提供了unlockAndPost方法,將數據給到BufferQueue:
int fd = -1; status_t err = mLockedBuffer->unlockAsync(&fd); ALOGE_IF(err, "failed unlocking buffer (%p)", mLockedBuffer->handle);
//1. 將生產好的數據給到BufferQueue err = queueBuffer(mLockedBuffer.get(), fd); ALOGE_IF(err, "queueBuffer (handle=%p) failed (%s)", mLockedBuffer->handle, strerror(-err));
mPostedBuffer = mLockedBuffer; mLockedBuffer = 0; return err;}
3.2 SurfaceTexture
SurfaceTexture作為BufferQueue的消費者,其初始化代碼如下:
sp<IGraphicBufferProducer> producer; sp<IGraphicBufferConsumer> consumer; //1. 創建一個BufferQueue????BufferQueue::createBufferQueue(&producer,?&consumer);
if (singleBufferMode) { consumer->disableAsyncBuffer(); consumer->setDefaultMaxBufferCount(1); }
//2. 創建一個消費者實例surfaceTexture sp<GLConsumer> surfaceTexture; if (isDetached) { surfaceTexture = new GLConsumer(consumer, GL_TEXTURE_EXTERNAL_OES, true, true); } else { surfaceTexture = new GLConsumer(consumer, texName, GL_TEXTURE_EXTERNAL_OES, true, true); }
//3. 將消費者實例和該BufferQueue對應的生產者保存到java層,這樣Surface構造時,就可以獲取到該BufferQueue對應的生產者了 SurfaceTexture_setSurfaceTexture(env, thiz, surfaceTexture); SurfaceTexture_setProducer(env, thiz, producer);
}
消費的方法是updateTexImage,流程如下:
GLConsumer的updateTextImage實現如下:
// Release the previous buffer. err = updateAndReleaseLocked(item); if?(err?!=?NO_ERROR)?{ glBindTexture(mTexTarget, mTexName); return err; }
}
acquireBufferLocked方法,最終走到了ConsumerBase的acquireBufferLocked方法。
return OK;}
同理,消費者消費數據的方法是releaseTexImage,最終也會走到BufferQueueConsumer的releaseBufferLocked方法,這里不再描述了。
上述介紹了BufferQueue的內部實現,以及常用的封裝類。接下來將介紹一個具體的實例。
Android中,SurfaceView作為系統提供的組件,因為可以在子線程中繪制提高性能,SurfaceView擁有自身的Surface,不需要和Activity的Surface共享,在SurfaceFlinger中,Activity的Surface和SurfaceView的Surface是平級且互相獨立的,可以獨立的進行合成。那我們來看一下SurfaceView是怎么使用BufferQueue的。
4.1 數據的生產過程
SurfaceView的Surface創建過程,這里不關注,有興趣的可以參考?android?SurfaceView繪制實現原理解析?這篇文章,我們主要關注其中與BufferQueue相關的繪制和顯示步驟。
使用SuerfaceView繪制偽碼如下:?
需要調用lockCanvas和unlockCanvasAndPost方法,這兩個方法的作用是什么呢?
先看下lockCanvas,調用流程是:
SurfaceHolder.lockCanvas
SurfaceHolder.internalLockCanvas
Surface.lockCanvas?
Surface.nativeLockCanvas?
nativeLockCanvas實現如下:
ANativeWindow_Buffer outBuffer; //1.?通過Surface::lock方法,獲取一個合適的Buffer status_t err = surface->lock(&outBuffer, dirtyRectPtr);
//2. 構造一個Bitmap,地址指向步驟1獲取的Buffer的地址,這樣在這個Bitmap上繪制的內容,直接繪制到了GraphicBuffer,如果GraphicBuffer的內存是SurfaceFlinger通過共享內存申請的,那么SurfaceFlinger就能直接看到繪制的圖形數據????SkImageInfo?info?=?SkImageInfo::Make(outBuffer.width,?outBuffer.height, convertPixelFormat(outBuffer.format), kPremul_SkAlphaType); SkBitmap bitmap; ssize_t bpr = outBuffer.stride * bytesPerPixel(outBuffer.format); bitmap.setInfo(info, bpr); if (outBuffer.width > 0 && outBuffer.height > 0) { bitmap.setPixels(outBuffer.bits); } else { // be safe with an empty bitmap. bitmap.setPixels(NULL); }
// 3. 將創建的Bitmap設置給Canvas,作為畫布????Canvas*?nativeCanvas?=?GraphicsJNI::getNativeCanvas(env,?canvasObj); nativeCanvas->setBitmap(bitmap);
}
從這里可以看到,nativeLockCanvas的步驟主要如下:
通過調用Surface::lock方法(內部也是調用dequeueBuffer和requestBuffer方法),獲取到一個GraphicBuffer
將步驟1獲取的GraphicBuffer構造成一個Bitmap,設置給Canvas
應用通過這個Canvas就可以繪制圖形了
在繪制圖形完成后,調用unlockCanvasAndPost方法,調用流程是:
SurfaceHolder.unlockCanvasAndPost
Surface.unlockCanvasAndPost
Surface.nativeUnlockCanvasAndPost
nativeUnlockCanvasAndPost?的實現如下:
// detach the canvas from the surface????Canvas*?nativeCanvas?=?GraphicsJNI::getNativeCanvas(env,?canvasObj); nativeCanvas->setBitmap(SkBitmap());
// 直接調用Surface的unlockAndPost方法,有上文可知unlockAndPost內部最終也會調用到qeueBuffer方法 status_t err = surface->unlockAndPost方法,有上文可知unlockAndPost內部最終也會調用到qeueBuffer方法(); if (err < 0) { doThrowIAE(env); }}
從注釋可以看到,這個方法,最終會調用到Surface的unlockAndPost方法方法,而該方法內部最終也會調用到BufferQueueProducer的queueBuffer方法。即完成了數據的生產和入隊。
4.2 數據的消費過程
SurfaceView繪制的數據,傳遞過BufferQueue后,最終由SurfaceFlinger進行合成消費。SurfaceFlinger的消費由SurfaceFlingerConsumer實現,流程如下:
//2. 消費完畢,釋放Slot err = updateAndReleaseLocked(item); if?(err?!=?NO_ERROR)?{ return err; }}
acquireBufferLocked的實現如下:
而updateAndReleaseLocked方法的流程如下:
本文對BufferQueue的內部實現做了介紹,結合入隊/出對說明了BufferQueue內部Slot的狀態扭轉過程,并介紹了常用的BufferQueue封裝類,最后介紹了一個基于BufferQueue的例子。
總結
以上是生活随笔為你收集整理的深入浅出Android BufferQueue的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 邀您参加 | K8S云原生技术开放日-北
- 下一篇: 腾讯机智在GTC 2019