Android SurfaceFlinger做Layer合成时，如何与HAL层进行交互

零、本文讨论问题的范围

上图表示了，Surface 如何被渲染。
借用官网的一段话：“无论开发者使用什么渲染 API，一切内容都会渲染到 Surface 上。Surface 表示缓冲区队列中的生产方，而缓冲区队列通常会被 SurfaceFlinger 消耗。在 Android 平台上创建的每个窗口都由 Surface 提供支持。所有被渲染的可见 Surface 都被 SurfaceFlinger 合成到屏幕。”

本文关注的范围是上图红框中部分，SurfaceFlinger做Layer合成时，如何与HAL层的交互？

一、问题：SurfaceFlinger图层合成选择实现方式的两难

在处理Layer合成时，SurfaceFlinger会与OpenGL ES、HWC进行交互。对于HWC，由于各OEM的实现不一样，所支持的能力也不一样，很难直接用API表示硬件设备支持合成的Layer数量，Layer是否可以进行旋转和混合模式操作，以及对图层定位和硬件合成的限制等。这就导致了SurfaceFlinger作为调用端，很难做决策：根据当前的要合成的Layer数量，数据量大小，我该选择使用OpenGL ES？还是HWC？

1.1 从OpenGL ES、HWC本身来讲

在Android系统中，相对于HWC，OpenGL ES并不很擅长Layer的合成。
因为OpenGL ES主要是为游戏开发和图形渲染而设计的，它并不针对图层合成进行优化。如果使用OpenGL ES进行图层合成，会占用大量的GPU资源，导致应用程序无法使用GPU进行自己的渲染。因此，在需要进行高效图层合成的场景下，HWC更适合使用。

1.2 以HWC为主导的判断逻辑

既然各OEM提供的HWC的能力是不同的，有强、有弱，但Layer合成任务又想优先使用HWC，那么SurfaceFlinger的选择策略就交给HWC判断好了：
SurfaceFlinger根据HWC硬件能力决定使用OpenGL ES还是使用HWC来处理Layer合成任务。

具体逻辑如下：
SurfaceFlinger向HWC提供所有Layer的完整列表，让HWC根据其硬件能力决定如何处理这些Layer。
HWC会为每个Layer标注合成方式，是通过GPU还是通过HWC合成。
SurfaceFlinger负责先把所有注明GPU合成的Layer合成（使用OpenGL ES）到一个输出Buffer，然后把这个输出Buffer和其他注明HWC合成的Layer一起交给HWC，让HWC完成剩余Layer的合成和显示。

二、SurfaceFlinger与HAL层进行交互的具体实现框架

2.1 SurfaceFlinger 调用 OpenGL ES 流程

Gralloc 即 Graphics Alloc 图形分配 。 Android 系统在HAL层中提供了一个 Gralloc 模块，封装了对 Framebuffer 的所有访问操作。
Gralloc 模块包含 fb 和 gralloc 两个设备：fb 负责打开内核中的 Framebuffer 、初始化配置，以及提供 post, setSwapInterval 等操作，它是底层显卡的HAL层抽象；gralloc 则管理帧缓冲区的分配和释放，上层应用只能通过 Gralloc 访问 fb。

Android12 的源码中，HAL层头文件定义的路径在：源码根目录/hardware/libhardware/include/hardware/*.h

2.2 FrameBuffer

FrameBuffer 机制模仿显卡的功能，是显卡硬件的抽象，可以将 FrameBuffer 看成是显存的一个映像，将其映射到进程地址空间之后，就可以直接进行读写操作，简单理解就是一段内存。用户应用不停的向这段内存中写入数据，显示控制器不停地从中读取数据并显示出来。

2.3 SurfaceFlinger 调用 HWC 的流程

三、通过HAL定义，理解上述概念

3.1 hwcomposer.h

上面我们提到HWC会为每个Layer标注合成方式

typedef struct hwc_layer_1 {
	int32_t compositionType;
}

结构体 hwc_layer_1 中，定义了一个 compositionType 变量，表示当前Layer 的合成类型。可选的常量有 HWC_BACKGROUND、HWC_FRAMEBUFFER_TARGET、HWC_FRAMEBUFFER、HWC_OVERLAY、HWC_SIDEBAND、HWC_CURSOR_OVERLAY。
其中：HWC_FRAMEBUFFER，是这么注释的（节选）：

     *   Set by the HWC implementation during (*prepare)(), this indicates
     *   that the layer will be drawn into the framebuffer using OpenGL ES.

HWC在准备阶段，可能会将Layer的类型设置成 HWC_FRAMEBUFFER，表示这个Layer会使用OpenGL ES画到 framebuffer 中。
再看 HWC_BACKGROUND

     *   Always set by the caller before calling (*prepare)(), this value
     *   indicates this is a special "background" layer. The only valid field
     *   is backgroundColor.
     *   The HWC can toggle this value to HWC_FRAMEBUFFER to indicate it CANNOT
     *   handle the background color.

总是由调用者在调用(*prepare)()之前设置这个值，表示这是一个特殊的“背景”图层。唯一有效的字段 backgroundColor。HWC可以将此值切换为HWC_FRAMEBUFFER来表示它不能处理背景颜色（HWC处理不了，就只能是用OpenGl ES来处理）。这里的调用者应该就是SurfaceFlinger了。

Hardware Composer 必须支持事件，其中之一是 VSYNC（另一个是支持即插即用 HDMI 的热插拔）

3.2 fb.h

我们抽出几个属性，有个大体印象

typedef struct framebuffer_device_t {
    /* dimensions of the framebuffer in pixels */
    const uint32_t  width;
    const uint32_t  height;

    /* framebuffer pixel format */
    const int       format;

    /* resolution of the framebuffer's display panel in pixel per inch*/
    const float     xdpi;
    const float     ydpi;

    /* framebuffer's display panel refresh rate in frames per second */
    const float     fps;
    ......
}

FrameBuffer设备的属性有：宽高、像素格式、以dip为单位的分辨率、fps。
再看一个方法：

    /*
     * Post  to the display (display it on the screen)
     * The buffer must have been allocated with the
     *   GRALLOC_USAGE_HW_FB usage flag.
     * buffer must be the same width and height as the display and must NOT
     * be locked.
     *
     * The buffer is shown during the next VSYNC.
     *
     * Returns 0 on success or -errno on error.
     */
    int (*post)(struct framebuffer_device_t* dev, buffer_handle_t buffer);

post函数会将 buffer post到display上，显示在屏幕上。
buffer的宽度要与fb设备宽高一致，不能被锁。
在下一个VSYNC信号到来时，buffer会显示出来。

3.3 gralloc.h

/**
 * Name of the graphics device to open
 */
#define GRALLOC_HARDWARE_GPU0 "gpu0"

看出 gralloc操作的设备就是GPU

enum {
    /* buffer will be used as an OpenGL ES texture */
    GRALLOC_USAGE_HW_TEXTURE            = 0x00000100U,
    /* buffer will be used as an OpenGL ES render target */
    GRALLOC_USAGE_HW_RENDER             = 0x00000200U,
    /* buffer will be used by the 2D hardware blitter */
    GRALLOC_USAGE_HW_2D                 = 0x00000400U,
    /* buffer will be used by the HWComposer HAL module */
    GRALLOC_USAGE_HW_COMPOSER           = 0x00000800U,
    /* buffer will be used with the framebuffer device */
    GRALLOC_USAGE_HW_FB                 = 0x00001000U,
    /* buffer may be used as a cursor */
    GRALLOC_USAGE_CURSOR                = 0x00008000U,
    /* buffer will be used with the HW video encoder */
    GRALLOC_USAGE_HW_VIDEO_ENCODER      = 0x00010000U,
    /* buffer will be written by the HW camera pipeline */
    GRALLOC_USAGE_HW_CAMERA_WRITE       = 0x00020000U,
    /* buffer will be read by the HW camera pipeline */
    GRALLOC_USAGE_HW_CAMERA_READ        = 0x00040000U,
    ......
}

gralloc graphics allocation字面意思图形分配，其实就是开辟一段内存，操作的是GPU那就是显存。
这里定义了一个枚举，为分配出的 buffer 标记了分类，按使用用途分出的类别。
这里有做为 OpenGL ES texture 使用的、被 HWComposer HAL module 使用的、被硬件视频编码器使用的、被摄像头管道写入/读出的。还发现一个有意思的是，GRALLOC_USAGE_CURSOR 光标竟然是单独一种类型的 buffer。

核心方法：

typedef struct alloc_device_t {
    struct hw_device_t common;
    /* 
     * (*alloc)() Allocates a buffer in graphic memory with the requested
     * parameters and returns a buffer_handle_t and the stride in pixels to
     * allow the implementation to satisfy hardware constraints on the width
     * of a pixmap (eg: it may have to be multiple of 8 pixels). 
     * The CALLER TAKES OWNERSHIP of the buffer_handle_t.
     *
     * If format is HAL_PIXEL_FORMAT_YCbCr_420_888, the returned stride must be
     * 0, since the actual strides are available from the android_ycbcr
     * structure.
     * 
     * Returns 0 on success or -errno on error.
     */
    
    int (*alloc)(struct alloc_device_t* dev,
            int w, int h, int format, int usage,
            buffer_handle_t* handle, int* stride);

这个方法就是分配显存，传入参数 宽、高、格式、使用用途。返回 buffer_handle_t、步长。

上述对 HAL层头文件简单浏览，有助于我们对这几个概念有更深的印象。