Android SurfaceFlinger导读（05）理解fence机制

该系列文章总纲链接：Android GUI系统之SurfaceFlinger 系列文章目录

---

本章关键点总结 & 说明：

本章节思维导图如上。主要从2个方面讲述了fence机制，从简介到引入的原因，再到应用，即协调Buffer处理流程。

1 Fence机制简介

Fence（栅栏）机制是 android4.4开始引入的一种资源同步机制，主要用于处理跨硬件场景，如CPU、GPU、HWC之间的buffer资源同步。可以将fence理解为一种资源锁。

一组线程能够使用fence来集体进行相互同步。本质上每个线程在到达某种状态时调用fence的wait()方法,阻塞等待其他全部參与线程调用wait()方法表明它们也到达了这个状态.一旦全部的线程都到达fence,它们就会集体解除阻塞,并一起继续运行。

2 Fence机制的引入

GPU的产生就是为了加速图形显示到display的过程。GPU编程和纯CPU编程不同之处在于它是异步的，当我们调用GL command返回时这条命令并不一定完成了，只是把这个命令放在本地的command buffer里。具体什么时候这条GL command被真正执行完CPU是不知道的，除非CPU使用glFinish()等待这些命令执行完，但是这样效率就太低了。另外一种方法便是使用基于同步对象的Fence机制。

3 Fence机制协调Buffer处理流程的简要说明

这里主要谈论 fence在producer和consumer对buffer处理的过程中是怎样协调他们同步工作从而保证buffer内容准确性且不会被篡改的。基于前面的学习，一个buffer的状态变化是这样的：FREE->DEQUEUED->QUEUED->ACQUIRED->FREE，接下来就对Buffer的四种状态进行说明：

1. Buffer处于FREE状态时，producer并不能直接申请它，v此时需要等一个signal（NO_FENCE信号），由于有可能上一次申请的buffer正在被consumer消费中，所以要等待consumer发出finish的信号，而此时FREE状态下的buffer就好像被栅栏（fence）拦住了，这里是用Fence中wait()或者waitForever()方法。等一个NO_FENCCE信号，栅栏（fence）就会打开。进入到下一流程。
2. Buffer处于DEQUEUED状态时，即producer申请的buffer从队列中出来但还没有进入队列或者取消buffer。这个状态下producer想向Buffer填入UI数据时，必须等一个NO_FENCE信号，因为有可能其它owner正在对它进行操作。当信号到达时poducer就能够对其进行操作，操作完毕后再发出一个NO_FENCE信号。
3. Buffer处于QUEUED状态时，即 把buffer加入队列，在这个操作前必须等dequeueBuffer完毕之后发的NO_FENCE信号，收到信号后才进行入队列操作或者取消buffer操作。这个时候它的owner就变成BufferQueue了。
4. Buffer处于ACQUIRED状态时，即producer已经对buffer填充完毕，也要等一个NO_FENCE信号，然后consumer才干对其进行操作。操作完毕后会释放buffer，然后发出一个NO_FENCE 信号。

当然我们了解fence机制后就对 Buffer的处理理解更深了。同时后面的章节 为了方便分析，会忽略fence机制的部分。