转自：https://source.android.com/devices/graphics/?hl=zh-cn
图形
Android 框架提供了各种用于 2D 和 3D 图形渲染的 API，可与制造商的图形驱动程序实现方法交互，因此，务必充分了解这些 API 如何在更高的级别工作。本页介绍了在其上构建这些驱动程序的图形硬件抽象层 (HAL)。
应用开发者可通过两种方式将图像绘制到屏幕上：使用 Canvas 或 OpenGL。有关 Android 图形组件的详细说明，请参阅系统级图形架构。
android.graphics.Canvas是一个 2D 图形 API，并且是在开发者人群中最流行的图形 API。Canvas 运算会在 Android 中绘制所有原生和自定义android.view.View。在 Android 中，Canvas API 通过一个名为 OpenGLRenderer 的绘制库实现硬件加速，该绘制库将 Canvas 运算转换为 OpenGL 运算，以便它们可以在 GPU 上执行。
从 Android 4.0 开始，硬件加速的 Canvas 默认情况下处于启用状态。因此，支持 OpenGL ES 2.0 的硬件 GPU 对于 Android 4.0 及更高版本的设备来说是强制要求。有关硬件加速绘制路径的工作原理及其行为与软件绘制路径行为之间的差异的说明，请参阅硬件加速指南。
除了 Canvas，开发者渲染图形的另一个主要方式是使用 OpenGL ES 直接渲染到 Surface。Android 在Android.opengl包中提供了 OpenGL ES 接口，开发者可以使用这些接口通过 SDK 或Android NDK中提供的原生 API 调用其 GL 实现。
Android 实现人员可以使用drawElements 质量计划（也称为 deqp）来测试 OpenGL ES 功能。
Android 图形组件
无论开发者使用什么渲染 API，一切内容都会渲染到“Surface”。Surface 表示缓冲队列中的生产方，而缓冲队列通常会被 SurfaceFlinger 消耗。在 Android 平台上创建的每个窗口都由 Surface 提供支持。所有被渲染的可见 Surface 都被 SurfaceFlinger 合成到显示部分。
下图显示了关键组件如何协同工作：
图 1.Surface 如何被渲染
主要组件如下所述：
图像流生产方
图像流生产方可以是生成图形缓冲区以供消耗的任何内容。例如 OpenGL ES、Canvas 2D 和 mediaserver 视频解码器。
图像流消耗方
图像流的最常见消耗方是 SurfaceFlinger，该系统服务会消耗当前可见的 Surface，并使用窗口管理器中提供的信息将它们合成到显示部分。SurfaceFlinger 是可以修改显示部分内容的唯一服务。SurfaceFlinger 使用 OpenGL 和 Hardware Composer 来合成一组 Surface。
其他 OpenGL ES 应用也可以消耗图像流，例如相机应用会消耗相机预览图像流。非 GL 应用也可以是消耗方，例如 ImageReader 类。
窗口管理器
控制窗口的 Android 系统服务，它是视图容器。窗口总是由 Surface 提供支持。该服务会监督生命周期、输入和聚焦事件、屏幕方向、转换、动画、位置、变形、Z-Order 以及窗口的其他许多方面。窗口管理器会将所有窗口元数据发送到 SurfaceFlinger，以便 SurfaceFlinger 可以使用该数据在显示部分合成 Surface。
硬件混合渲染器
显示子系统的硬件抽象实现。SurfaceFlinger 可以将某些合成工作委托给 Hardware Composer，以分担 OpenGL 和 GPU 上的工作量。SurfaceFlinger 只是充当另一个 OpenGL ES 客户端。因此，在 SurfaceFlinger 将一个或两个缓冲区合成到第三个缓冲区中的过程中，它会使用 OpenGL ES。这样使合成的功耗比通过 GPU 执行所有计算更低。
Hardware Composer HAL则进行另一半的工作，并且是所有 Android 图形渲染的核心。Hardware Composer 必须支持事件，其中之一是 VSYNC（另一个是支持即插即用 HDMI 的热插拔）。
Gralloc
需要使用图形内存分配器 (Gralloc) 来分配图像生产方请求的内存。有关详情，请参阅Gralloc HAL。
数据流
有关 Android 图形管道的描述，请参见下图：
图 2.流经 Android 的图形数据流
左侧的对象是生成图形缓冲区的渲染器，如主屏幕、状态栏和系统界面。SurfaceFlinger 是合成器，而硬件混合渲染器是制作器。
BufferQueue
BufferQueues 是 Android 图形组件之间的粘合剂。它们是一对队列，可以调解缓冲区从生产方到消耗方的固定周期。一旦生产方移交其缓冲区，SurfaceFlinger 便会负责将所有内容合成到显示部分。
有关 BufferQueue 通信过程，请参见下图。
图 3.BufferQueue 通信过程
BufferQueue 包含将图像流生产方与图像流消耗方结合在一起的逻辑。图像生产方的一些示例包括由相机 HAL 或 OpenGL ES 游戏生成的相机预览。图像消耗方的一些示例包括 SurfaceFlinger 或显示 OpenGL ES 流的另一个应用，如显示相机取景器的相机应用。
BufferQueue 是将缓冲区池与队列相结合的数据结构，它使用 Binder IPC 在进程之间传递缓冲区。生产方接口，或者您传递给想要生成图形缓冲区的某个人的内容，即是 IGraphicBufferProducer（SurfaceTexture的一部分）。BufferQueue 通常用于渲染到 Surface，并且与 GL 消耗方及其他任务一起消耗内容。BufferQueue 可以在三种不同的模式下运行：
类同步模式 - 默认情况下，BufferQueue 在类同步模式下运行，在该模式下，从生产方进入的每个缓冲区都在消耗方那退出。在此模式下不会舍弃任何缓冲区。如果生产方速度太快，创建缓冲区的速度比消耗缓冲区的速度更快，它将阻塞并等待可用的缓冲区。
非阻塞模式 - BufferQueue 还可以在非阻塞模式下运行，在此类情况下，它会生成错误，而不是等待缓冲区。在此模式下也不会舍弃缓冲区。这有助于避免可能不了解图形框架的复杂依赖项的应用软件出现潜在死锁现象。
舍弃模式 - 最后，BufferQueue 可以配置为丢弃旧缓冲区，而不是生成错误或进行等待。例如，如果对纹理视图执行 GL 渲染并尽快绘制，则必须丢弃缓冲区。
为了执行这项工作的大部分环节，SurfaceFlinger 就像另一个 OpenGL ES 客户端一样工作。例如，当 SurfaceFlinger 正在积极地将一个缓冲区或两个缓冲区合成到第三个缓冲区中时，它使用的是 OpenGL ES。
Hardware Composer HAL 执行另一半工作。该 HAL 充当所有 Android 图形渲染的中心点。
同步框架
由于 Android 图形不提供显式并行性，因此供应商一直都是在自己的驱动程序中实现自己的隐式同步。但是，Android 图形同步框架不再需要这么做。有关实现说明，请参阅显式同步部分。
同步框架明确描述了系统中不同异步操作之间的依赖关系。框架提供了一个简单 API，使组件在缓冲区被释放时发出信号。它还允许在从内核到用户空间的驱动程序之间以及用户空间进程本身之间传递同步基元。
例如，应用可以将要在 GPU 中执行的工作加入队列。然后，GPU 开始绘制该图像。尽管图像尚未被绘制到内存中，但缓冲区指针仍然可以与指示 GPU 工作何时完成的栅栏一起传递到窗口合成器。然后，窗口合成器可以提前开始处理，并将工作移交给显示控制器。通过这种方式，CPU 工作可以提前完成。GPU 完成后，显示控制器就可以立即显示图像。
同步框架还允许实现人员在自己的硬件组件中利用同步资源。最后，框架使实现人员可以查看图形管道，以帮助进行调试。
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 3.0 License, and code samples are licensed under theApache 2.0 License. For details, see ourSite Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 九月 13, 2017.