3、Camera HAL版本演进：从HAL1到HAL3再到HAL3.4/3.5，掌握各版本的核心差异与迁移动机
Android Camera HAL（Hardware Abstraction Layer）是连接Android框架层（Framework）与底层Camera硬件驱动（Vendor/Driver）的关键桥梁。自Android诞生以来，Camera HAL经历了从HAL1到HAL3，再到HAL3.4/3.5的多次重大演进。每一次版本升级，都不仅仅是API接口的增删，而是对整个Camera系统架构、数据流模型、控制权归属以及性能上限的重新定义。对于HAL开发者而言，理解这一演进脉络，不仅是为了适配新系统，更是为了在架构选型时做出符合产品定位的决策。本章将深入剖析各版本的核心设计哲学、关键差异以及驱动厂商迁移的真实动因。
3.1 HAL1：串行控制时代的“功能机”架构
核心原理：以Preview/Record为中心的单一职责模型
HAL1诞生于Android 4.0时代，其设计初衷是满足当时以“拍照”和“录像”为核心的移动应用场景。在HAL1架构中，Camera硬件被抽象为一个单一状态机，同一时刻只能处于预览（Preview）、拍照（Still Capture）或录像（Video Record）中的一种模式。Framework层通过一个全局的android.hardware.Camera接口下发指令，HAL层则负责将这些指令翻译为具体的Sensor、ISP和VFE（Video Front End）寄存器操作。
HAL1最显著的特征是参数传递的扁平化。所有设置项（如曝光、白平衡、对焦）均通过setParameter(String key, String value)接口以字符串键值对形式传递。这种设计虽然简单，但带来了两个致命问题：一是参数校验完全依赖HAL实现，缺乏统一的元数据描述；二是无法表达参数之间的时序依赖关系（例如“先设置曝光再触发对焦”）。
| 维度 | HAL1 特征 | 典型限制 |
|---|---|---|
| 并发能力 | 单线程串行处理 | 无法同时进行预览与高分辨率拍照 |
| Buffer管理 | 由Framework分配，HAL被动接收 | 无法实现零拷贝，延迟高 |
| 3A（自动对焦/曝光/白平衡） | HAL内部实现，状态不透明 | App无法精细控制3A策略 |
| 扩展性 | 新增功能需增加setParameter键值 | 代码膨胀，维护困难 |
判断方法：识别HAL1的典型代码特征
在源码层面，HAL1的camera_device_ops_t结构体包含set_parameters和get_parameters函数指针，且preview_stream_ops回调中必须实现enqueue_buffer和dequeue_buffer。如果Vendor层代码中大量出现strcmp解析参数键值的逻辑，且存在一个巨大的switch-case状态机处理预览/拍照/录像切换，基本可以判定为HAL1架构。
setParameter是异步的，但Framework层并不保证参数生效的时序。在低端平台上，频繁调用setParameter可能导致预览卡顿或拍照黑屏。若产品需要多摄或高帧率功能，HAL1已完全无法胜任。
案例拆解：老平台上的“拍照黑屏”问题
某入门级手机使用HAL1架构，用户点击拍照按钮后，屏幕偶尔出现1-2秒黑屏。通过抓取HAL日志发现，takePicture调用后，HAL内部先停止预览流，再切换Sensor到高分辨率模式，完成曝光后再重新启动预览。整个过程约1.5秒，期间无任何帧输出。由于HAL1不支持“预览流与拍照流并行”，黑屏是必然结果。最终只能通过缩短Sensor切换时间（从120ms优化到80ms）来缓解，但无法根治。
3.2 HAL3：Camera2的“并发请求”革命
核心原理：基于CaptureRequest的流水线模型
Android 5.0引入的HAL3（即Camera2 HAL）彻底重构了数据流模型。其核心是CaptureRequest（捕获请求）：App可以同时提交多个请求，每个请求独立描述目标流（Stream）、3A策略、输出格式和帧回调。HAL层内部维护一个请求队列，通过process_capture_request接口接收请求，并在process_capture_result中返回结果。这一设计使得预览、拍照、录像可以真正并行——例如在录制4K视频的同时，仍可触发一张1600万像素的静态照片。
HAL3的另一关键变化是Buffer管理权移交。在HAL3中，Framework通过dequeue_buffer/enqueue_buffer将Buffer池交给HAL，HAL可以直接在GPU或ISP中填充数据，实现零拷贝。同时，HAL3引入了元数据（Metadata）机制，使用camera_metadata_t结构体描述所有可控参数和输出统计信息，取代了HAL1的字符串键值对。
操作流程：HAL3请求处理的标准链路
- 配置流：App通过
configure_streams定义输出流（如预览流、拍照流、录像流）。 - 构建请求：App创建
CaptureRequest，指定目标流、3A模式、AE/AF/AWB设置。 - 提交请求：Framework将请求封装为
camera3_capture_request_t，调用HAL的process_capture_request。 - HAL处理：HAL解析请求，驱动Sensor曝光、ISP处理，并将结果填充到指定Buffer。
- 返回结果：HAL通过
process_capture_result返回帧数据、3A统计信息和时间戳。
process_capture_request是同步调用，但HAL可以异步返回结果。这意味着HAL必须管理好请求的并发执行，不能阻塞调用线程。若HAL实现不当，容易导致请求超时（CAMERA3_MSG_ERROR_REQUEST）。
案例拆解：ZSL（零快门延迟）的实现
某旗舰机型在HAL3下实现ZSL功能。其核心是维持一个环形Buffer池，HAL持续将Sensor输出的帧写入Buffer，但仅当App提交拍照请求时，才从Buffer中选取时间戳最接近的帧作为最终照片。通过request->settings中的android.control.enableZsl字段，HAL可以判断是否启用ZSL模式。实测中，ZSL拍照延迟从HAL1的800ms降至150ms，且无黑屏。但代价是内存占用增加约40MB（用于Buffer池），且对ISP的持续处理能力要求更高。
3.3 HAL3.4/3.5：多摄与逻辑Camera的“系统级”扩展
核心原理：物理Camera与逻辑Camera的抽象
随着多摄（双摄、三摄、四摄）成为标配，HAL3的单一Camera设备模型已无法满足需求。HAL3.4（Android 9）和HAL3.5（Android 10）引入了逻辑Camera（Logical Camera）概念：一个逻辑Camera可以聚合多个物理Camera（如广角+超广角+长焦），对外表现为一个统一的camera_device，但内部通过camera3_stream_configuration中的physical_camera_id字段区分不同物理流。
HAL3.4/3.5还引入了离线处理（Offline Processing）模式，允许HAL在后台线程中处理长时间运行的请求（如多帧降噪、超分辨率），而不阻塞实时预览流。此外，camera3_capture_request中新增了physical_camera_settings数组，允许App针对不同物理Camera单独设置参数。
| 特性 | HAL3 | HAL3.4/3.5 |
|---|---|---|
| 多摄支持 | 仅支持独立Camera设备 | 支持逻辑Camera聚合物理Camera |
| 流类型 | 仅实时流（Realtime） | 新增离线流（Offline） |
| 参数控制 | 全局设置 | 支持物理Camera独立设置 |
| Buffer管理 | HAL管理 | HAL管理，但支持Buffer跨物理流共享 |
| 典型场景 | 单摄、基础双摄 | 超广角切换、人像虚化、多帧HDR |
判断方法：如何识别HAL3.4/3.5特性
在camera3_device_ops_t中，HAL3.4新增了is_realtime标志和physical_camera_id字段。若Vendor层实现了get_physical_camera_info接口，且支持CAMERA3_STREAM_OFFLINE流类型，则说明已适配HAL3.4+。此外，camera_metadata中新增了android.logicalMultiCamera标签，用于描述逻辑Camera的物理组成。
案例拆解：超广角切换的“无缝变焦”实现
某手机采用“广角+超广角”双摄方案，目标是在1x-0.6x变焦范围内实现平滑过渡。在HAL3.4下，逻辑Camera同时打开两个物理Camera，App提交一个包含两个物理流的CaptureRequest。HAL内部根据变焦系数动态调整两个Sensor的裁剪区域（Crop Region），并通过physical_camera_settings分别设置曝光和增益，使两路画面的亮度、色温保持一致。在切换点（如0.8x），HAL通过camera3_capture_result中的physical_metadata返回两路帧的融合权重，由ISP完成无缝拼接。实测切换延迟从HAL3的200ms降至30ms，且无画面跳变。
3.4 版本迁移决策：从HAL1到HAL3/3.4的动因与代价
核心原理：迁移的本质是控制权与复杂度的再平衡
迁移到HAL3/3.4并非简单的API替换，而是将控制权从Framework下放到HAL，同时将复杂度从App转移到Vendor。HAL1时代，Framework承担了大部分调度逻辑；HAL3时代，HAL必须自己管理请求队列、Buffer生命周期和3A策略。对于Vendor而言，这意味着需要更强大的ISP驱动、更精细的电源管理和更复杂的调试工具。
操作流程：迁移评估的五个关键步骤
- 步骤1：硬件能力盘点——确认Sensor、ISP是否支持多流并发、快速模式切换（如
FAST模式）。 - 步骤2：驱动架构重构——将原有的
setParameter逻辑拆分为独立的3A模块和请求处理模块。 - 步骤3：Buffer管理改造——实现基于
gralloc的Buffer池，支持HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED格式。 - 步骤4：元数据适配——编写
camera_metadata的静态信息（如ANDROID_SENSOR_INFO_*）和动态更新逻辑。 - 步骤5：CTS/VTS验证——通过
android.hardware.camera2.cts.CameraDeviceTest等测试用例，确保符合兼容性定义。
process_capture_request的耗时分布。
案例拆解：某中端平台的HAL1→HAL3迁移复盘
某方案商在MTK平台（4核A53）上从HAL1迁移至HAL3。初始阶段，预览帧率从30fps降至22fps，且拍照时出现ANR。通过systrace分析发现，瓶颈在于HAL的process_capture_request中进行了大量的memcpy操作（将请求参数复制到内部结构体）。优化方案：改用零拷贝引用计数，仅保存请求指针，并在结果返回时统一释放。同时，将3A算法从主线程移至独立线程，避免阻塞请求处理。最终帧率恢复至30fps，拍照延迟从900ms降至400ms。复盘经验：迁移前必须进行CPU/内存/带宽预算评估，且HAL层应避免任何不必要的深拷贝。
3.5 总结与选型建议
HAL1适合功能简单、成本敏感的功能机或IoT设备；HAL3是当前Android主流设备的基线，适合单摄或基础双摄；HAL3.4/3.5则是多摄旗舰的必选项。选型时需综合考量硬件能力、产品定义和团队维护成本。对于新项目，建议直接基于HAL3.4起步，预留逻辑Camera和离线处理能力，避免后期二次迁移。