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 注入算法参数 |
| 性能开销 | 低,但灵活性差 | 较高,但可针对场景优化 |
persist.vendor.camera.hal1.enable 中可强制切换,但需验证 sensor 驱动和 ISP 的 HAL3 支持能力。
4.1.1 HAL1 架构示意图
4.1.2 HAL3 架构示意图
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);
}
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 状态机
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 |
configureStreams() 一次性配置所有流,避免运行时动态增减。
4.5 Pipeline 模型:请求处理与数据流
Pipeline 模型 是 HAL3 处理 CaptureRequest 的核心机制。每个请求在 HAL 内部经过“解析 → 硬件处理 → 后处理 → 返回结果”的流水线。Pipeline 模型支持多请求并发、乱序返回,以及灵活的算法插入点。
4.5.1 Pipeline 处理流程
4.5.2 Pipeline 模型中的算法集成策略
- 预处理阶段: 在 ISP 输出 YUV 后,立即调用第三方算法库(如降噪、HDR 融合)。
- 后处理阶段: 在编码压缩前,对 YUV 数据进行美颜、滤镜等处理。
- Metadata 传递: 算法参数通过
CaptureRequest的 metadata 字段传递,避免全局变量。 - Buffer 管理: 算法库直接操作
GraphicBuffer或ANativeWindowBuffer,减少内存拷贝。
processCaptureRequest 的 metadata 控制美颜等级,无需修改 Framework 上层代码。