Android5.1中surface和CpuConsumer下生產者和消費者間的處理架構簡述

Android5.1中surface和CpuConsumer下生產者和消費者間的處理架構簡述

 

前沿：

如果對SurfaceFlinger架構的工作原理較為熟悉的話，本文閱讀起來會相對容易些。之所以撰寫本文是因為在閱讀Camera HAL3的實現過程中大量的出現了類似與SurfaceFlinger的工作模式。本文將以CallbackProcessor模組的為入口，和大家進行分享。

 

 

1 Preview模組Surface與SurfaceFlinger的基礎知識

開發過Android Camera模組的人，基本都應該熟悉即時採集的視頻如果要顯示到手機屏上，對應的Framework層就應該構建一個Surface對象，這對所有Android版本都是通用的。該Surface本質是一個在APP端的ANativeWindow，是需要從SurfaceFlinger端的Gralloc模組擷取Buffer的，然後填充幀映像資料並送顯示的過程。詳細內容可以參考之前的專欄我心所向之Android4.2關於SurfaceFlinger相關的內容。

由於目前Android系統版本升級過快，在5.0以上的版本中SurfaceFlinger部分架構發生了變化(目前還沒有深入去研讀過)，瞭解到的是：

一方面他去掉了SurfaceTexture/SurfaceTextureClient等內容，增強了Surface的功能。

另一方面BufferQueue的使用也更加簡單與明了，Producer與Consumer的關係也更加明確，BufferQueue不再是以前的消費者角色，轉而成為ProducerBufferQueue和Consumer相互關聯的橋樑。

此外，如果你在深入的話，會瞭解到Gralloc模組中非framebuff的緩衝管理與共用不在是那個Ashmem匿名共用記憶體，而是出現了一種新的記憶體管理機制/dev/ION/，後面會和大家分享他部分的工作機制。

對於SurfaceFlinger與Camera Preview Surface而言，ANativeWindow作為兩者的共性負責管理和維護Buffer的建立與共用，在SurfaceFlinger端ANativeWindow建立buffer，在Surface側通過dequeuebuffer擷取buffer handle到本地進行共用，在填充完資料後通過queuebuffer告訴SurfaceFlinger當前buffer可用，這樣就形成了一個buffer生產與消費的關係，基於這種原理我們在Camera3Device中除了看到正常的Preview Surface之外還看到了其他模組中出現了Surface的建立。

 

2 CallbackProcessor::updateStream() 建立Surface

 

    sp producer;        sp consumer;        BufferQueue::createBufferQueue(&producer, &consumer);//BufferQueueProducer與BufferQueueConsumer        mCallbackConsumer = new CpuConsumer(consumer, kCallbackHeapCount);        mCallbackConsumer->setFrameAvailableListener(this);//當前CallbackProcessor繼承於CpuConsumer::FrameAvailableListener        mCallbackConsumer->setName(String8(Camera2Client::CallbackConsumer));        mCallbackWindow = new Surface(producer);//用於queue操作，這裡直接進行本地的buffer操作

上述代碼看上去很簡單，但就是他最終形成了一個bufferstream Product和Consumer的處理，這種方式也為Camera2Client下出現多路stream，多路資料流存在奠定了基礎，下面我們來簡單的描述他的工作機制。

 

 

2.1 BufferQueue::createBufferQueue

 

void BufferQueue::createBufferQueue(sp* outProducer,        sp* outConsumer,        const sp& allocator) {    LOG_ALWAYS_FATAL_IF(outProducer == NULL,            BufferQueue: outProducer must not be NULL);    LOG_ALWAYS_FATAL_IF(outConsumer == NULL,            BufferQueue: outConsumer must not be NULL);    sp core(new BufferQueueCore(allocator));    LOG_ALWAYS_FATAL_IF(core == NULL,            BufferQueue: failed to create BufferQueueCore);    sp producer(new BufferQueueProducer(core));//本地Bn的BufferQueueProducer    LOG_ALWAYS_FATAL_IF(producer == NULL,            BufferQueue: failed to create BufferQueueProducer);    sp consumer(new BufferQueueConsumer(core));//本地Bn的BufferQueueConsumer    LOG_ALWAYS_FATAL_IF(consumer == NULL,            BufferQueue: failed to create BufferQueueConsumer);    *outProducer = producer;    *outConsumer = consumer;}

當前Android5.1版本中可以看到BufferQueue已經改變了原先的角色，成為了一個用於建立一組操作BufferQueue的介面，實現了BufferQueueProducer與BufferQueueConsumer的建立。更本質說現在BufferQueue的工作量已經很小，基本由Surface來全盤操作。這裡通過BufferQueueCore會將BufferQueueProducer與BufferQueueConsumer綁定在一起，BufferQueueProducer可以說是替代了舊版本Android4.2中的SurfaceTextureClient，而BufferQueueConsumer則直接是SurfaceTexture以及BufferQueue的替代者。是在Android4.2.2中Surface和SurfaceFlinger間基於Bn/BpSurfaceTexture的多進程間buffer的queue操作機制。

 

2.2 CpuConsumer

在2.1中本質上是建立了BufferQueueProducer和BufferQueueConsumer，一般是成對出現。

這個CpuConsumer的地位本質是和SurfaceFlinger是一樣的，主要角色就是來處理已經帶有幀資料的buffer塊，所以整個的處理機制都是類型的，其中兩者均為繼承一個ConsumerBase類，用於實現對buffer塊的處理。

 

CpuConsumer::CpuConsumer(const sp& bq,        uint32_t maxLockedBuffers, bool controlledByApp) :    ConsumerBase(bq, controlledByApp),    mMaxLockedBuffers(maxLockedBuffers),    mCurrentLockedBuffers(0){    // Create tracking entries for locked buffers    mAcquiredBuffers.insertAt(0, maxLockedBuffers);    mConsumer->setConsumerUsageBits(GRALLOC_USAGE_SW_READ_OFTEN);    mConsumer->setMaxAcquiredBufferCount(maxLockedBuffers);}

 

 

2.3 mCallbackConsumer->setFrameAvailableListener(this)

這裡所完成的過程是需要Consumer去將一個listener加入到Productor端去，便於在幀資料可用時，可以監聽到並告知Consumer去做資料的處理，Product需要在資料可用時觸發這個listener的onFrameAvailable，從而讓資料從Productor轉到Consumer則，資料處理應該是在同一進程的而不是跨進程。

如果作為Consumer如CPUConsumer沒有使用setFrameAvailableListener將自己加入到listener中去，會由ConsumerBase的介面onFrameAvailable來替代完成。

2.4 mCallbackWindow = new Surface(producer)
這裡是建立一個Surface，也就是類型於Preview模式下建立的Surface，兩者的本質是一樣的。在Android5.1中，Surface已經擁有了絕對的控制權，Preview模式下的Surface是跨進程的和SF進行互動，故建構函式傳入的sp& bufferProducer參數一般是一個BufferQueue中BufferQueueProducer側匿名的binder BpGraphicBufferProducer。對於CPUConsumer而言，兩者是處於同一進程之中的，Surface主要行駛如下的操作，而在舊版本中這些主要由SurfaceTextureClient來管理的：

 

   ANativeWindow::setSwapInterval  = hook_setSwapInterval;    ANativeWindow::dequeueBuffer    = hook_dequeueBuffer;    ANativeWindow::cancelBuffer     = hook_cancelBuffer;    ANativeWindow::queueBuffer      = hook_queueBuffer;    ANativeWindow::query            = hook_query;    ANativeWindow::perform          = hook_perform;    ANativeWindow::dequeueBuffer_DEPRECATED = hook_dequeueBuffer_DEPRECATED;    ANativeWindow::cancelBuffer_DEPRECATED  = hook_cancelBuffer_DEPRECATED;    ANativeWindow::lockBuffer_DEPRECATED    = hook_lockBuffer_DEPRECATED;    ANativeWindow::queueBuffer_DEPRECATED   = hook_queueBuffer_DEPRECATED;

一般對Buffer的操作都先是基於Struct ANativeWindow這個本地的視窗類別來處理，再是通過hook到實際的surface再交由GraphicBufferProducer來完成的。

 

 

3 Android5.1下Surface的queuebuffer操作邏輯

對比上一圖可知，當前CPUConsumer模式下，從queuebuffer的處理過程來看更加體現出Productor和Consumer這種設計模式，整個架構代碼看起來也更明了，這也是Google不斷升級系統去冗存精的道理吧。整個使用者在調用這種邏輯是，只需幾句代碼就可以獲得對一個buffer塊的讀與寫的操作介面，具體後續在分析Camera HAL3的資料流時可以很深刻的看到。

總的來說Surface在Camera3Device的架構下，與HAL3相組合是充當了消費者，與CPUCOnsumer或者Surfaceflinger來說就是生產者。或者說surface充當了buffer資訊的傳輸與過渡。