2. Buffer队列基础：Buffer的概念、GraphicBuffer与MetadataBuffer、Buffer分配与释放机制

在Camera HAL框架中，Buffer是贯穿图像采集、处理、显示与编码的核心数据载体。理解Buffer的本质、类型划分以及生命周期管理，是掌握后续Buffer队列调度与帧同步优化的前提。本章从Buffer的基本概念出发，深入剖析GraphicBuffer与MetadataBuffer的差异，并详细阐述Buffer的分配与释放机制。

2.1 Buffer的基本概念

Buffer在操作系统层面是一段连续的物理或虚拟内存区域，用于临时存储数据。在Camera HAL上下文中，Buffer特指用于承载图像帧数据或元数据的预分配内存块。其核心属性包括：

• 内存区域： 通常分配在共享内存（如ION/DMA-BUF）中，支持跨进程（App、HAL、Server）零拷贝访问。
• 生命周期： 由Buffer队列管理，经历“空闲 → 入队 → 出队 → 处理 → 释放/回填”的循环。
• 同步机制： 通过Fence（同步栅栏）确保生产者与消费者之间的数据完整性。

2.2 GraphicBuffer与MetadataBuffer

Camera Pipeline中主要存在两类Buffer：GraphicBuffer 和 MetadataBuffer。它们在数据内容、内存布局、使用方式上存在本质区别。

2.2.1 GraphicBuffer

GraphicBuffer是承载图像像素数据的Buffer。它由Android的Gralloc模块分配，支持多种图像格式（如NV12、YUV420、RAW10等），并具备硬件合成器（HWC）和显示子系统直接消费的能力。

• 数据内容： 像素数据（YUV/RGB/RAW）。
• 内存布局： 包含多个平面（Plane），每个平面有独立的stride（跨距）和offset（偏移）。
• 典型用途： 预览帧、拍照帧、视频编码输入帧。
• 生命周期： 由Gralloc分配，通过BufferQueue在生产者（Camera HAL）和消费者（Display/Encoder）之间流转。

2.2.2 MetadataBuffer

MetadataBuffer是承载帧相关控制参数和统计信息的Buffer。它通常是一个固定大小的内存块，内部封装了标准的Camera元数据（如AE/AWB/AF状态、传感器时间戳、ISP统计数据等）。

• 数据内容： 结构化元数据（Key-Value对或二进制blob）。
• 内存布局： 连续内存，内部按Camera3规范定义的tag组织。
• 典型用途： 帧同步、3A算法输入、后处理参数传递。
• 生命周期： 由Camera HAL分配，与对应的GraphicBuffer绑定，一起在Pipeline中传递。

2.3 Buffer分配与释放机制

Buffer的分配与释放是Buffer队列管理的基石。在Camera HAL中，Buffer分配遵循“预分配、按需复用、延迟释放”的原则，以最小化运行时开销。

2.3.1 分配时机与策略

Buffer分配通常发生在以下两个阶段：

1. Stream配置阶段： 当App通过configureStreams()配置数据流时，HAL根据分辨率、格式、数量等参数一次性分配所有Buffer。
2. 运行时按需分配： 某些场景（如ZSL、HDR）需要额外的Buffer池，HAL会在运行时动态扩展池大小。

2.3.2 分配流程（以GraphicBuffer为例）

GraphicBuffer的分配流程涉及HAL、Gralloc和ION驱动三个层次：

1. HAL发起请求： Camera HAL调用Gralloc的allocate()接口，传入宽度、高度、格式、usage标志（如SW_READ_OFTEN、HW_COMPOSER）。
2. Gralloc解析参数： Gralloc根据usage标志选择底层分配器（ION、DMA-BUF或自定义）。
3. ION分配物理内存： ION驱动在系统堆或Carveout堆中分配连续的物理内存，并返回一个文件描述符（fd）。
4. 映射到HAL进程： HAL通过mmap()将ION fd映射到进程虚拟地址空间，获取CPU访问指针。
5. 封装为GraphicBuffer： Gralloc将分配的内存信息（fd、stride、offset、size）封装成GraphicBuffer对象，返回给HAL。

// 伪代码：GraphicBuffer 分配流程
status_t allocateGraphicBuffer(uint32_t width, uint32_t height, 
                                uint32_t format, uint64_t usage,
                                buffer_handle_t *outHandle) {
    // 1. 调用 Gralloc 分配器
    status_t err = gralloc->allocate(width, height, format, usage, outHandle);
    if (err != OK) return err;

    // 2. 获取 ION fd 和 stride
    int fd = outHandle->data[0];
    uint32_t stride = outHandle->stride;

    // 3. 映射到进程空间（可选，用于 CPU 访问）
    void *cpuPtr = mmap(NULL, getSize(width, height, format), 
                        PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    if (cpuPtr == MAP_FAILED) {
        gralloc->free(*outHandle);
        return NO_MEMORY;
    }

    // 4. 记录分配信息
    mBufferMap[outHandle] = {fd, cpuPtr, stride};
    return OK;
}

2.3.3 释放机制

Buffer释放遵循“引用计数 + 延迟回收”机制，确保所有消费者都完成使用后才真正释放内存。

• 引用计数： 每个Buffer维护一个引用计数。当HAL、App、Display等客户端释放Buffer时，计数减1。当计数降为0时，触发实际释放。
• 延迟回收： 释放操作不会立即归还给系统，而是将Buffer标记为“空闲”，放回Buffer池中复用。只有当Buffer池缩容或系统内存压力大时，才真正释放物理内存。
• Fence同步： 在释放前，必须等待所有关联的Fence信号完成，确保GPU或ISP不再访问该Buffer。

2.3.4 常见问题与避坑

• Buffer泄漏： 引用计数未正确递减，导致Buffer永远无法释放。常见于异常分支未处理returnBuffer()调用。
• Fence死锁： 释放Buffer时等待Fence超时，导致线程阻塞。需要设置合理的Fence超时阈值（通常100ms）。
• 内存碎片： 频繁分配释放不同大小的Buffer会导致ION堆碎片。解决方案是使用固定大小的Buffer池，避免运行时动态调整。
• 跨进程fd泄漏： 通过Binder传递Buffer fd时，如果接收方没有正确关闭fd，会导致fd泄漏。建议使用智能指针或RAII机制管理fd生命周期。