4. Android Camera 框架概览：Camera HAL3 架构、Camera Service、Camera Provider 分层

ZSL（零延迟快门）拍照模式的实现，依赖于 Android Camera 框架各层之间的紧密协作与高效数据通路。本章将系统梳理 Camera 框架的三大核心分层：Camera HAL3（硬件抽象层）、Camera Service（相机服务）与 Camera Provider（相机提供者），并阐明各层在 ZSL 流程中的职责与交互关系。

4.1 整体分层架构

Android Camera 框架采用 C/S（客户端-服务端）架构，自顶向下分为应用层、框架层、服务层与硬件抽象层。ZSL 拍照的数据流需要跨越所有层级，因此理解分层边界与接口契约是优化零延迟的关键前提。

核心分层速览： Application → Camera2 API → Camera Service → Camera Provider → Camera HAL3 → Kernel Driver
Android Camera 框架分层架构（ZSL 视角） Application Layer（Camera2 API 调用者） Framework Layer（Camera2 API 实现 / CameraManager） Camera Service（相机服务 / 权限 / 会话管理） Camera Provider（HAL 接口桥接 / 进程隔离） Camera HAL3（硬件抽象层 / 流 & 请求处理）

4.2 Camera HAL3 架构详解

Camera HAL3 是 Android 从 HAL1 升级后的核心硬件抽象层，专为 ZSL、高速连拍、多帧融合 等高级特性设计。HAL3 引入了 Pipeline（流水线）模型，将拍照分解为可并行处理的请求-结果循环。

4.2.1 HAL3 关键接口与数据结构

接口 / 结构体 作用 ZSL 相关性
camera3_device_t HAL 设备句柄，提供操作函数表 初始化流配置
camera3_capture_request_t 单次捕获请求，包含输出 buffer 列表、设置参数 ZSL 请求需携带 reprocess 标记
camera3_stream_t 定义数据流类型（预览/拍照/分析） ZSL 需要同时配置 preview + still capture 流
process_capture_request() HAL 处理请求的入口函数 ZSL 要求此函数在 1 帧内返回
flush() 清空所有待处理请求 ZSL 场景下用于快速重置 pipeline

4.2.2 HAL3 Pipeline 模型与 ZSL 数据流

HAL3 内部维护一个 多级 Pipeline，每个请求经过 Sensor → ISP → Post-processor 三个阶段。ZSL 模式下，HAL3 需要维持一个 环形 buffer（Ring Buffer），持续缓存最近 3~5 帧的原始数据，当用户按下快门时，直接从 buffer 中取出对应帧进行 reprocess，而非等待新的 Sensor 曝光。

ZSL 关键约束： HAL3 的 process_capture_request() 必须支持 同步 reprocess 模式，即输入 buffer 来自之前缓存的帧，输出 buffer 直接写入 JPEG 编码器。这要求 HAL 实现者维护帧序号与时间戳的映射表。
HAL3 Pipeline 与 ZSL 环形 Buffer 机制 Sensor ISP Post-processor Ring Buffer (3~5帧) 快门按下 → reprocess ZSL 零延迟关键路径 Sensor 持续曝光 → ISP 处理 → 帧数据写入 Ring Buffer 快门触发 → 从 Ring Buffer 取出最近帧 → 直接 reprocess → 输出 JPEG

4.3 Camera Service 架构与职责

Camera Service 运行在 cameraserver 进程中，是 Android 相机框架的 中枢神经。它负责管理客户端连接、权限校验、会话生命周期、以及向 Camera Provider 下发配置指令。

4.3.1 Camera Service 内部模块

  • CameraManager：对外暴露 getCameraIdList()、openCamera() 等 API，维护相机设备列表。
  • CameraDeviceClient：每个打开的相机设备对应一个 Client，负责创建 CaptureSession 和 CaptureRequest。
  • CameraMetadata：静态/动态元数据管理，ZSL 模式下需查询 REQUEST_AVAILABLE_CAPABILITIES 是否包含 PRIVATE_REPROCESSING。
  • PermissionController：在 ZSL 场景下，需确保应用已获取 CAMERA 权限且在前台运行。

4.3.2 ZSL 场景下的 Service 关键流程

  1. 会话配置阶段：Service 将应用请求的 SessionConfiguration 转换为 HAL3 的 camera3_stream_configuration_t，ZSL 要求至少包含一个 CAMERA3_STREAM_OUTPUT 类型的预览流和一个 CAMERA3_STREAM_OUTPUT 类型的拍照流。
  2. 请求提交阶段：Service 将 CaptureRequest 序列化后通过 Binder 传递给 Camera Provider，ZSL 请求需设置 CONTROL_ENABLE_ZSL 为 TRUE。
  3. 结果回调阶段：HAL3 返回的 CaptureResult 经 Service 解析后回调给应用，ZSL 模式下需确保 SHUTTER_TIMESTAMP 与 Ring Buffer 中的帧时间戳对齐。
ZSL 延迟陷阱： Camera Service 与 Provider 之间的 Binder 调用是跨进程通信，单次 IPC 延迟约 0.1~0.5ms。在 ZSL 场景下，应尽量减少 Service 层的元数据校验与权限检查次数，建议使用 批处理请求（Burst Request）模式降低 IPC 开销。

4.4 Camera Provider 分层与进程模型

Camera Provider 是 Android 8.0 引入的 Treble 架构产物，将 HAL 实现从 Camera Service 中解耦，放入独立进程（android.hardware.camera.provider@2.x-service）。Provider 层负责加载 HAL 库、管理设备生命周期、以及转发 Service 的请求到 HAL3。

4.4.1 Provider 分层结构

层级 进程 职责 ZSL 影响
Camera Service cameraserver 权限、会话、元数据 请求序列化与校验
Camera Provider provider@2.x HAL 加载、设备枚举、接口转换 HIDL 转 HAL3 调用
Camera HAL3 Provider 进程内 硬件控制、Pipeline 处理 Ring Buffer 与 reprocess

4.4.2 HIDL / AIDL 接口与 ZSL 数据传递

Provider 层使用 HIDL（Android 8~10）或 AIDL（Android 11+）与 Service 通信。ZSL 场景下，关键接口包括：

  • ICameraDeviceSession::processCaptureRequest()：接收序列化的请求列表，ZSL 要求支持 同步提交多个请求（Burst）。
  • ICameraDeviceSession::flush()：清空 Provider 内部队列，ZSL 切换场景时需快速调用。
  • ICameraDeviceCallback::notify()：传递 SHUTTER 事件，ZSL 模式下需携带准确的曝光开始时间戳。
Camera Service ↔ Provider ↔ HAL3 交互流程（ZSL 请求） Camera Service 权限校验 会话管理 Camera Provider HIDL/AIDL 桥接 设备枚举 Camera HAL3 Pipeline 处理 Ring Buffer processCaptureRequest HAL 函数调用 CaptureResult / Notify 回调 ZSL 优化点：减少 Service ↔ Provider 之间的 IPC 次数，使用批量请求（Burst）降低跨进程开销

4.5 分层协作：ZSL 拍照的完整调用链

综合以上三层，ZSL 拍照的完整调用链可归纳为以下步骤：

  1. 应用层 通过 Camera2 API 创建 CaptureRequest，设置 CONTROL_ENABLE_ZSL = TRUE，并提交到 Camera Service。
  2. Camera Service 校验权限与元数据后，将请求通过 HIDL/AIDL 传递给 Camera Provider。
  3. Camera Provider 将请求转换为 HAL3 的 camera3_capture_request_t，调用 process_capture_request()。
  4. HAL3 从 Ring Buffer 中取出最近一帧原始数据，执行 reprocess（重处理）流程，输出 JPEG 或 YUV 结果。
  5. 结果 沿原路径返回：HAL3 → Provider → Service → Application，应用层收到 CaptureResult 中的 JPEG buffer。
ZSL 延迟关键指标： 从应用提交请求到 HAL3 开始 reprocess，理想延迟应 < 1 帧周期（16.6ms @60fps）。其中 Service 层 IPC 占 0.3~0.8ms，Provider 层转换占 0.1~0.3ms，HAL3 内部调度占 0.5~1ms。优化重点在于减少跨进程拷贝与元数据重复校验。

4.6 本章小结

  • Camera HAL3 是 ZSL 的核心执行层，通过 Pipeline 模型和 Ring Buffer 实现零延迟 reprocess。
  • Camera Service 作为中枢，负责权限、会话与元数据管理，是 ZSL 请求的入口与出口。
  • Camera Provider 实现进程隔离与接口桥接，是 Service 与 HAL3 之间的桥梁，其 IPC 效率直接影响 ZSL 延迟。
  • 理解三层之间的接口契约与数据流方向，是后续章节深入分析 ZSL 优化策略的基础。
← 上一章 📖 返回目录 下一章 →