3. Camera HAL 版本演进:从 HAL1 到 HAL3.6 的架构变迁与选型指南

Android Camera HAL(硬件抽象层)自 Android 诞生以来经历了多次重大重构。理解各版本的演进逻辑、核心差异与适用场景,是选择正确 HAL 版本、设计高性能相机系统的前提。本章从 HAL1 的遗留设计讲起,逐步深入到 HAL3 各子版本(3.4、3.5、3.6)的增量特性,最后给出面向不同项目阶段的选型建议。

学习提示: 本章重点不在于记忆每个版本的 API 编号,而在于理解“为什么需要升级”——每次版本迭代都对应着拍照延迟、多帧融合、HDR、高帧率等真实场景的痛点。建议在阅读时对照实际设备(如 Pixel、高通平台)的 HAL 实现来加深理解。

3.1 HAL1:单线程、阻塞式、低帧率时代的遗留架构

HAL1 是 Android 相机最早的 HAL 接口,设计于单核处理器和低分辨率传感器的时代。其核心模型是“一次只能做一件事”:预览、拍照、录像三者互斥,且所有操作在单一控制线程上串行执行。

HAL1 架构:单线程阻塞式模型 Camera App CameraService HAL1 Module Sensor / ISP 阻塞式调用链(一次只能做一件事) startPreview() → 阻塞直到第一帧到达 takePicture() → 阻塞预览,完成拍照后恢复 录像期间无法拍照或切换参数
HAL1 关键缺陷:
  • 单线程阻塞: 拍照时预览停止,用户体验割裂。
  • 无缓冲区复用: 每帧都需重新分配内存,内存带宽浪费严重。
  • 不支持多相机: 无法同时操作主摄和副摄(如双摄虚化)。
  • 帧率上限低: 受限于单线程处理能力,通常 ≤ 30fps。

HAL1 在 Android 4.0 之前是唯一选择,至今仍被部分低端 IoT 设备或 legacy 平台使用。但任何新项目都不应再基于 HAL1 开发。

3.2 HAL3:多线程、流水线、高性能的现代架构

Android 4.4 引入 Camera HAL3(又称 Camera3),彻底重构了 HAL 模型。核心变化是引入 同步框架(Synchronization Framework) 和 多缓冲区流水线,将预览、拍照、录像解耦为独立的请求-响应流。

HAL3 架构:多线程流水线模型 Camera App CameraService HAL3 Device Request Queue Capture Thread ISP Pipeline Result Queue Preview Stream Capture Stream Video Stream Metadata Stream Sensor / ISP
HAL3 核心概念: 应用通过 capture() 提交一个 CaptureRequest,HAL 异步返回一个 CaptureResult。每个请求可以指定不同的输出目标(Surface)、传感器设置(曝光/增益/对焦)和处理管线(YUV/JPEG/RAW)。这种设计使得多路流(如同时预览+拍照+录像)成为可能。

3.3 HAL3 子版本演进:3.4、3.5、3.6 的增量特性

HAL3 自 Android 4.4 发布后,随着 Android 版本迭代(5.0~14.0),Google 通过 Camera Metadata Tag 和 HAL 接口扩展 的方式逐步增加了 3.4、3.5、3.6 等子版本。这些子版本并非推翻重来,而是在 HAL3 框架上增加新的能力。

HAL 版本 引入 Android 版本 核心新增特性 典型应用场景
HAL3.0 Android 4.4 多请求流水线、同步框架、YUV/RAW 输出 基础拍照、预览、录像分离
HAL3.4 Android 5.0 ZSL(零快门延迟)、多帧融合(MFNR)、HDR+ 基础支持 快速拍照、夜景多帧降噪
HAL3.5 Android 7.0 Camera Session 配置优化、高速连拍(Burst)、YUV reprocessing 连拍模式、第三方相机应用
HAL3.6 Android 9.0 多相机同步(Logical Camera)、物理相机抽象、动态帧率控制 双摄/三摄虚化、超广角切换

3.3.1 HAL3.4:ZSL 与多帧融合的基石

HAL3.4 最重要的贡献是 Zero Shutter Lag(ZSL) 和 Multi-Frame Noise Reduction(MFNR)。ZSL 通过维护一个循环缓冲区(Ring Buffer),在用户按下快门前持续捕获帧,按下时直接取出最近的一帧,从而消除取景到拍照之间的延迟。

HAL3.4 ZSL 环形缓冲区机制 帧 N-4 帧 N-3 帧 N-2 帧 N-1 帧 N ← 最新帧(当前预览) 最旧帧 → 被覆盖 用户按下快门 直接取出帧 N-1(延迟 ≈ 0)
ZSL 实现要点:
  • HAL 需要维护至少 4~6 帧的 YUV 或 RAW 缓冲区。
  • 应用通过 CAPTURE_INTENT_ZERO_SHUTTER_LAG 标记请求。
  • MFNR 在此基础上对多帧进行对齐、融合,提升暗光画质。

3.3.2 HAL3.5:Session 配置优化与 Burst 连拍

HAL3.5 主要解决了两个痛点:Camera Session 的重复配置开销 和 高速连拍的帧率稳定性。它引入了 configureStreams() 的优化版本,允许在不销毁 Session 的情况下动态调整输出流尺寸。同时,Burst 模式通过预分配请求列表,减少了每次 capture 的 IPC 开销。

// HAL3.5 Burst 连拍示例(伪代码)
// 预创建 30 个 CaptureRequest,全部指向同一个输出 Surface
List<CaptureRequest> burstRequests = new ArrayList<>();
for (int i = 0; i < 30; i++) {
    CaptureRequest.Builder builder = cameraDevice.createCaptureRequest(CameraDevice.TEMPLATE_STILL_CAPTURE);
    builder.addTarget(previewSurface);
    // 设置固定曝光、对焦
    builder.set(CaptureRequest.CONTROL_AE_MODE, CaptureRequest.CONTROL_AE_MODE_OFF);
    builder.set(CaptureRequest.SENSOR_EXPOSURE_TIME, 10000000L); // 10ms
    burstRequests.add(builder.build());
}
// 一次性提交,HAL 内部以最快速度连续捕获
cameraCaptureSession.captureBurst(burstRequests, callback, handler);

3.3.3 HAL3.6:多相机同步与 Logical Camera

HAL3.6 是面向多摄手机时代的重大更新。它引入了 Logical Camera 概念:一个逻辑相机设备背后可以包含多个物理相机(如广角+超广角+长焦)。应用只需与逻辑相机交互,HAL 负责在物理相机之间切换或融合数据。

HAL3.6 Logical Camera 架构 Camera App Logical Camera 0 Physical Camera 0 (Wide) Physical Camera 1 (Ultra-wide) Physical Camera 2 (Tele)
HAL3.6 实现难点:
  • 帧同步: 多个物理相机的帧到达时间必须对齐(误差 < 1ms),否则融合会出现鬼影。
  • 物理相机切换: 变焦时从广角切换到长焦,需要平滑过渡,不能出现黑屏或跳变。
  • 功耗管理: 同时打开多个物理相机传感器会显著增加功耗,需要智能策略(如只打开即将使用的相机)。

3.4 版本选择指南:如何为项目选择正确的 HAL 版本

在实际项目中,HAL 版本的选择并非“越新越好”,而是取决于 硬件能力、Android 基线版本 和 产品需求。以下决策树可以帮助你快速定位:

  1. 硬件平台是什么?
    • 低端 IoT 芯片(如 Allwinner V3s、君正 T40)→ 仅支持 HAL1,无选择余地。
    • 中端 SoC(如 Qualcomm 200/400 系列、MTK 入门级)→ 通常支持 HAL3.0~3.4。
    • 旗舰 SoC(如 Snapdragon 8 Gen 2、Dimensity 9000+)→ 支持 HAL3.6 及以上。
  2. Android 基线版本是多少?
    • Android 4.4~5.0 → 只能使用 HAL3.0~3.4。
    • Android 7.0~8.0 → 推荐 HAL3.5。
    • Android 9.0+ → 必须使用 HAL3.6 才能获得多摄支持。
  3. 产品需要哪些特性?
    • 仅基础拍照+录像 → HAL3.0 足够。
    • 需要 ZSL、夜景多帧降噪 → 至少 HAL3.4。
    • 需要高速连拍(≥ 30fps burst)→ HAL3.5。
    • 需要多摄虚化、超广角切换、逻辑相机 → HAL3.6 必须。
项目类型 推荐 HAL 版本 理由
低端 IoT 摄像头(Linux + Android 4.4) HAL1 硬件不支持 HAL3,且无多摄需求
入门级手机(Android 7.0,单摄) HAL3.4 需要 ZSL 提升拍照体验,无多摄需求
中端手机(Android 9.0,双摄) HAL3.6 需要逻辑相机管理双摄切换
旗舰手机(Android 13+,三摄/四摄) HAL3.6 + Vendor Extensions 需要多摄融合、HDR+、AI 场景识别
车载环视系统(Android 10+,多路摄像头) HAL3.6 需要多相机同步、低延迟
选型建议: 对于 2024 年之后的新项目,除非硬件极度受限,否则应直接选择 HAL3.6。它向下兼容 HAL3.0~3.5 的所有特性,且是 Google 当前唯一持续维护的 HAL 版本。HAL1 仅用于 legacy 维护或超低端场景。

3.5 版本特性对比总结

下表从 延迟、帧率、多摄、功耗、开发复杂度 五个维度对 HAL1 和 HAL3 各子版本进行横向对比:

维度 HAL1 HAL3.0 HAL3.4 HAL3.5 HAL3.6
拍照延迟 200~500ms 100~200ms < 30ms (ZSL) < 30ms < 30ms
最大帧率 30fps 30fps 30fps 60fps (Burst) 60~120fps
多摄支持 不支持 不支持 不支持 有限(独立 Session) 原生支持(Logical Camera)
功耗(同帧率) 低(单线程) 中 中高(环形缓冲区) 中 高(多传感器)
开发复杂度 低 中 中高 高 很高(同步、融合)
关键结论:
  • HAL1 已死,仅用于 legacy 维护。
  • HAL3.0 是基础,但缺少现代相机必备的 ZSL 和多帧能力。
  • HAL3.4 是“够用”的起点,适合中低端单摄产品。
  • HAL3.5 优化了连拍和 Session 管理,适合需要高速连拍的应用。
  • HAL3.6 是当前和未来的标准,所有多摄、高帧率、逻辑相机场景的首选。