BufferQueue原创 - fence 的流转

首先理解一下什么是 fence.

fence 可以理解为 一个有时间线的fd. 是的， 可以认为 fence 本质上是一个 fd, 是以 fd 的形式在各个进程之间流转的， 所以一般来说 要接收一个 fence 的话， 我们都是传递的一个 int 的地址， 本质上就是传的这个 fd.

假设 A 进程刚开始使用 B 进程生产的Buffer, 然后就马上把这个 Buffer 交给B进程再次生产，同时会传递一个Fence给B进程， B进程再次生产的时候， 就需要根据Fence来判断能不能复用这个Buffer.

具体流程是:
A模块在初始化的时候会创建一个timeline
struct sw_sync_timeline *timeline = sw_sync_timeline_create("test-timeline");

A收到B送的Buffer, 就会创建Fence, 然后把Buffer和Fence传递给B

对于每一个Buffer, A进程会根据自己的timeline创建一个节点PT, 这个节点的PT有一个value, 这个value是一个全局的， 每创建一个pt节点， value的值就会+1, 这样可以确保 后创建的节点的value值永远比前面的大
`struct sync_pt *pt = sw_sync_pt_create(timeline, val);

创建完这个pt节点， 就根据这个pt节点来创建一个 fence
struct sync_fence *fence = sw_sync_fence_create("test-fence",pt);

然后获取一个现在不被使用的fd
int fd = get_unused_fd();

把这个fence和fd绑定
sync_fence_install(fence,fd);

每使用完一个Buffer, 就按顺序signal timeline上的节点
sw_sync_timeline_inc(timeline, 1);

模块B想要复用该Buffer的时候，需要先取得fence, 然后看一下这个fence是否被signal
struct fence *fence = sw_file_get_fence(fd); //根据fd取得fence

等待fence被signal
sync_fence_wait(fence, 1000);

fence 分为两类， 生产者产生的 fence 叫做 acquireFence（不优雅，应该叫 producerFence）, 消费者产生的 fence 叫做 releaseFence （不恰当， 应该叫做 consumerFence）. 不过这都无所谓。
另一个角度看， 当写入一个Buffer的时候， 要带acquireFence还给BQ. 当读取完一个Buffer的时候要带releaseFence还给BQ.
再换一个角度， 当写入一个Buffer之前， 要check releaseFence. 但读取一个Buffer之前要check acquireFence.
这两类fence都是在把Buffer还给 BufferQueue 的时候增加的。

那我们就先看一下acquireFence的过程。 首先 Surface.cpp 的 queueBuffer 中， 会带有 fenceFd, 这个 fenceFd是在哪里赋值的呢？在Camera3OutputStream的returnBufferCheckedLocked方法中， 我们看到， Provider返回的这个 camera_stream_buffer 就带有fence, 自带 acquire_fence和release_fence， 我们这里用到的是release_fence.
这里为啥要用release_fence呢？ Surface作为生产者， 往BufferQueue中 queueBuffer 的时候应该带着 acquireFence 呀。
这个是因为 acquireFence 和 releaseFence 都是 BufferQueue 的叫法。。。。 bufferQueue会把 queueBuffer 的时候带的 fence 叫做 acquireFence...
但是对于很多底层的硬件来说， 当不是这个硬件生产的Buffer离开这个硬件的时候， 都会调用一些 release 方法， 然后往对应的数据结构的 relasexxx 属性上, 所以就造成了上面这种情况。

那我们在看一下 releaseFence 的过程， 在 android_media_ImageReader.cpp的 ImageReader_imageRelease中， 会先调用 Image_unlockIfLocked来获取 releaseFence, 最终调用到 GraphicBuffer 的 ublockAsync来获取Fence, 在调用到 GraphicBufferMapper的unlockAsync获取 Fence .

看一下在C++中的使用。

1. SurfaceComposerClient 是 SurfaceFlinger的 binder 代理， 可以通过它来让 SurfaceFlinger 分配buffer.
2. SurfaceComposerClient 的 createSurface 方法， 会创建一个 SurfaceControl, SurfaceControl 是 Surface 的包装类。
3. Surface 和 ANativeWindow 又是等价的。 要使用 ANativeWindow 申请 Buffer, 还有一些必要的设置, 这是由于这里的Buffer是从SurfaceFlinger来的， 所以缺少对应的参数。 ANativeWindow由于是真正和底层硬件打交道的， 所以我们必须要 通过native_window_api_connect来让它和具体的硬件关联。 然后native_window_set_buffers_format来设置Window的格式， native_window_set_usage来设置用途， native_window_set_buffers_user_dimensions来设置展示大小， native_window_set_scaling_mode来设置缩放模式， 一般都需要设置这些参数。
   然后才是调用 dequeueBuffer来获取一个Buffer.
   获得了buffer之后， 就可以包装成 GraphicBuffer, 然后 lock出来 buffer的地址， 进行数据填充了。
   填充完之后进行unlock
   最后将其queueBuffer到BufferQueue中， 就可以被消费者消费了。