1-概述
https://www.jianshu.com/p/41b4533f78bf
无论开发者使用什么渲染 API，一切内容都会渲染到“Surface”。Surface 表示缓冲队列中的生产方，而缓冲队列通常会被 SurfaceFlinger 消耗。在 Android 平台上创建的每个窗口都由 Surface 提供支持。所有被渲染的可见 Surface 都被 SurfaceFlinger 合成到显示部分。
图片1
IMAGE STREAM PRODUCTERS:
图像流生产方可以是生成图形缓冲区以供消耗的任何内容。例如 OpenGL ES、Canvas 2D 和 mediaserver 视频解码器。
IMAGE STREAM CONSUMERS:
图像流的最常见消耗方是 SurfaceFlinger，该系统服务会消耗当前可见的 Surface，并使用窗口管理器中提供的信息将它们合成到显示部分。SurfaceFlinger 是可以修改所显示部分内容的唯一服务。SurfaceFlinger 使用 OpenGL 和 Hardware Composer 来合成一组 Surface。
其他 OpenGL ES 应用也可以消耗图像流，例如相机应用会消耗相机预览图像流。非 GL 应用也可以是使用方，例如 ImageReader 类。
HAL:
显示子系统的硬件抽象实现。SurfaceFlinger 可以将某些合成工作委托给 Hardware Composer，以分担 OpenGL 和 GPU 上的工作量。SurfaceFlinger 只是充当另一个 OpenGL ES 客户端。因此，在 SurfaceFlinger 将一个或两个缓冲区合成到第三个缓冲区中的过程中，它会使用 OpenGL ES。这样使合成的功耗比通过 GPU 执行所有计算更低。
图片2
BufferQueue
BufferQueues 是 Android 图形组件之间的粘合剂。它们是一对队列，可以调解缓冲区从生产方到消耗方的固定周期。一旦生产方移交其缓冲区，SurfaceFlinger 便会负责将所有内容合成到显示部分。
图片3
生产者和消费者运行在不同的进程.
- 生产者请求一块空闲的缓存区:dequeueBuffer()
- 生产者填充缓存区并返回给队列: queueBuffer()
- 消费者获取一块缓存区: acquireBuffer()
- 消费者使用完毕,则返回给队列: releaseBuffer()
BufferQueue 包含将图像流生产方与图像流消耗方结合在一起的逻辑。图像生产方的一些示例包括由相机 HAL 或 OpenGL ES 游戏生成的相机预览。图像消耗方的一些示例包括 SurfaceFlinger 或显示 OpenGL ES 流的另一个应用，如显示相机取景器的相机应用。
BufferQueue 是将缓冲区池与队列相结合的数据结构，它使用 Binder IPC 在进程之间传递缓冲区。生产方接口，就是分配buffer, 提供上层生成数据内容，即是 IGraphicBufferProducer
BufferQueue 通常用于渲染到 Surface，并且与 GL 消耗（看图片1）方及其他任务一起消耗内容。BufferQueue 可以在三种不同的模式下运行
-
类同步模式
默认情况下，BufferQueue 在类同步模式下运行，在该模式下，从生产方进入的每个缓冲区都在消耗方那退出。在此模式下不会舍弃任何缓冲区。如果生产方速度太快，创建缓冲区的速度比消耗缓冲区的速度更快，它将阻塞并等待可用的缓冲区。 -
非阻塞模式
BufferQueue 还可以在非阻塞模式下运行，在此类情况下，它会生成错误，而不是等待缓冲区。在此模式下也不会舍弃缓冲区。这有助于避免可能不了解图形框架的复杂依赖项的应用软件出现潜在死锁现象。 -
舍弃模式
最后，BufferQueue 可以配置为丢弃旧缓冲区，而不是生成错误或进行等待。例如，如果对纹理视图执行 GL 渲染并尽快绘制，则必须丢弃缓冲区。
为了执行这项工作的大部分环节，SurfaceFlinger 就像另一个 OpenGL ES 客户端一样工作。例如，当 SurfaceFlinger 正在积极地将一个缓冲区或两个缓冲区合成到第三个缓冲区中时，它使用的是 OpenGL ES。
Hardware Composer HAL 执行另一半工作。该 HAL 充当所有 Android 图形渲染的中心点。
2-SurfaceFlinger 总体架构
图片.png
- 2.1 SurfaceFlinger（SF) client
frameworks/native/libs/gui/SurfaceComposerClient.cpp
下面的调用就是举例，其他的函数类似
ScreenshotClient::update
sp<ISurfaceComposer> s(ComposerService::getComposerService()); //获取ServiceFlinger server
s->captureScreen //由client 经过binder, 进入了SF server 端
- 2.2 SurfaceFlinger（SF) server
frameworks/native/services/surfaceflinger/DisplayHardware/
#SF 设计HAL 效率，使用了commandbuffer 写命令, service--->HAL client
//frameworks/native/services/surfaceflinger/DisplayHardware/ComposerHal.cpp
Error Composer::execute()
--->mClient->setInputCommandQueue //mClient 是HAL 代理，经过vbinder调用
--->ComposerClient::setInputCommandQueue
//hardware/interfaces/graphics/composer/2.1/default/ComposerClient.cpp
ComposerClient::setInputCommandQueue
- 2.3 HAL
这个路径是HAL, device 是由 hw_module_t* 注册，也就是hardware/qcom/display/sdm/ 路径下实现来的
hardware/interfaces/graphics/composer/2.1/default/
load 不同的vendor实现，如果是HWC2 适配，HWC1.X 则需要调用:frameworks/native/libs/hwc2on1adapter 进行适配
vendor init 时候初始化了，设备能力:----》mDevice->getFunction(mDevice, desc);
mDevice： 这个是实例化后的hwc2_device_t， 因此可以调用到vendor(2.4 章节getFunction )具体的getFunction实现
########
command buffer base ==>>>>>>>针对提高效率设计, surfacefinger端进行继承， HAL也进行继承。
frameworks/native/services/surfaceflinger/DisplayHardware/ComposerHal.cpp: Composer::setLayerZOrder----->>>>
hardware/interfaces/graphics/composer/2.1/default/IComposerCommandBuffer.h HAL 端
########
- 2.4 vendor 实现
vendor:实现 ，继承hwc2_device_t， 进行了实现
hardware/qcom/display/sdm/libs/hwc2/hwc_session.cpp
131 HWCSession::HWCSession(const hw_module_t *module) {
132 hwc2_device_t::common.tag = HARDWARE_DEVICE_TAG;
133 hwc2_device_t::common.version = HWC_DEVICE_API_VERSION_2_0;
134 hwc2_device_t::common.module = const_cast<hw_module_t *>(module);
135 hwc2_device_t::common.close = Close;
136 hwc2_device_t::getCapabilities = GetCapabilities;
137 hwc2_device_t::getFunction = GetFunction;---->这个函数是重点
138 }
REF:
https://source.android.com/devices/graphics/
https://blog.csdn.net/a740169405/article/details/70548443?utm_source=blogxgwz0
网友评论