CamX架构下Camera HAL层开发入门 - 第2节
2.1 从 QCamera 到 CamX：演进之路
在 Qualcomm 平台的 Camera HAL 发展历程中，QCamera 是早期基于 Android 传统 HAL1/HAL3 接口实现的闭源 HAL 层方案。随着移动设备对多摄像头、高帧率、计算摄影和 AI 场景的需求爆发，QCamera 的架构瓶颈日益凸显。
QCamera 架构痛点
| 痛点 | 具体表现 | 影响 |
|---|---|---|
| 紧耦合设计 | Pipeline 与 Sensor/ISP 驱动深度绑定，更换模组需重写大量代码 | 开发周期长，维护成本高 |
| 单流架构 | 仅支持单一输出流，无法同时满足预览、拍照、视频的多路需求 | 多摄场景下性能受限 |
| 平台锁定 | 代码与 Qualcomm 私有接口强耦合，无法跨芯片平台复用 | OEM 切换平台代价巨大 |
| 调试困难 | 日志分散、无统一 Trace 机制，问题定位依赖经验 | 稳定性问题收敛慢 |
关键转折：Android 引入 Treble 架构和 Camera HAL3 强制要求后，QCamera 的紧耦合设计已无法满足多厂商、多平台的快速适配需求。Qualcomm 于 2018 年正式启动 CamX（Camera eXtensible）架构，作为下一代 Camera HAL 统一框架。
演进路线图
2.2 CamX 核心设计哲学
CamX 从诞生之初就围绕三个核心设计原则构建：模块化、可扩展、跨平台。这三个原则贯穿了整个架构的每一层设计。
2.2.1 模块化（Modularity）
CamX 将 Camera Pipeline 拆解为多个独立的功能模块，每个模块负责单一的硬件抽象或算法处理。模块之间通过标准化的接口进行通信，降低了模块间的耦合度。
- Usecase 模块：定义拍照、录像、多摄等场景的 Pipeline 拓扑
- Pipeline 模块：管理从 Sensor 到 Output 的数据流路径
- Node 模块：封装 ISP、JPEG、CV 等具体处理单元
- Sensor 模块：抽象不同厂商的 Sensor 驱动差异
2.2.2 可扩展（Extensibility）
CamX 通过 CHI（Camera Hardware Interface） 和 XML 配置驱动 的机制，允许 OEM 和第三方算法厂商在不修改核心框架代码的前提下，扩展新的功能模块。
扩展性实践：OEM 只需编写一个符合 CHI 接口规范的 Node 动态库，并在 XML 配置中声明 Pipeline 拓扑，CamX 框架即可在运行时加载并编排该 Node，无需重新编译整个 HAL。
2.2.3 跨平台（Cross-Platform）
CamX 将平台相关代码与平台无关逻辑严格分离。平台适配层（Platform Adaptation Layer）封装了不同骁龙 SoC 的 ISP、DSP、GPU 等硬件差异，上层 Usecase 和 Pipeline 逻辑无需修改即可跨平台复用。
| 层次 | 平台无关 | 平台相关 |
|---|---|---|
| Usecase | 拍照/录像/多摄场景定义 | — |
| Pipeline | 数据流拓扑与 Node 编排 | — |
| Node | 算法逻辑（如 3A、HDR） | ISP 寄存器配置、DSP 调用 |
| Platform Adapter | — | 硬件抽象、驱动接口、电源管理 |
开发注意：跨平台能力并不意味着“一次编写，到处运行”。不同平台的 ISP 能力、带宽限制、电源策略存在差异，Node 开发时仍需在平台适配层做针对性优化。CamX 提供的是架构层面的复用，而非二进制级别的兼容。
2.3 CamX 架构全景图
综合上述设计哲学，CamX 的整体架构可以概括为以下分层结构。每一层都遵循模块化、可扩展、跨平台的原则，共同构成一个灵活且高性能的 Camera HAL 框架。
架构要点总结：CamX 通过清晰的六层分层，将 Android Framework 与底层硬件完全解耦。开发者只需关注 Node 层的算法实现和 CHI 接口的适配，无需关心上层框架的调度细节。这种设计使得 CamX 能够快速适配新的骁龙平台和新的 Camera 模组，大幅缩短了 OEM 的集成周期。