1. Camera HAL 概述：架构位置、作用与核心差异

Camera HAL（Hardware Abstraction Layer）是 Android 相机系统中连接 Framework 与底层硬件驱动的关键中间层。它定义了统一的接口规范，使上层应用无需关心具体传感器、ISP 或平台差异，同时为 OEM 厂商提供硬件适配的标准化入口。本章从系统架构位置、核心职责以及 HAL1 与 HAL3 的演进差异三个维度展开，为后续性能优化与帧率抖动分析奠定基础。

1.1 HAL 在 Android 相机系统中的位置与作用

在 Android 相机软件栈中，HAL 位于 Camera Service（运行于 cameraserver 进程）与 Kernel Driver 之间。其核心作用包括：

• 接口标准化：向上提供 camera_module_t、camera_device_t 等统一结构体，向下屏蔽不同 SoC（Qualcomm、MTK、Exynos 等）的硬件差异。
• 流管理：处理来自 Framework 的打开/关闭、配置流、请求捕获等指令，并将其转换为硬件可执行的底层操作。
• 缓冲区管理：协调 Graphic Buffer 的分配、填充与传递，确保预览/拍照/录像数据流在 HAL、SurfaceFlinger 和 MediaServer 之间高效流转。
• 3A 与元数据传递：将底层 AE/AWB/AF 状态封装为 camera_metadata_t 上报给 Framework，同时接收应用下发的控制参数。

1.2 HAL1 vs HAL3：核心差异对比

HAL1 是 Android 4.0 引入的传统接口，HAL3 随 Android 5.0 的 Camera2 API 一同推出。两者在设计哲学、流模型、控制粒度上存在本质区别。下表从工程落地角度进行对比：

1.3 HAL3 请求-响应模型与帧率抖动的关系

HAL3 的核心是 逐帧请求 模型。Framework 下发 CaptureRequest，HAL 通过 process_capture_request 接收并处理，最终通过 notify 和 process_capture_result 返回结果。这一模型直接影响了帧率的稳定性：

• Request 排队：HAL 必须按序处理 request，若某一帧处理超时（如 3A 收敛慢、ISP 管线阻塞），后续帧会累积延迟，导致帧率骤降。
• Fence 同步：HAL 在填充 output buffer 前需等待 input buffer 的 fence 信号。若 fence 信号延迟（如 GPU 或显示管线繁忙），会导致 HAL 空等，产生帧间隔抖动。
• Metadata 开销：每帧都需要解析和填充大量 metadata（如 AE 状态、AF 位置、统计信息），若 HAL 实现中 metadata 操作未优化，会引入微秒级到毫秒级的额外延迟。

1.4 从 HAL1 迁移到 HAL3 的工程考量

对于正在维护老平台（如 Android 7/8）的团队，从 HAL1 升级到 HAL3 需要关注以下适配点：

1. 流模型重构：HAL1 的 start_preview / take_picture 需要改为 configure_streams + process_capture_request 模式。
2. Metadata 管理：需要实现 camera_metadata_t 的构建、解析和缓存逻辑，避免每帧重复分配内存。
3. Fence 集成：如果底层驱动不支持 fence，需要在 HAL 层模拟同步逻辑，否则会出现 buffer 竞争导致的花屏或卡顿。
4. 性能摸底：在迁移初期，建议使用 perfetto 或 systrace 抓取 HAL3 的 process_capture_request 耗时分布，建立基线数据。

1.5 本章小结