📚 课程目录第2章 Android Camera架构全景

2. Android Camera架构全景：从App到Kernel的完整数据流

Android Camera 架构是一个典型的分层设计，从上至下依次为 应用层 (App)、框架层 (Framework)、硬件抽象层 (HAL) 和 内核层 (Kernel)。理解每一层的职责以及它们之间的数据流与控制流，是掌握 Camera HAL 开发的基础。

核心观点： Camera 架构的设计哲学是“接口隔离，职责单一”。应用层只关心拍照/录像的语义；Framework 负责协调资源与权限；HAL 屏蔽硬件差异；Kernel 驱动实际传感器。任何一层的变更都不应影响其他层。

2.1 四层架构总览

下图展示了 Android Camera 的完整分层结构，以及关键组件 CameraService、CameraProvider 和 HAL 在其中的位置。

  关键分层职责：
  App层： 通过 CameraManager 获取相机列表，通过 CameraDevice 创建捕获会话，发送 CaptureRequest。
Framework层： CameraService 作为核心服务，管理客户端连接、权限校验、流配置协商，并将请求转发给 HAL。
HAL层： CameraProvider 封装底层硬件实现，提供 ICameraDevice、ICameraDeviceSession 等接口。
Kernel层： 通过 V4L2 框架或平台私有驱动控制传感器、ISP 和 CSI 接收器。

2.2 关键组件详解

2.2.1 CameraService

CameraService 是 Android Framework 中 Camera 子系统的核心服务，运行在 cameraserver 进程中。它负责以下关键职责：

客户端管理： 维护多个 CameraDeviceClient 实例，每个客户端对应一个相机应用连接。
权限与安全： 校验调用方是否有 CAMERA 权限，以及是否具有访问特定物理相机的资格。
流配置协商： 当应用调用 createCaptureSession 时，CameraService 负责协调输出流（Surface）与 HAL 支持的流配置。
请求分发： 将应用提交的 CaptureRequest 转换为 HAL 可识别的格式，并调用 HAL 的 process_capture_request。

2.2.2 CameraProvider

CameraProvider 是 Android 8.0 (Treble) 引入的 HAL 接口封装层，运行在独立的 provider 进程中。它通过 HIDL (Android 8-10) 或 AIDL (Android 11+) 与 CameraService 通信。

特性	CameraProvider (HIDL/AIDL)	传统 HAL (legacy)
进程模型	独立进程，与 cameraserver 隔离	直接加载到 cameraserver 进程
接口定义	使用 .hal 或 .aidl 文件定义	使用 `hw_module_t` 结构体
热插拔支持	原生支持，通过回调通知 CameraService	不支持，需额外实现
版本演进	ICameraProvider 1.0 → 2.0 → AIDL	HAL 1.0 → 2.0 → 3.x (已废弃)

开发注意： 在 Android 12 及以上版本，Google 强烈推荐使用 AIDL 版本的 CameraProvider。HIDL 版本虽然仍被支持，但新功能（如并发相机、逻辑相机）仅在 AIDL 接口中提供。

2.2.3 Camera HAL 3.x 接口

HAL 3.x 是当前主流的 Camera HAL 版本，它定义了以下核心函数指针，由 OEM 厂商实现：

// camera3_device_ops_t 中的关键函数
typedef struct camera3_device_ops {
    // 初始化设备，返回设备版本信息
    int (*initialize)(const struct camera3_device *,
                      const camera3_callback_ops_t *callback_ops);

    // 配置输出流（分辨率、格式、方向等）
    int (*configure_streams)(const struct camera3_device *,
                             camera3_stream_configuration_t *stream_list);

    // 注册输入/输出缓冲区
    int (*register_stream_buffers)(const struct camera3_device *,
                                   const camera3_stream_buffer_set_t *buffer_set);

    // 处理捕获请求（核心函数，每次拍照/预览调用一次）
    int (*process_capture_request)(const struct camera3_device *,
                                   camera3_capture_request_t *request);

    // 刷新所有待处理的请求
    int (*flush)(const struct camera3_device *);

    // 销毁设备
    void (*close)(struct camera3_device *);
} camera3_device_ops_t;

2.3 完整数据流：一次拍照请求的生命周期

以下 SVG 流程图展示了一次典型的 拍照请求 从 App 到 Kernel 再到 App 的完整路径：

2.4 关键数据流与缓冲区管理

在 Camera 数据流中，缓冲区 (Buffer) 的管理是性能关键。Android 使用 GraphicBuffer 和 ION/DMA-BUF 机制实现零拷贝传递：

App 注册 Surface： 应用通过 createCaptureSession 传入 Surface（通常来自 SurfaceView、ImageReader 或 MediaCodec）。
Framework 分配 BufferQueue： CameraService 为每个输出流创建一个 BufferQueue，生产者是 HAL，消费者是 App。
HAL 填充 Buffer： 当 HAL 处理完 process_capture_request 后，将图像数据直接写入 BufferQueue 的共享内存中。
App 消费 Buffer： App 通过 onImageAvailable 或 onFrameAvailable 回调获取填充后的 Buffer。

  性能优化要点：
  使用 BufferQueue 的 dequeueBuffer/queueBuffer 机制避免内存拷贝。
HAL 实现中应使用 ION/DMA-BUF 分配物理连续内存，减少 Cache 刷新开销。
对于高帧率场景（如 60fps 预览），建议使用 循环 Buffer 池 避免频繁分配/释放。

2.5 架构演进：从 HAL 1.0 到 HAL 3.x 再到 Treble

阶段	Android 版本	架构特点	主要问题
HAL 1.0	2.3 - 4.4	同步接口，每次只处理一个请求	性能差，不支持 ZSL/HDR
HAL 2.0	4.4 (实验性)	引入异步回调，支持多请求	接口不稳定，未广泛采用
HAL 3.x	5.0 - 至今	完全异步，支持 per-frame 控制	实现复杂度高，需处理 pipeline 同步
Treble (HIDL)	8.0 - 11	HAL 独立进程，接口标准化	HIDL 学习成本，跨进程性能损耗
Treble (AIDL)	12+	统一使用 AIDL，简化接口	需迁移现有 HIDL 实现

迁移建议： 如果你的项目仍在使用 HIDL 版本的 CameraProvider，建议在 Android 14 之前完成向 AIDL 的迁移。Google 已明确表示后续版本将不再支持 HIDL 接口。

2.6 本章小结

Android Camera 架构通过四层分离实现了硬件无关性：

App 层 通过 Camera2 API 发起请求。
Framework 层 的 CameraService 负责协调与权限控制。
HAL 层 的 CameraProvider 封装硬件差异，通过 process_capture_request 处理每个帧的控制与数据。
Kernel 层 驱动实际硬件完成图像捕获。

掌握这一全景图，是后续深入 HAL 开发、调试性能问题、以及实现自定义相机特性的前提。