2. Android Camera 系统整体架构：从 App 层到 HAL 层的完整数据流与组件分层
Android Camera 系统采用分层解耦的架构设计，从上至下依次为 Application（应用层）、Framework（框架层）、HAL（硬件抽象层） 和 Kernel（内核层）。每一层都承担明确的职责，并通过标准化的接口进行通信。理解这一分层结构是掌握 Camera HAL3 架构的基础。
核心要点： Camera 系统的设计哲学是“接口隔离，职责单一”。应用层不关心底层硬件细节，HAL 层不关心上层业务逻辑，两者通过 Framework 层的标准化服务进行桥接。
2.1 四层架构总览
下表总结了 Camera 系统各层的核心组件与主要职责：
| 层级 | 核心组件/进程 | 主要职责 | 关键接口/协议 |
|---|---|---|---|
| Application | Camera App (如系统相机、第三方应用) | 调用 Camera API2 发起拍照/录像请求，处理预览帧与结果 | android.hardware.camera2 API |
| Framework | CameraService, CameraProviderManager | 管理 Camera 设备生命周期，协调 Capture Session，分发请求与结果 | AIDL / Binder |
| HAL | Camera HAL3 实现 (Provider 进程) | 实现 Camera 设备抽象，处理 Framework 下发的 Capture Request，返回 Result | HIDL / AIDL (Treble) |
| Kernel | V4L2, ISP Driver, Sensor Driver | 驱动硬件传感器、ISP 图像信号处理器，完成原始数据采集 | V4L2, I2C, SPI |
架构演进： 自 Android 8.0 (Treble) 起，HAL 层与 Framework 层之间强制使用 HIDL 接口进行通信，实现了 Framework 与 Vendor 实现的完全解耦。Android 13 及之后版本开始逐步迁移至 AIDL HAL，但分层思想与数据流模型保持不变。
2.2 完整数据流与组件分层详解
一次典型的 Camera 预览或拍照流程，数据从应用层发起请求，经过 Framework 层封装与调度，到达 HAL 层驱动硬件，最终将图像数据逐层回传。下图展示了这一完整的数据流与组件交互关系：
2.3 各层组件职责与关键交互
2.3.1 Application 层
- 入口： 应用通过
CameraManager.openCamera()获取CameraDevice实例。 - 请求发起： 创建
CaptureRequest.Builder，配置输出目标（Surface）、参数（AE/AWB/AF 模式等），调用CameraCaptureSession.capture()或setRepeatingRequest()提交请求。 - 结果接收： 通过
CameraCaptureSession.CaptureCallback接收onCaptureCompleted()回调，获取TotalCaptureResult和图像 Buffer。
常见误区： 应用层直接操作的是
CameraCaptureSession 而非 CameraDevice。一个 CameraDevice 可以创建多个 CameraCaptureSession，但同一时间只能有一个活跃的 Session。
2.3.2 Framework 层
Framework 层是 Camera 系统的“大脑”，运行在 cameraserver 进程中。其核心组件包括：
- CameraService： 核心服务，负责 Camera 设备的枚举、打开、关闭管理，以及权限校验。
- CameraProviderManager： 管理 HAL Provider 进程，通过 HIDL/AIDL 接口与 HAL 层通信。
- Session 管理： 维护
CameraDevice与CaptureSession的状态机，确保请求串行化与正确性。 - Buffer 管理： 协调
Surface与GraphicBuffer的分配与流转，通过BufferQueue机制将图像数据传递给应用层。
2.3.3 HAL 层
HAL 层是硬件厂商的实现核心，运行在独立的 android.hardware.camera.provider 进程中。HAL3 规范要求实现以下关键接口：
| HAL 接口 | 功能描述 | 关键方法 |
|---|---|---|
| ICameraDevice | Camera 设备抽象 | open(), close(), flush() |
| ICameraDeviceSession | Capture Session 抽象 | processCaptureRequest(), flush(), close() |
| ICameraProvider | Provider 管理 | getCameraIdList(), isSetTorchModeSupported() |
2.3.4 Kernel 层
Kernel 层负责与物理硬件交互，主要涉及：
- V4L2 (Video for Linux 2)： 标准视频设备驱动框架，提供
open/ioctl/mmap/poll等操作接口。 - ISP 驱动： 图像信号处理器驱动，负责 RAW 数据到 YUV/JPEG 的转换、3A 统计信息采集。
- Sensor 驱动： 控制图像传感器的曝光、增益、帧率等参数，通过 I2C/SPI 总线通信。
2.4 关键数据流路径总结
一次完整的 Capture 请求数据流可以归纳为以下步骤：
- App 发起请求： 应用层通过 Camera API2 构建
CaptureRequest，包含目标 Surface 列表和参数设置。 - Framework 封装： CameraService 将请求封装为 HAL 层的
CaptureRequest，并通过 HIDL/AIDL 跨进程发送给 HAL Provider。 - HAL 处理： HAL 实现解析请求，调用底层驱动（V4L2）配置 Sensor 和 ISP，启动曝光与数据采集。
- 数据回传： Kernel 层通过 DMA 将图像数据写入预分配的 Buffer，HAL 层填充
CaptureResult元数据，通过 HIDL 回调返回给 Framework。 - App 接收： Framework 将
TotalCaptureResult和图像 Buffer 通过 Binder 回调传递给应用层的CaptureCallback。
性能关键点： 整个数据流中，跨进程通信（Binder/HIDL）和 Buffer 拷贝是主要性能瓶颈。HAL3 通过
StreamBuffer 机制和 BufferQueue 实现零拷贝传递，减少内存开销。
2.5 分层架构的优势
- 解耦： 应用层与硬件实现完全解耦，同一套 Camera API 可适配不同厂商的硬件。
- 可测试性： 每一层都可以独立进行单元测试和模拟测试（如使用
CameraServiceTest或VtsHalCameraProviderTest）。 - 稳定性： 分层隔离了错误传播，HAL 层的崩溃不会直接导致 Framework 层或应用层崩溃。
- 可扩展性： 新增 Camera 特性（如多帧合成、HDR+）只需在 HAL 层实现，不影响上层接口。