前沿：
如果對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<IGraphicBufferProducer> producer;
- sp<IGraphicBufferConsumer> 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操作
2.1 BufferQueue::createBufferQueue
- void BufferQueue::createBufferQueue(sp<IGraphicBufferProducer>* outProducer,
- sp<IGraphicBufferConsumer>* outConsumer,
- const sp<IGraphicBufferAlloc>& 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<BufferQueueCore> core(new BufferQueueCore(allocator));
- LOG_ALWAYS_FATAL_IF(core == NULL,
- "BufferQueue: failed to create BufferQueueCore");
- sp<IGraphicBufferProducer> producer(new BufferQueueProducer(core));//本地Bn的BufferQueueProducer
- LOG_ALWAYS_FATAL_IF(producer == NULL,
- "BufferQueue: failed to create BufferQueueProducer");
- sp<IGraphicBufferConsumer> consumer(new BufferQueueConsumer(core));//本地Bn的BufferQueueConsumer
- LOG_ALWAYS_FATAL_IF(consumer == NULL,
- "BufferQueue: failed to create BufferQueueConsumer");
- *outProducer = producer;
- *outConsumer = consumer;
- }
2.2 CpuConsumer
在2.1中本質上是創建了BufferQueueProducer和BufferQueueConsumer，一般是成對出現。
這個CpuConsumer的地位本質是和SurfaceFlinger是一樣的，主要角色就是來處理已經帶有幀數據的buffer塊，所以整個的處理機制都是類型的，其中兩者均爲繼承一個ConsumerBase類，用於實現對buffer塊的處理。
- CpuConsumer::CpuConsumer(const sp<IGraphicBufferConsumer>& 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);
- }
這裏所完成的過程是需要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<IGraphicBufferProducer>& 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;
3 Android5.1下Surface的queuebuffer操作邏輯
對比上一圖可知，當前CPUConsumer模式下，從queuebuffer的處理過程來看更加體現出Productor和Consumer這種設計模式，整個架構代碼看起來也更明瞭，這也是谷歌不斷升級系統去冗存精的道理吧。整個用戶在調用這種邏輯是，只需幾句代碼就可以獲得對一個buffer塊的讀與寫的操作接口，具體後續在分析Camera HAL3的數據流時可以很深刻的看到。
總的來說Surface在Camera3Device的架構下，與HAL3相組合是充當了消費者，與CPUCOnsumer或者Surfaceflinger來說就是生產者。或者說surface充當了buffer信息的傳輸與過渡。
