4. Camera HAL 架构详解:HAL3 vs HAL1 对比、CameraProvider、CameraDevice、CameraStream、Pipeline 模型

在集成第三方算法库之前,必须深入理解 Camera HAL 的架构层次。本章将系统对比 HAL1 与 HAL3 的核心差异,并逐一剖析 CameraProvider、CameraDevice、CameraStream 以及 Pipeline 模型的设计原理。这些概念是后续实现算法注入、buffer 管理和流配置的基础。

4.1 HAL1 vs HAL3:架构演进与核心差异

Android Camera HAL 从 HAL1 演进到 HAL3,本质是从“固定管线”到“可编程管线”的转变。HAL1 适用于简单场景,而 HAL3 为多帧、多流、算法集成提供了必要的基础设施。

对比维度 HAL1 HAL3
操作模式 单线程、同步预览/拍照 多线程、异步请求/响应
Buffer 管理 HAL 内部管理,Framework 被动接收 Framework 通过 CaptureRequest 下发 buffer,HAL 填充后返回
流(Stream)支持 最多 2 路(预览 + 拍照) 支持多路并发(预览、拍照、视频、YUV、RAW 等)
元数据(Metadata) 有限,通过固定参数传递 丰富的 CameraMetadata,支持 3A、AE/AWB/AF 精细控制
算法集成 困难,需修改 HAL 内部管线 容易,通过自定义 CaptureRequest 和 Result 注入算法参数
性能开销 低,但灵活性差 较高,但可针对场景优化
工程建议: 对于集成第三方算法库(如美颜、HDR、夜景增强),必须使用 HAL3。HAL1 的固定管线无法支持多流并发和逐帧参数控制,算法注入将导致严重的性能退化或功能缺失。
兼容性提示: 部分低端平台仍默认使用 HAL1。在系统属性 persist.vendor.camera.hal1.enable 中可强制切换,但需验证 sensor 驱动和 ISP 的 HAL3 支持能力。

4.1.1 HAL1 架构示意图

HAL1 架构示意图 App / Framework HAL1 适配层 Sensor / ISP HAL1 关键特征: • 同步模型:preview() / takePicture() 阻塞调用 • 固定流:仅支持 preview 和 picture 两路 • Buffer 所有权:HAL 内部管理,Framework 无法直接控制 • 算法集成:需重写 HAL 内部管线,耦合度高 • 适用场景:低端设备、功能简单的摄像头

4.1.2 HAL3 架构示意图

HAL3 架构示意图 CameraService CameraProvider CameraDevice CameraStream CaptureRequest processCaptureRequest HAL 处理管线 CaptureResult HAL3 关键特征: • 异步模型:CaptureRequest 下发后立即返回,结果通过回调上报 • 多流并发:支持 preview / video / YUV / RAW / Depth 等多路同时输出 • Buffer 所有权:Framework 管理 buffer 池,HAL 只负责填充 • 算法集成:通过自定义 metadata 和 buffer 操作,可灵活注入第三方算法 • 适用场景:中高端设备、多摄像头、算法增强

4.2 CameraProvider:HAL 的入口与生命周期管理

CameraProvider 是 Camera HAL 在 Android 系统中的入口点,负责枚举摄像头设备、管理 HAL 服务生命周期,并对外提供统一的 ICameraProvider 接口。在 Treble 架构下,CameraProvider 运行在独立的 HAL 进程中,与 CameraService 通过 HIDL / AIDL 通信。

4.2.1 CameraProvider 核心职责

  • 设备枚举: 调用 getCameraIdList() 返回所有可用摄像头 ID。
  • 设备创建: 通过 getCameraDeviceInterface() 返回 ICameraDevice 实例。
  • 服务生命周期: 管理 HAL 进程的启动、初始化、异常恢复和关闭。
  • 版本协商: 支持 HAL1 / HAL3 接口版本切换,兼容不同平台。

4.2.2 CameraProvider 接口定义(AIDL 示例)

// ICameraProvider.aidl
interface ICameraProvider {
    /**
     * 获取所有摄像头 ID 列表
     */
    String[] getCameraIdList();

    /**
     * 根据摄像头 ID 创建 CameraDevice 接口
     * @param cameraId 摄像头 ID
     * @return ICameraDevice 实例
     */
    ICameraDevice getCameraDeviceInterface(String cameraId);

    /**
     * 设置回调,用于通知 CameraService 设备热插拔事件
     */
    void setCallback(ICameraProviderCallback callback);
}
常见问题: 在集成第三方算法库时,CameraProvider 层通常不需要修改。但如果算法需要独占某个硬件资源(如 ISP 或 DSP),则需在 Provider 层增加资源管理逻辑,防止多摄像头同时访问冲突。

4.3 CameraDevice:摄像头实例与流配置

CameraDevice 代表一个具体的摄像头硬件实例,负责处理 CaptureRequest 的接收、流(Stream)的配置、以及 CaptureResult 的回调。每个 CameraDevice 对应一个物理摄像头(或逻辑摄像头)。

4.3.1 CameraDevice 核心接口

接口方法 功能描述 算法集成相关
configureStreams() 配置输出流(预览、拍照、视频等) 算法库需要指定输入/输出格式(如 YUV、RAW)
processCaptureRequest() 下发单帧或批量 CaptureRequest 算法参数通过 metadata 注入
flush() 清空所有待处理的请求队列 算法库需支持中断和快速恢复
close() 释放摄像头资源 算法库需释放 GPU / DSP 内存

4.3.2 CameraDevice 状态机

CameraDevice 状态机 UNINITIALIZED INITIALIZED STREAMING ERROR open() configureStreams() flush() / close() 异常

4.4 CameraStream:数据流与 Buffer 管理

CameraStream 是 HAL3 中数据流的核心抽象,代表一条从 sensor 到输出 buffer 的数据通道。每个 Stream 包含格式、分辨率、使用场景(preview / video / still_capture)等属性。多个 Stream 可以同时存在,形成多路并发。

4.4.1 Stream 配置参数

// Stream 配置结构体(C++ 示例)
struct CameraStreamConfig {
    uint32_t width;          // 宽度(像素)
    uint32_t height;         // 高度(像素)
    int32_t format;          // 格式:HAL_PIXEL_FORMAT_YCbCr_420_888 / HAL_PIXEL_FORMAT_BLOB
    int32_t usage;           // 使用场景:GRALLOC_USAGE_HW_CAMERA_WRITE / GRALLOC_USAGE_HW_TEXTURE
    int32_t rotation;        // 旋转角度
    int32_t stream_type;     // CAMERA_STREAM_OUTPUT / CAMERA_STREAM_INPUT
};

4.4.2 多流并发示例

Stream ID 用途 格式 分辨率 Buffer 数量
0 预览 YCbCr_420_888 1920x1080 3
1 拍照 BLOB (JPEG) 4000x3000 2
2 视频 YCbCr_420_888 1920x1080 4
3 算法输入 YCbCr_420_888 640x480 2
算法集成要点: 第三方算法库通常需要独立的 YUV 输入流(Stream ID 3)。该流与预览流共享 sensor 数据,但分辨率更低,用于人脸检测、场景识别等预处理。通过 configureStreams() 一次性配置所有流,避免运行时动态增减。

4.5 Pipeline 模型:请求处理与数据流

Pipeline 模型 是 HAL3 处理 CaptureRequest 的核心机制。每个请求在 HAL 内部经过“解析 → 硬件处理 → 后处理 → 返回结果”的流水线。Pipeline 模型支持多请求并发、乱序返回,以及灵活的算法插入点。

4.5.1 Pipeline 处理流程

Pipeline 处理流程 Request 解析 解析 metadata Sensor 曝光 AE / AWB / AF ISP 处理 RAW → YUV 算法注入点 第三方算法 编码 / 压缩 JPEG / H.264 Result 组装 metadata + buffer 回调上报 processCaptureResult Pipeline 模型关键特性: • 每个 CaptureRequest 独立经过 Pipeline,支持乱序返回(out-of-order) • 算法注入点位于 ISP 处理后、编码压缩前,此时数据为 YUV 格式,最适合算法处理

4.5.2 Pipeline 模型中的算法集成策略

  1. 预处理阶段: 在 ISP 输出 YUV 后,立即调用第三方算法库(如降噪、HDR 融合)。
  2. 后处理阶段: 在编码压缩前,对 YUV 数据进行美颜、滤镜等处理。
  3. Metadata 传递: 算法参数通过 CaptureRequest 的 metadata 字段传递,避免全局变量。
  4. Buffer 管理: 算法库直接操作 GraphicBuffer 或 ANativeWindowBuffer,减少内存拷贝。
工程案例: 某旗舰机型集成 AI 美颜算法时,在 Pipeline 的 ISP 后处理阶段插入自定义节点。算法库接收 YUV 格式的 buffer,输出处理后的 YUV buffer,然后继续走 JPEG 编码流程。整个过程通过 processCaptureRequest 的 metadata 控制美颜等级,无需修改 Framework 上层代码。

4.6 本章小结