Camera HAL 的历史演进：HAL1 vs HAL3 架构核心差异与开发实战

关键词：
Camera HAL、HAL1、HAL3、Android 架构演进、capture_request、pipeline_model、frame pipeline、open camera、实时预览、metadata

摘要：
Camera 硬件抽象层（HAL）是 Android 图像系统的重要中间层，承接了用户态 Framework 与内核驱动之间的数据与控制交互。本文从工程实战角度系统梳理 HAL1 到 HAL3 的架构演进背景、设计差异、接口变化与实际应用路径，解析 HAL3 引入的 Pipeline 模型如何解决并发访问、流管理与高帧率采集等问题，并对现有主流平台（如 QCOM、MTK、三星等）的适配策略进行对比分析，助力开发者高效完成 HAL 层的系统集成与定制优化。

目录

  1. Android Camera HAL 概览：从抽象接口到平台实现路径
  2. HAL1 架构解读：设计背景与结构组成
  3. HAL3 架构模型详解：Pipeline 化的设计核心
  4. HAL1 vs HAL3 核心接口差异与兼容性分析
  5. HAL3 中的关键组件：CaptureRequest、FrameNumber、PipelineDepth
  6. 多平台适配实战：高通、MTK、三星对 HAL3 的演进路径对比
  7. 工程经验总结：从 HAL1 移植到 HAL3 的注意事项与调试路径
  8. 发展趋势展望：基于 AOSP 未来演进的 Camera HAL 模块设计方向

第1章：Android Camera HAL 概览：从抽象接口到平台实现路径

在 Android 系统架构中，Camera HAL 作为 framework 与驱动之间的桥梁，负责封装硬件差异、提供标准接口并控制摄像头资源。其作用包括：

  • 映射 hardware module 到 camera service；
  • 管理 sensor 初始化、图像流控制与请求响应；
  • 实现从 APP 到 ISP、Sensor、Lens 的完整控制链条。

Android HAL 层的开发严格遵循 Google 提供的接口规范（见 hardware/interfaces/camera/ ），其中包括：

  • camera_module_t ：模块入口；
  • camera_device_t ：设备实例；
  • HAL1 中以 take_picture() 、 start_preview() 为核心；
  • HAL3 中以 process_capture_request() 为中心调度单元。

不同版本的 HAL 所实现的功能、接口风格与底层资源调度模型差异巨大，直接影响了图像质量、功耗、帧率与延迟等核心参数。

第2章：HAL1 架构解读：设计背景与结构组成

HAL1 最早出现在 Android 4.x 系列中，设计初衷是简化对传统 Sensor 的控制，支持典型的手机单摄需求，结构相对简单：

  • 每个功能入口对应一个函数（ start_preview() 、 take_picture() 、 auto_focus() ）；
  • 无 unified request 模型，控制流与数据流耦合严重；
  • preview 与 capture 分离执行，无法并发 pipeline 管理；
  • callback 机制过于依赖全局状态，易出现同步问题。

结构组成如下：

  • camera_module_t ：负责枚举 camera_id；
  • camera_device_t ：包含函数指针接口；
  • 调用路径为：APP → CameraService → HAL1 驱动 → V4L2/ISP。

典型平台实现如：早期 QCOM S805、MTK MT6589 等采用 HAL1，具有稳定但灵活性不足的特点，不适合多摄、并发拍摄等场景。

第3章：HAL3 架构模型详解：Pipeline 化的设计核心

HAL3 于 Android 5.0（Lollipop）正式引入，是为了解决 HAL1 架构在并发处理、高性能拍照、视频录制、低延迟预览等方面的瓶颈而设计的，其核心思路是以请求-响应模型替代指令式控制，采用流水线（Pipeline）机制管理图像数据流和控制流。

架构组成要点：

  • 模块结构：

    • camera3_device_ops 作为 HAL 接口核心，定义了 process_capture_request() 、 flush() 等操作；
    • camera3_device_t 结构中包含 priv 私有数据指针，便于厂商扩展；
    • 使用异步通知回调 camera3_callback_ops 实现 Frame 完成、错误报告等机制。

  • Pipeline 模型：

    • 每个 CaptureRequest 都是一次完整拍摄指令，携带 metadata（如 AE/AF 参数）与 output buffer；
    • HAL3 负责将请求入队、调度处理并通过 process_capture_result() 返回结果；
    • 支持多 output stream 并发（如 Preview + Video + Capture）；
    • 引入 frame_number 标识请求序列，确保结果有序交付。

优势：

  • 精细控制：支持帧级 AE/AF/AWB 设置；
  • 并发执行：可同时处理多个 Request，实现 HDR、多流录制；
  • 灵活扩展：支持 reprocess stream、ZSL 环境、RAW capture。

关键数据结构：

typedef struct camera3_capture_request {
    uint32_t frame_number;
    camera3_stream_buffer_t *output_buffers;
    const camera_metadata_t *settings;
} camera3_capture_request_t;

该结构成为 HAL3 与 framework 之间最重要的控制单元，推动从面向操作转向面向帧的架构演进。

第4章：HAL1 vs HAL3 核心接口差异与兼容性分析

对比维度HAL1 架构HAL3 架构
控制机制函数式调用，如 take_picture()请求-响应模型， process_capture_request()
执行模式串行，Preview/Capture 分离并发，支持多 Stream
参数传递单次配置，无法帧级切换帧级 Metadata 灵活控制
Callback 回调多个函数回调入口统一使用 camera3_callback_ops
架构扩展性差，难支持 ZSL/HDR/RAW好，天然支持 Pipeline 与复杂模式

兼容性处理：

  • Android Framework 在运行时对 Camera HAL 版本做识别，支持 HAL1 和 HAL3 并存；
  • Google 定义了 Legacy 模式（HAL1 映射为 HAL3 接口）用于兼容老平台，但功能受限；
  • 多数现代设备已强制使用 HAL3，以支持 Camera2 API 的高级能力（如手动对焦、RAW 拍摄等）。

工程启示：

  • 若项目采用旧平台或无法支持 Pipeline，HAL1 可作为兼容方案；
  • 对于需要 ZSL、高帧率、人像虚化、AI 摄影等功能的系统，HAL3 是必选路径；
  • HAL3 的实现建议配合异步线程模型，避免阻塞 process_capture_request 流程，提升帧处理效率。

第5章：HAL3 中的关键组件：CaptureRequest、FrameNumber、PipelineDepth

在 HAL3 架构中，流水线式的数据与控制调度模型对系统稳定性和性能提出更高要求。以下为三个关键组件在工程实践中的核心作用及其交互逻辑：

1. CaptureRequest ：帧级控制的核心入口

camera3_capture_request_t 是 HAL3 设计的基本操作单元，每一个请求对应一帧图像处理任务。其内部结构包括：

  • frame_number ：请求编号，用于维持顺序。
  • settings ：本帧控制参数（metadata）。
  • output_buffers[] ：输出目标（preview/capture/video）。
typedef struct camera3_capture_request {
    uint32_t frame_number;
    const camera_metadata_t *settings;
    uint32_t num_output_buffers;
    camera3_stream_buffer_t *output_buffers;
} camera3_capture_request_t;

注意点：

  • settings 为 NULL 时，HAL 需复用上一次配置；
  • output_buffers 可含多目标（如 preview + JPEG），HAL 必须保持独立处理与回调。

2. frame_number ：队列顺序与输出顺序绑定核心

HAL3 的异步特性要求严格的帧顺序管理，Android 框架通过 frame_number 保证每一帧请求与对应结果的准确匹配。典型工作流如下：

  • process_capture_request() 提交请求；
  • HAL 异步完成处理后，调用 process_capture_result() 返回；
  • 返回结构体中需带有相应的 frame_number 以供 framework 正确映射。

场景举例：

  • 拍照时异步处理慢，Preview 帧先完成，此时返回顺序必须通过 frame_number 对齐；
  • 若丢帧或错误帧，也需发送错误状态且保持编号同步。

3. pipeline_depth ：并发缓存与帧处理深度控制

该字段指示 HAL 可同时处理的最大请求数（例如 pipeline 深度为 4，表示最多挂起 4 帧），需在 camera3_device_ops->initialize() 中返回。

工程影响：

  • 深度越高，吞吐能力越强，但内存占用也更高；
  • 若超出深度，framework 将等待 process_capture_result 回调释放 pipeline 空间；
  • 典型平台设置范围在 3~6 之间，需结合 ISP 与内存能力动态评估。

调试建议：

  • 使用 frame_number 打印 log 可快速排查帧乱序、丢失问题；
  • 观察 pipeline 满载时的帧延迟，验证流畅性是否受限；
  • pipeline_depth 值建议随场景（Preview vs Capture）动态调整，提升并发适应性。

第6章：多平台适配实战：高通、MTK、三星对 HAL3 的演进路径对比

当前主流 SoC 平台均基于 HAL3 架构进行适配，但底层实现策略、扩展能力和兼容机制差异显著，下面基于实际工程实践进行对比分析：

关键点高通（QCOM）联发科（MTK）三星（Exynos）
流水线模型支持深度优化 pipeline（基于 CAMSS 模块）基于 MtkCam3Pipeline 多线程调度架构Exynos ISP 独立 pipeline，深度高度可控
HAL3 扩展支持ZSL、MFNR、RAW、P2Reprocess 全面支持多数平台支持 ZSL、RAW，但部分低端平台受限部分旧平台兼容 HAL1 via shim adapter
Metadata 模块多模块聚合：AE、AF、ASD 分模块下发Metadata 类型更标准，但调试入口较封闭使用自定义 metadata 类型（Samsung tag）
ISP 协议层camera.postproc.* + camera.device.*AEELog/DebugUtils 日志机制优化较好基于 OneUI 框架自定义 HAL 模块接入层
调试接口支持 QACT 工具链 + vendor camera logsMeta ISP 工具支持 pipeline 级别调参CameraService 内部注入调试点，需授权解锁

实战案例补充：

  • QCOM 平台（SDM845、SM8250 等） ：通过 QCamera3HardwareInterface 实现对多个 stream pipeline 的精细调度。支持并发传感器、YUV + RAW 并流等能力。

  • MTK 平台（MT6789 等） ：在 vendor/mediatek/proprietary/hardware/mtkcam 路径下定义自有 Pipeline 控制器（如 CamIO3），封装复杂的 ISP 操作逻辑，调试需依赖 TuningTool 与工程固件。

  • 三星平台（Exynos 9825 / 2100） ：通常采用独立的 ExynosISP 控制芯片与内核接口，HAL 层做适配封装，通过 libexynoscamera 维护整体控制流。

第7章：工程经验总结：从 HAL1 移植到 HAL3 的注意事项与调试路径

Android Camera HAL 从 HAL1 到 HAL3 的演进不仅是接口层级的变化，更是整个图像采集、控制模型由同步走向异步、由单帧命令驱动走向 pipeline 编程范式的系统性重构。对于原生基于 HAL1 驱动或系统的厂商，在工程升级路径上需重点关注以下关键环节：

1. 控制与数据结构差异适配

  • HAL1 中调用流程为 takePicture() 式同步命令，HAL3 改为 process_capture_request() 异步 pipeline 提交；
  • HAL1 仅支持一个 preview_stream 与 snapshot ，HAL3 支持任意 stream 组合（YUV、RAW、DEPTH）并支持帧级 Metadata 控制；
  • HAL3 需实现多个回调接口，包括 process_capture_result() 、 notify() ，确保时序正确对齐。

建议： 原有 HAL1 中的参数逻辑需按帧粒度拆分封装入 metadata，避免集中设置引发控制冲突。

2. 帧调度逻辑重构

  • HAL1 以队列为核心，逐帧同步处理；
  • HAL3 构建 in-flight request 管理机制，多帧并发调度，需确保 frame_number 、 pipeline_depth 等管理合理。

风险点：

  • pipeline 未清空前误触发 stream_config ，可能导致 ISP 出现 stream_on 错误；
  • 多流（如 YUV+JPEG）合并回调时，metadata 必须回调一次，输出 buffer 分多次返回也要保持编号一致。

3. 调试路径与日志策略更新

  • HAL3 调试依赖 Camera3Device / CameraService 层的 callback 验证，无法直接通过 logcat 判定是否成功；
  • 可通过开启 vendor.camera.debug 系列属性，结合 frame_number 回调 log，建立完整帧调度链追踪；
  • 使用 dumpsys media.camera 查看 pipeline 是否满载， lsof 检查设备节点状态是否挂死。

4. HAL 层多平台抽象框架建议

工程建议对底层 Camera 驱动逻辑做 Platform Abstraction（PlatformOps），保持 sensor 控制、ISP 接入、Tuning 参数下发逻辑独立，便于：

  • 同一套 HAL 逻辑复用于 MTK/QCOM；
  • 避免平台迁移时重复适配；
  • 实现模块化 CameraAdapter。

典型移植问题汇总：

问题类型HAL1 → HAL3 移植场景排查建议
Stream 配置失败process_capture_request 不回调检查 configure_streams() 实现
拍照黑屏JPEG pipeline 未正确建立检查 HAL 返回的 JpegBuffer
Preview 卡顿pipeline depth 设置过小建议设置 ≥4，并动态调试
Metadata 不生效settings 指针错误注意 NULL 代表复用，不等于空参数

第8章：发展趋势展望：基于 AOSP 未来演进的 Camera HAL 模块设计方向

随着 Android 图像系统的持续演化，Camera HAL 模块也正逐步向更智能化、高可配置性与 AI 深度融合方向发展。

1. 多 pipeline 支持与帧并行调度

Android S 之后， Camera HAL3+ 模块正逐步原生支持 Multi-Pipeline 协议，通过 RequestQueue 协议将 Preview / Capture / ZSL 任务分离执行，提高低延迟高分辨率场景的响应能力。

趋势：面向 XR、SLAM 的 Camera 需具备高帧率低延迟 pipeline 分离机制。

2. AI 控制能力与 Sensor 协同增强

AOSP 提出基于 metadata 的扩展控制提案（如 VendorTag +AI Hint），未来 HAL 可支持：

  • 提前告知帧类型（action、低光等）；
  • Sensor 层与 AI 模型协同设定曝光曲线与对焦曲面；
  • 实现 AI 主导的控制流重建。

3. HAL 层模组化与抽象层提取

项目维度中出现了越来越多的 libcamera_hal_adapter 框架，旨在提供平台无关、参数可配置的 HAL 层通用适配模块，满足：

  • Camera 模组复用需求；
  • SoC 换代时快速对接 HAL；
  • AI 加速功能（HDR、超分）跨平台调用封装。

4. 可视化调试与配置工具趋势

新版本 AOSP Camera Service 已逐步引入 frame trace、dump 工具，未来开发者可通过图形化方式：

  • 查看每一帧的 metadata 变化；
  • 可视化 preview 与 capture pipeline 拓扑；
  • 结合 AI 工具进行多模组帧异步追踪与图像质量回溯。

总结

从 HAL1 到 HAL3，不仅是技术架构的升级，更是一个 Camera 模块智能化、平台化的进阶过程。面向未来，每一个具备 HAL3 能力的相机系统都需要：

  • 完整理解 pipeline 模型；
  • 建立 metadata 控制闭环；
  • 配合 SoC 与 AI 模型完成真正“感知驱动”的图像处理链路。

本文转自 https://jc-performance.cn//online/0410_148656019.html，如有侵权，请联系删除。