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

可以看到创建一个BufferQueue就是创建一个BufferQueueCore，然后以这个core为参数分别创建生产者基础接口和消费者基础接口。一般情况下都是在消费者进程中创建的BufferQueue，然后把生产者接口用Binder跨进程传递给生产者进程。当然也可以反过来，也可以两者都跨进程，也可以两者都不跨进程。之所以大部分情况下选择在消费者进程中创建BufferQueue，是为了想让消费者准备好，然后生产者一生成就可以立马得到消费了。

一般情况下我们并不会直接使用原始的生产者或者消费者接口，而是会对它们进行层层封装，封装之后的接口就比较方便使用了。下面我们看一下它的封装逻辑图。
这个图画的是APK与SurfaceFlinger对BufferQueue的使用情况。可以看到对原始生产者接口的封装一般都是Surface，但是我们也会经常在代码中看到SurfaceControl，这是怎么回事呢？这是为了完成控制权与绘制权的分离。APK启动的时候会去请求WMS创建窗口也就是Surface，WMS再去请求SurfaceFlinger创建BufferQueue，并获得其原始生产者接口。WMS自身把原始生产者封装为SurfaceControl，以便对Surface进行控制。然后又把原始生产者封装为Surface传递给APK，这样APK就只有绘制权了。APK如果想设置Surface的属性，还得请求WMS的帮忙。下面画个图看一下：
下面我们再看一下BufferQueue的内部管理逻辑。BufferQueue管理的是GraphicBuffer，但又不是直接管理的GraphicBuffer，而是定义了BufferSlot结构体。BufferSlot包含对GraphicBuffer的智能指针应用和对Fence的智能指针引用，以及BufferState。BufferQueueCore包含一个BufferSlot的数组，有64个元素，由于BufferSlot内部都是智能指针引用，所以它一开始都是空的，只有用到了才会分配。BufferQueue在管理BufferSlot的时候并不会直接去操作它们，而是会管理它们的下标。下面我们画个图看一下。
BufferQueue用4个整数容器来管理BufferSlot，BufferSlot的下标放在不同的容器中有不同的含义。首先是BufferQueue硬编码定义的64是all slots，当创建BufferQueue之后我们可以使用接口函数来设置我们要用多少个Buffer，不用的下标就会被放置在容器mUnusedSlots中，使用的下标就会被放置在容器mFreeSlots中。然后当我们使用某个Buffer的时候，无论是生产者使用还是消费者使用，都会把它的下标放入容器mActiveBuffers中去。当消费者使用完一个Buffer的时候又会把它放入容器mFreeBuffers中去。mFreeBuffers和mFreeSlots的区别是前者的BufferSlot已经关联上GraphicBuffer了，而后者仅仅是一个空的slot。Buffer的状态变迁我们在3.4节中讲。

3.3 显存分配与同步

当我们第一次使用BufferSlot的时候就会去分配GraphicBuffer，那么GraphicBuffer又是怎么样分配内存的呢？GraphicBuffer会通过谷歌定义的Gralloc接口来分配内存。Gralloc接口又是通过两个Hidl接口IAllocator和IMapper来实现的。下面我们画图来看一下。

可以看到最终分配内存的方法是ION。ION是一种跨空间跨设备的内存分配方法，ION是基于DMA-BUF的，我们先来说一下DMA-BUF。

DMA-BUF是一种跨空间跨设备的内存共享机制，它仅仅是一个框架，并不能分配内存。DMA-BUF既不是DMA也不是BUF，而是Sharing。DMA-BUF定义了两个角色：Exporter(导出者)，负责分配内存，一个体系中只能存在一个导入者；Importer(导入者)，也叫User，负责使用内存，可以有N个，一般有两个，一个写，既生产者，一个读，既消费者。下面我们画图来看一下：
明白了DMA-BUF，我们再来看一下ION。ION是建立在DMA-BUF的基础之上的，ION能够在进程之间、进程和内核之间、设备之间共享内存都归功于DMA-BUF。ION自身有许多heap，不同的heap用来分配不同类型的内存，ION默认使用system heap。内核里的代码可以直接使用ION的接口，为了让用户空间也能使用ION，ION创建了一个设备文件/dev/ion。用户空间可以用各种ioctl命令来使用ION，显然这不太方便，于是产生了libion来帮助大家方便地使用ION。总结一下，如下图所示：
GraphicBuffer的内存分配完成之后，就可以用来渲染和合成了。但是我们现在只能进行同步操作，而GPU的渲染是异步，为了能提高性能，我们需要一种异步使用下的等待通知机制。为此内核中实现了Fence，它主要是给DMA-BUF用的，所以它也是一种跨空间跨设备的机制。因此，Fence是一种跨设备跨空间的wait/notify机制，它和Java中的wait/notify、C++中条件变量的wait/signal的语义是一样的，不同的是，Java、C++中的机制只能在进程内使用。Fence还有一个很大的特点就是它的notify信号不会丢失，这是因为Fence是一次性的，用完就扔，每次使用都需要重新申请一个，不能复用，因此Fence都是有编号的。Fence不仅有编号，还有context，不同的场景都可以创建context。同一个context下的fence编号是有可比较性的，编号小的时间在前。不同context下的fence编号不具有可比较性。下面我们画图来看一下。

3.4 生产消费流程

明白了前面的知识之后，我们就要来看一看生产消费的具体流程了。我们先来看一下BufferSlot的状态变迁，BufferSlot的状态变化是和生产消费的流程相关的。我们先看图再来解说。

一个BufferSlot最初是处于Free状态的，当生产者准备生产的时候，会先dequeueBuffer，此时就会得到BufferSlot，BufferSlot的状态也会变为Dequeued。得到的BufferSlot如果之前是空的slot，就会去分配内存，流程在上一节中说过了，如果是已经分配内存的slot则直接使用。然后生产者开始生产，把生产的内存都放到GraphicBuffer中去。当生产完成时就会调用queueBuffer，以告诉消费者我生产完了，你可以开始消费了。queueBuffer之后，BufferSlot的状态就由Dequeue转变为Queued。此时的GraphicBuffer会被封装为一个BufferItem结构体，放入mQueue队列中。消费者得到消息后就要准备消费了。消费者先acquireBuffer，从mQueue队列中获取一个BufferItem，其对应的BufferSlot的状态就转化为Acquired了。然后消费者就可以开始消费了，当消费完成的时候，会调用releaseBuffer表明自己消费完成，把BufferSlot还给BufferQueue，此时BufferSlot的状态就回归Free了。

明白了BufferSlot的状态变化以及生成消费的基本流程之后，我们再来看一下，在VSync下，在有Fence的情况下，生成消费的流程。我们先看图：
首先渲染和合成是两个独立的线程，两者是同时进行的，双方都是在收到VSync信号时开始执行的。其次渲染和合成都分别有一个额外的线程来进行异步渲染与合成，不会阻塞主流线程。主流线程没有阻塞操作，不会卡住，两个异步线程都在等Fence信号，有可能会卡住。当某个异步线程一直卡住的时候，比如说合成线程卡住了，会导致渲染线程一直在wait Fence信号也会卡住，但是主线程还能继续运行。

四、总结回顾