void BfferQueue::createBufferQueue(sp* outProducer, sp* outConsumer) { spcore(new BufferQueueCore()); spproducer(new BufferQueueProducer(core)); spconsumer(new BufferQueueConsumer(core)); *outProducer = producer; *outConsumer = consumer;}

可以看到創(chuàng)建一個(gè)BufferQueue就是創(chuàng)建一個(gè)BufferQueueCore，然后以這個(gè)core為參數(shù)分別創(chuàng)建生產(chǎn)者基礎(chǔ)接口和消費(fèi)者基礎(chǔ)接口。一般情況下都是在消費(fèi)者進(jìn)程中創(chuàng)建的BufferQueue，然后把生產(chǎn)者接口用Binder跨進(jìn)程傳遞給生產(chǎn)者進(jìn)程。當(dāng)然也可以反過來，也可以兩者都跨進(jìn)程，也可以兩者都不跨進(jìn)程。之所以大部分情況下選擇在消費(fèi)者進(jìn)程中創(chuàng)建BufferQueue，是為了想讓消費(fèi)者準(zhǔn)備好，然后生產(chǎn)者一生成就可以立馬得到消費(fèi)了。

一般情況下我們并不會(huì)直接使用原始的生產(chǎn)者或者消費(fèi)者接口，而是會(huì)對它們進(jìn)行層層封裝，封裝之后的接口就比較方便使用了。下面我們看一下它的封裝邏輯圖。
這個(gè)圖畫的是APK與SurfaceFlinger對BufferQueue的使用情況?？梢钥吹綄υ忌a(chǎn)者接口的封裝一般都是Surface，但是我們也會(huì)經(jīng)常在代碼中看到SurfaceControl，這是怎么回事呢？這是為了完成控制權(quán)與繪制權(quán)的分離。APK啟動(dòng)的時(shí)候會(huì)去請求WMS創(chuàng)建窗口也就是Surface，WMS再去請求SurfaceFlinger創(chuàng)建BufferQueue，并獲得其原始生產(chǎn)者接口。WMS自身把原始生產(chǎn)者封裝為SurfaceControl，以便對Surface進(jìn)行控制。然后又把原始生產(chǎn)者封裝為Surface傳遞給APK，這樣APK就只有繪制權(quán)了。APK如果想設(shè)置Surface的屬性，還得請求WMS的幫忙。下面畫個(gè)圖看一下：
下面我們再看一下BufferQueue的內(nèi)部管理邏輯。BufferQueue管理的是GraphicBuffer，但又不是直接管理的GraphicBuffer，而是定義了BufferSlot結(jié)構(gòu)體。BufferSlot包含對GraphicBuffer的智能指針應(yīng)用和對Fence的智能指針引用，以及BufferState。BufferQueueCore包含一個(gè)BufferSlot的數(shù)組，有64個(gè)元素，由于BufferSlot內(nèi)部都是智能指針引用，所以它一開始都是空的，只有用到了才會(huì)分配。BufferQueue在管理BufferSlot的時(shí)候并不會(huì)直接去操作它們，而是會(huì)管理它們的下標(biāo)。下面我們畫個(gè)圖看一下。
BufferQueue用4個(gè)整數(shù)容器來管理BufferSlot，BufferSlot的下標(biāo)放在不同的容器中有不同的含義。首先是BufferQueue硬編碼定義的64是all slots，當(dāng)創(chuàng)建BufferQueue之后我們可以使用接口函數(shù)來設(shè)置我們要用多少個(gè)Buffer，不用的下標(biāo)就會(huì)被放置在容器mUnusedSlots中，使用的下標(biāo)就會(huì)被放置在容器mFreeSlots中。然后當(dāng)我們使用某個(gè)Buffer的時(shí)候，無論是生產(chǎn)者使用還是消費(fèi)者使用，都會(huì)把它的下標(biāo)放入容器mActiveBuffers中去。當(dāng)消費(fèi)者使用完一個(gè)Buffer的時(shí)候又會(huì)把它放入容器mFreeBuffers中去。mFreeBuffers和mFreeSlots的區(qū)別是前者的BufferSlot已經(jīng)關(guān)聯(lián)上GraphicBuffer了，而后者僅僅是一個(gè)空的slot。Buffer的狀態(tài)變遷我們在3.4節(jié)中講。

3.3 顯存分配與同步

當(dāng)我們第一次使用BufferSlot的時(shí)候就會(huì)去分配GraphicBuffer，那么GraphicBuffer又是怎么樣分配內(nèi)存的呢？GraphicBuffer會(huì)通過谷歌定義的Gralloc接口來分配內(nèi)存。Gralloc接口又是通過兩個(gè)Hidl接口IAllocator和IMapper來實(shí)現(xiàn)的。下面我們畫圖來看一下。

可以看到最終分配內(nèi)存的方法是ION。ION是一種跨空間跨設(shè)備的內(nèi)存分配方法，ION是基于DMA-BUF的，我們先來說一下DMA-BUF。

DMA-BUF是一種跨空間跨設(shè)備的內(nèi)存共享機(jī)制，它僅僅是一個(gè)框架，并不能分配內(nèi)存。DMA-BUF既不是DMA也不是BUF，而是Sharing。DMA-BUF定義了兩個(gè)角色：Exporter(導(dǎo)出者)，負(fù)責(zé)分配內(nèi)存，一個(gè)體系中只能存在一個(gè)導(dǎo)入者；Importer(導(dǎo)入者)，也叫User，負(fù)責(zé)使用內(nèi)存，可以有N個(gè)，一般有兩個(gè)，一個(gè)寫，既生產(chǎn)者，一個(gè)讀，既消費(fèi)者。下面我們畫圖來看一下：
明白了DMA-BUF，我們再來看一下ION。ION是建立在DMA-BUF的基礎(chǔ)之上的，ION能夠在進(jìn)程之間、進(jìn)程和內(nèi)核之間、設(shè)備之間共享內(nèi)存都?xì)w功于DMA-BUF。ION自身有許多heap，不同的heap用來分配不同類型的內(nèi)存，ION默認(rèn)使用system heap。內(nèi)核里的代碼可以直接使用ION的接口，為了讓用戶空間也能使用ION，ION創(chuàng)建了一個(gè)設(shè)備文件/dev/ion。用戶空間可以用各種ioctl命令來使用ION，顯然這不太方便，于是產(chǎn)生了libion來幫助大家方便地使用ION?？偨Y(jié)一下，如下圖所示：
GraphicBuffer的內(nèi)存分配完成之后，就可以用來渲染和合成了。但是我們現(xiàn)在只能進(jìn)行同步操作，而GPU的渲染是異步，為了能提高性能，我們需要一種異步使用下的等待通知機(jī)制。為此內(nèi)核中實(shí)現(xiàn)了Fence，它主要是給DMA-BUF用的，所以它也是一種跨空間跨設(shè)備的機(jī)制。因此，F(xiàn)ence是一種跨設(shè)備跨空間的wait/notify機(jī)制，它和Java中的wait/notify、C++中條件變量的wait/signal的語義是一樣的，不同的是，Java、C++中的機(jī)制只能在進(jìn)程內(nèi)使用。Fence還有一個(gè)很大的特點(diǎn)就是它的notify信號不會(huì)丟失，這是因?yàn)镕ence是一次性的，用完就扔，每次使用都需要重新申請一個(gè)，不能復(fù)用，因此Fence都是有編號的。Fence不僅有編號，還有context，不同的場景都可以創(chuàng)建context。同一個(gè)context下的fence編號是有可比較性的，編號小的時(shí)間在前。不同context下的fence編號不具有可比較性。下面我們畫圖來看一下。

3.4 生產(chǎn)消費(fèi)流程

明白了前面的知識之后，我們就要來看一看生產(chǎn)消費(fèi)的具體流程了。我們先來看一下BufferSlot的狀態(tài)變遷，BufferSlot的狀態(tài)變化是和生產(chǎn)消費(fèi)的流程相關(guān)的。我們先看圖再來解說。

一個(gè)BufferSlot最初是處于Free狀態(tài)的，當(dāng)生產(chǎn)者準(zhǔn)備生產(chǎn)的時(shí)候，會(huì)先dequeueBuffer，此時(shí)就會(huì)得到BufferSlot，BufferSlot的狀態(tài)也會(huì)變?yōu)镈equeued。得到的BufferSlot如果之前是空的slot，就會(huì)去分配內(nèi)存，流程在上一節(jié)中說過了，如果是已經(jīng)分配內(nèi)存的slot則直接使用。然后生產(chǎn)者開始生產(chǎn)，把生產(chǎn)的內(nèi)存都放到GraphicBuffer中去。當(dāng)生產(chǎn)完成時(shí)就會(huì)調(diào)用queueBuffer，以告訴消費(fèi)者我生產(chǎn)完了，你可以開始消費(fèi)了。queueBuffer之后，BufferSlot的狀態(tài)就由Dequeue轉(zhuǎn)變?yōu)镼ueued。此時(shí)的GraphicBuffer會(huì)被封裝為一個(gè)BufferItem結(jié)構(gòu)體，放入mQueue隊(duì)列中。消費(fèi)者得到消息后就要準(zhǔn)備消費(fèi)了。消費(fèi)者先acquireBuffer，從mQueue隊(duì)列中獲取一個(gè)BufferItem，其對應(yīng)的BufferSlot的狀態(tài)就轉(zhuǎn)化為Acquired了。然后消費(fèi)者就可以開始消費(fèi)了，當(dāng)消費(fèi)完成的時(shí)候，會(huì)調(diào)用releaseBuffer表明自己消費(fèi)完成，把BufferSlot還給BufferQueue，此時(shí)BufferSlot的狀態(tài)就回歸Free了。

明白了BufferSlot的狀態(tài)變化以及生成消費(fèi)的基本流程之后，我們再來看一下，在VSync下，在有Fence的情況下，生成消費(fèi)的流程。我們先看圖：
首先渲染和合成是兩個(gè)獨(dú)立的線程，兩者是同時(shí)進(jìn)行的，雙方都是在收到VSync信號時(shí)開始執(zhí)行的。其次渲染和合成都分別有一個(gè)額外的線程來進(jìn)行異步渲染與合成，不會(huì)阻塞主流線程。主流線程沒有阻塞操作，不會(huì)卡住，兩個(gè)異步線程都在等Fence信號，有可能會(huì)卡住。當(dāng)某個(gè)異步線程一直卡住的時(shí)候，比如說合成線程卡住了，會(huì)導(dǎo)致渲染線程一直在wait Fence信號也會(huì)卡住，但是主線程還能繼續(xù)運(yùn)行。

四、總結(jié)回顧