参考文档：
本文记录一下关于图像的深入学习过程，想来工作也有两年有余了，期间也写过不少的自定义View，熟络的也仅仅是Api的调用以及对应Java层的调用逻辑，对于native层的源码也是浅尝辄止，没有细细研究过，今天抽空看了一下官方文档，关于图像这一块的内容还是蛮多的，这里就下决心研究一下吧，关于图像这一块，涉及的比较多，如SurfaceFlinger，Vsync同步信号，硬件加速等等，希望能坚持把文章写完吧。
首先这里先做个总述吧，这里使用的基本上是官网上的解释以及图片，做个知识的搬运工。如果能够翻墙的同学可以直接在官网看即可，无需查看下面内容。
前言
对于图像的显示，日常中经常接触到的控件就是显示图像的一部分，包括TextView，Button，RecyclerView等等所有的控件建立在Canvas上显示成像，在深入一点的可以使用opengl es来进行绘制。这两种方式就是Android提供给我们的在可操作层次上的Api。下面对Canvas以及Opengl做个介绍：
- Canvas是一个 2D 图形 API，Canvas 运算可在 Android 中绘制所有原生和自定义 android.view.View。在 Android 中，Canvas API 通过一个名为 OpenGLRenderer 的绘制库实现硬件加速，该绘制库将 Canvas 运算转换为 OpenGL 运算，以便它们可以在 GPU 上执行。从 Android 4.0 开始，硬件加速的 Canvas 默认情况下处于启用状态。
- Opengl es为Opengl的阉割版，由于移动设备跟PC的硬件差异，导致了 Opengl es的出现。开发者渲染图形的另一个主要方式是使用 OpenGL ES 直接渲染到 Surface。Android 会在 Android.opengl 软件包中提供 OpenGL ES 接口，开发者可以使用这些接口通过 SDK 或原生 API（在 Android NDK 中提供）来调用其 GL 实现。
Android 图形组件
无论开发者使用什么渲染 API，一切内容都会渲染到“Surface”。Surface 表示缓冲队列中的生产方，而缓冲队列通常会被 SurfaceFlinger 消耗。在 Android 平台上创建的每个窗口都由 Surface 提供支持。所有被渲染的可见 Surface 都被 SurfaceFlinger 合成到显示部分。
下面展示关键组件的协同工作内容：
Image Stream Producers
图像流生产者可以是生成图形缓冲区以供消耗的任何内容，如 OpenGL ES、Canvas 2D 和 mediaserver 视频Decoder。
Window Manager
Window Manager控制窗口的 Android 系统服务，它是视图容器。窗口总是由 Surface 提供支持。该服务会监督生命周期、输入和聚焦事件、屏幕方向、转换、动画、位置、变形、Z-Order 以及窗口的其他许多方面。窗口管理器会将所有窗口元数据发送到 SurfaceFlinger，以便 SurfaceFlinger 可以使用该数据在显示部分合成 Surface。
Image Stream Consumers
最常见的图像流消费者就是SurfaceFlinger，系统服务会消费当前可见的Surfaces并且结合WindowManager所提供的信息一起合成展示到显示中。SurfaceFlinger 是可以修改所显示部分内容的唯一服务。SurfaceFlinger 使用 OpenGL 和 Hardware Composer 来合成一组 Surface。
Hardware Composer
这里我也有点懵逼，先原文写上吧
The hardware abstraction for the display subsystem. SurfaceFlinger can delegate certain composition work to the Hardware Composer to offload work from OpenGL and the GPU. SurfaceFlinger acts as just another OpenGL ES client. So when SurfaceFlinger is actively compositing one buffer or two into a third, for instance, it is using OpenGL ES. This makes compositing lower power than having the GPU conduct all computation.
The Hardware Composer HAL conducts the other half of the work and is the central point for all Android graphics rendering. The Hardware Composer must support events, one of which is VSYNC (another is hotplug for plug-and-playHDMI support).
Hardware Composer翻译成硬件混合渲染器，是显示图像子系统( display subsystem)的硬件抽象实现。SurfaceFlinger 可以将某些合成工作委托给 Hardware Composer，以分担 OpenGL 和 GPU 上的工作量。因此，在 SurfaceFlinger 将一个或两个缓冲区合成到第三个缓冲区中的过程中，它会使用 OpenGL ES。这样使合成的功耗比通过 GPU 执行所有计算更低。
Hardware Composer HAL 则进行另一半的工作，并且是所有 Android 图形渲染的核心。Hardware Composer 必须支持事件，其中之一是 VSYNC（另一个是支持即插即用 HDMI 的热插拔）。
** Gralloc **
Gralloc是需要使用图形内存分配器 (Gralloc) 来分配图像生产方请求的内存。
数据流
下图为Android图形管道的描述：
左侧的对象是生成图形缓冲区的渲染器，如主屏幕、状态栏和系统界面。SurfaceFlinger 是合成器，而硬件混合渲染器是制作器。
BufferQueue
BufferQueues 是 Android 图形组件之间的粘合剂。它们是一对队列(注意是一对)，可以调解缓冲区从生产方到消耗方的固定周期。一旦生产方移交其缓冲区，SurfaceFlinger 便会负责将所有内容合成到显示部分(硬件显示，即手机屏幕)。
BufferQueue 通信过程如下图：
BufferQueue 包含将图像流生产方与图像流消耗方结合在一起的逻辑。
BufferQueue 是将缓冲区池与队列相结合的数据结构，它使用 Binder IPC 在进程之间传递缓冲区。生产方接口为 IGraphicBufferProducer（SurfaceTexture 的一部分）。BufferQueue 通常用于渲染到 Surface，并且与 GL 消耗方及其他任务一起消耗内容。BufferQueue 可以在三种不同的模式下运行：
类同步模式 - 默认情况下，BufferQueue 在类同步模式下运行，在该模式下，从生产方进入的每个缓冲区都在消耗方那退出。在此模式下不会舍弃任何缓冲区。如果生产方速度太快，创建缓冲区的速度比消耗缓冲区的速度更快，它将阻塞并等待可用的缓冲区。
非阻塞模式 - BufferQueue 还可以在非阻塞模式下运行，在此类情况下，它会生成错误，而不是等待缓冲区。在此模式下也不会舍弃缓冲区。这有助于避免可能不了解图形框架的复杂依赖项的应用软件出现潜在死锁现象。
舍弃模式 - 最后，BufferQueue 可以配置为丢弃旧缓冲区，而不是生成错误或进行等待。例如，如果对纹理视图执行 GL 渲染并尽快绘制，则必须丢弃缓冲区。
为了执行这项工作的大部分环节，SurfaceFlinger 就像另一个 OpenGL ES 客户端一样工作。例如，当 SurfaceFlinger 正在积极地将一个缓冲区或两个缓冲区合成到第三个缓冲区中时，它使用的是 OpenGL ES。
Hardware Composer HAL 执行另一半工作。该 HAL 充当所有 Android 图形渲染的中心点。
同步框架
同步框架明确描述了系统中不同异步操作之间的依赖关系。框架提供了一个简单 API，使组件在缓冲区被释放时发出信号。它还允许在从内核到用户空间的驱动程序之间以及用户空间进程本身之间传递同步基元。例如，应用可以将要在 GPU 中执行的工作加入队列。然后，GPU 开始绘制该图像。尽管图像尚未被绘制到内存中，但缓冲区指针仍然可以与指示 GPU 工作何时完成的栅栏一起传递到窗口合成器。然后，窗口合成器可以提前开始处理，并将工作移交给显示控制器。通过这种方式，CPU 工作可以提前完成。GPU 完成后，显示控制器就可以立即显示图像。
扫一扫
1618
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
