Android 图形系统框架

网址（需翻墙）：http://source.android.com/devices/graphics/index.html

Android框架为2D和3D提供了一系列的图像渲染API，以与不同品牌制造商的图像驱动进行交互。所以从整体上了解这些API是如何工作的非常重要。这里介绍了建立在图像驱动之上的硬件抽象层（HAL）

Android应用开发者可以通过两种方式将图像描画到屏幕上：Canvas和OpenGL，关于Android图像组件的详细描述参见官网的System-level graphics architecture章节

android.graphics.Canvas是应用开发者中最为流行使用的一个2D图形API。Canvas的操作用于描画所有缓冲和用户的android.view.Views对象。在Android中，Canvas API的硬件加速实现在一个名为OpenGLRender的绘画库中，这个库将Canvas的操作翻译成OpenGL的操作以使其能够被GPU执行。

在Android 4.0上，Canvas的硬件加速被默认开启，因此在Android4.0及以后的版本上强制要求了对OpenGL ES2.0的硬件GPU支持。Hardware Acceleration guide详细解释了硬件加速的方式是如何工作的以及其与软件加速方式的区别

除了Canvas之外，开发者另一个渲染图像的主要方式就是使用OpenGL ES直接将图像渲染到Surface上了。Android在android.opengl包中为开发者提供了提供了OpenGL ES接口，使得开发者可以通过SDK或者Android NDK的API调用到GL的实现。

Android 实现者可以通过drawElements Quality program来测试OpenGL ES的功能，即degp。

Android图形组件

无论使用何种渲染ApI，一切最终都是被渲染到“surface上”。surface表现为一个经常被SurfaceFlinger消费的生产者侧Buffer队列。Android平台上创建的每一个窗口都被一个surface支持。所有可见的surfaces被SurfaceFlinger合成到屏幕上。

下面的图描述了关键组件是怎样配合工作的：



主要的组件如下：

Image Stream Producers(图像流生产者)

图像流生产者可以是产生供消费的图像buffer的任何 对象。比如OpenGL ES，Canvas 2D和流媒体解码器等

Image Stream Consumers(图像消费者)

通常的图像流消费者是SurfaceFlinger。系统服务利用WindowManager提供的信息消费掉当前的可见surfaces并将其合成到屏幕。SurfaceFlinger 是唯一可以修改显示组成的服务。SurfaceFlinger使用OpenGL和硬件特性合成一系列的surfaces。

其他OpenGL ES应用也可以消费图像，比如Camera应用消费Camera预览图像流，非GL应用也可以消费，比如ImageReader类

Window Manager

Android system service控制一个窗口（窗口是一系列View的容器），一个窗口通常由一个surface支持。这个服务监视声明周期、输入、焦点事件，屏幕旋转、转场效果、动画、位置变化，位置转换，Z轴次序及窗口的其他方面。Window Manager将所有窗口元数据送到SurfaceFlinger以使SurfaceFlinger可以使用这些数据来合成surface到屏幕上。

Hardware Composer

Hardware Composer是图像子系统的一个抽象。SurfaceFlinger可以委托部分工作给Hardware Composer以分担OpenGL和GPU的工作。SurfaceFlinger表现为OpenGL ES的另一个客户端。所以当SurfaceFlinger将一个或两个buffer合成到第三个，比如，使用OpenGL ES，就可以使得合成工作比单独使用GPU计算时有更低的功耗。

Hardware composer HAL进行另一半的工作。HAL是所有Android图像描画的中心指针。Hardware Composer必须支持events,比如VSYNC。此外还有用于支持即插即播HDMI设备支持的热插拔。

Gralloc

图像内存分配模块用于为图像生产者分配内存。

数据流

以下是Android图像管道的描述：



左边的对象是产生图像buffer的渲染器，比如Home 屏幕，状态栏和系统UI。SurfaceFlinger负责排布，硬件Composer负责刻录

BufferQueue

BufferQueue提供了Android图像系统间的联系。这是一对不断协调消费者和生产者的双队列。一旦生产者释放了它的buffer，SurfaceFlinger就负责将一切组合到显示屏上。



BufferQueue有将图像流生产者和图像流消费者绑定在一起的作用。图像生产者的例子有：camera HAL或者OpenGL ES游戏产生的Camera预览图像。图像消费者

的例子有：SurfaceFlinger或其他显示OpenGL ES流的应用，比如显示取景器的摄像头应用

BufferQueue是一种用于将buffer池绑定到一起的数据结构，通过使用Binder IPC来跨进程传递buffer。你用于传递图像的生产者接口是IGraphicBufferProducer（SurfaceTexture的一部分）。BufferQueue通常用于渲染surface及在其他任务中利用GL Consumer进行消费。BufferQueue可以在三种模式下进行操作：

1. 同步模式-BufferQueue默认在此模式下工作，每一个buffer从生产者生产出来之后都会交给消费者，没有任何buffer会被丢弃。如果生产者生产得太快，那么生产者将会阻塞以等待buffer释放。

2.非阻塞模式-BufferQueue也可以在非阻塞模式下工作，此模式在某些情况下会宁愿产生错误来避免等待buffer，此模式也不会有任何buffer会被丢弃。这对于避免

那些没有弄懂图像框架复杂依赖的应用中产生的死锁是很有用的。

3.丢弃模式-最后，BufferQueue可能会丢弃过时的buffer来避免产生错误或者等待。比如，如果要求GL 尽可能快地渲染纹理视图，那么部分buffer可能就必须要被丢弃。

Synchronization framework（同步框架）

因为Android图像系统没有提供显示的并行，方案商可以在驱动中实现其私有的同步方式。也就是说Android不限制图像系统的同步框架实现。同步框架明确描述不同异步操作之间的依赖关系，框架提供简单的API让组件在buffer被释放的时候可以收到信号。同时允许同步原语在内核的驱动到用户空间之间传递和处理。

比如一个应用可能排队在GPU上工作。然后GPU开始描画图像。虽然图像还没有被描画到内存中，但buffer指针仍然可以被传递给窗口排布器来描述GPU的工作何时会结束。

窗口排布器可能会提前处理并且将这个工作交给显示控制模块。在这个例子中，CPU的工作可以提前完成，一旦GPU的工作完成，显示控制模块就可以直接显示图像了。

同步框架允许实施者在其硬件组件中操作同步资源。

最后框架还提供了可视化图像管道来帮助调试工具。