原文链接：http://www.apkbus.com/blog-705730-61394.html

Android框架提供了各种2D/3D图形渲染API,负责与厂商实现的图形驱动来交互，因此深入理解这些API如何在更高层次上工作非常重要。本页介绍了图形硬件抽象层。

应用开发者有两种方法来绘图：Canvas，OPENGL。请参考 图形架构 详细了解android图形组件。

android.graphics.Canvas 是最流行的2D图形API。Canvas操作 在Android中绘制所有的原生和定制的View对象（ android.view.View）。在Android中，绘图库OpenGL 负责 CanvasAPI的硬件加速，将Canvas 操作转换为OpenGL操作以便在GPU上执行。

从Android4.0开始，Canvas的硬件加速是默认打开的，这导致GPU硬件必须支持OpenGL ES2.0。Hardware Accerleration Guide enter link description here 解释了硬件加速绘图路径的工作原理，以及软件绘图路径的区别。

对于Canvas，开发者 渲染图形的另外一种主要方法是 使用OpenGL ES直接渲染 surface 实例。在android.opengl包中，android提供了OpenGL ES接口，开发者可以用来调用他们自己SDK 的GL实现,或者AndroidNDK提供的本地API。

Android 可以使用deqp（drawElements Quality Program）来实测OpenGL ES功能。

图形组件

不管开发者使用何种渲染API，最终所有的东东渲染到某个“surface”上。surface 代表了生产者侧的一个buffer queue，通常其消费者是SurfaceFlinger。Android平台上所有的窗口，背后都有一个surface。所有可见的surface，由SurfaceFlinger合成到显示上。

下图展示了关键的图形组件： 

Figure 1. How surfaces are rendered

下面介绍了主要图形组件

生产者（Image Stream Producers）

只要能够产生图形缓冲以供消费的东东都可以称为 生产者，例如：OpenGL ES，Canvas 2D, 媒体服务中的视频解码器。

消费者（Image Stream Consumers）

图像流的最常见的消费者是SurfaceFlinger。该系统服务器负责消费当前可见的surfaces。SurfaceFlinger是唯一的可以修改显示内容的服务，使用OpenGL和硬件合成器，根据WindowsManager提供的信息，将这些surfaces合成到显示上。

其他OpenGL ES应用也可以消费图像流，例如，camera应用消费camera预览图像流。非OpenGL应用也可能hi消费者，例如，ImageRader Class。

窗口管理器（Window Manager）

该系统服务负责控制窗口，而窗口是views的容器。一个windows后面总是存在一个surface。WM服务监视 生命周期、输入和焦点事件、屏幕方向、透明度、动画、位置、变形、z-order以及window的其他很多方面。WM 将所有的窗口的元数据发送到SurfaceFlinger，以便SurfaceFlinger使用这些数据来合成显示。

硬件合成器（Hardware Composer ）

硬件合成器是显示子系统的硬件抽象。SurfaceFlinger可以将某些合成操作委托给硬件合成器，以降低OpenGL和GPU的负载。执行这种工作时，SurfaceFlinger表现得如同另外一种OpenGL ES客户端。因此当SurfaceFlinger 合成一块或者两块缓冲区到第三块缓冲区时，举例来说，他将使用OpenGL ES。 与全程使用GPU来完成所有计算相比，硬件合成器做合成工作耗能更低。（WHY？）

硬件合成器HAL 执行另一半工作。该HAL是所有Android图形渲染的中心。硬件合成器必须支持事件，其中之一是VSYNC，以及热插拔（hotplug）事件（用以支持HDMI即插即用）。

Gralloc

Gralloc是专用的图形内存分配器，用于向生产者分配内存。详情请见 Gralloc HAL。

Data Flow

下图描绘了Android图形管线：

 
Figure 2. Graphic data flow through Android

左侧的对象就是生产图形缓冲的渲染器，如主屏、状态条和系统UI。SurfaceFlinger是排序器（合成师），而硬件合成器HC 是合成器。

BufferQueue

BufferQueue 是Android图形组件间的胶合剂。These are a pair of queues that mediate the constant cycle of buffers from the producer to the consumer. 一对队列负责调和生产者到消费者之间的常数周期的多个缓冲区。一旦生产者交出了缓冲区，SurfaceFlinger将负责合成所有的一切到显示上。

下图展示了BufferQueue通信过程： 
 
Figure 3. BufferQueue communication process

BufferQueue将生产者和消费者结合在一起。一些例子中，某些生产者是相机预览，由camera HAL或者OpenGL ES游戏产生。另外一些例子中，消费者是SurfaceFlinger 或者显示OpenGL ES流的其他应用，例如cameraAPP 显示 camera viewfinder。

BufferQueue数据结构中，包含了一个缓冲区池、一个队列，并使用Binder在进程间传递缓冲区。生产者接口IGraphicBufferProducer 是SurfaceTexture的一部分，你可以传递给希望产生图形缓冲区的接收者。BufferQueue经常用于：渲染到一个surface上，然后使用一个GL consumer来配合其他任务来消费 。

BufferQueue有是那种不同的操作模式：

1. 同步模式（Synchronous-like Mode）。默认模式，每个缓冲区 在生产者中 引入（分配），然后在消费者中 离场（回收）。该模式中，没有缓冲区被丢弃。如果生产者过快了，创建缓冲区的速度快于被消耗的速度，生产者必须阻塞以等待空闲缓冲区。

2. 非阻塞模式（Non-blocking Mode）。在该模式中，同样不会丢弃缓冲区，但如果生产者过快，将产生一个错误而不是阻塞。这对避免应用软件中潜在的死锁非常有用，因为应用可能不太了解图形框架复杂的依赖关系。

3. 丢弃模式（Discard Mode）。过快是，缓冲区被丢弃，没错误也不阻塞。For instance, if conducting GL rendering to a texture view and drawing as quickly as possible, buffers must be dropped.

执行大部分这种工作时，SurfaceFlinger表现得如同另外一种OpenGL ES客户端。因此当SurfaceFlinger 合成一块或者两块缓冲区到第三块缓冲区时，举例来说，他将使用OpenGL ES。

硬件合成器HAL 执行（剩下）另一半工作。该HAL是所有Android图形渲染的中心。

Synchronization framework

既然Android图形框架提供不了显式并行，供应商 在他们自己的驱动中实现了自己的隐式同步。因此Android图形同步框架就不需要了。 Explicit synchronization 这一节有实现要求。

The synchronization framework explicitly describes dependencies between different asynchronous operations in the system. The framework provides a simple API that lets components signal when buffers are released. It also allows synchronization primitives to be passed between drivers from the kernel to userspace and between userspace processes themselves. 
同步框架显式描述了 系统中不同异步操作间的依赖关系。框架提供了一个简单的API，当缓冲区释放时 让组件发送一个信号；它也容许同步原语在驱动间传递（从内核到用户空间），以及在用户进程间传递。

For example, an application may queue up work to be carried out in the GPU. The GPU then starts drawing that image. Although the image hasn’t been drawn into memory yet, the buffer pointer can still be passed to the window compositor along with a fence that indicates when the GPU work will be finished. The window compositor may then start processing ahead of time and hand off the work to the display controller. In this manner, the CPU work can be done ahead of time. Once the GPU finishes, the display controller can immediately display the image. 
例如，一个应用可能将工作排队到GPU上。GPU稍后执行绘图。尽管图像还没有被绘制到内存中，缓冲区指针就已经可以被传递到window 排序器中，伴随一个指示GPU工作完成的屏障（fence）。windows排序器 可能开始提前处理，将工作交付给显示控制器。按照这种方式，CPU的工作可以提前完成；一旦GPU的工作完成，显示控制器可以马上显示图像。

同步框架也容许实现者影响他们自己的硬件组件中的同步资源。最后，为调试之用，框架提供了可视化到图形管线的功能。