📚 课程目录第2章 Camera HAL层架构

2. Camera HAL层架构：HAL3与HAL1的区别、核心接口

Camera HAL（Hardware Abstraction Layer）是Android相机系统中承上启下的关键层，它向上对接Framework的CameraService，向下直接控制V4L2驱动、ISP固件和传感器硬件。在帧率抖动排查中，HAL层的实现质量直接决定了请求下发、帧同步和结果回传的实时性。本章重点剖析HAL1与HAL3的架构差异，并深入讲解HAL3核心接口的调用契约与性能约束。

2.1 HAL1 vs HAL3：架构演进与帧率影响

Android从API Level 21（Android 5.0）开始引入HAL3接口，但HAL1在低端平台和兼容模式下仍广泛存在。两者在设计哲学上有本质区别：

对比维度	HAL1（传统模式）	HAL3（灵活模式）
操作模型	基于预览/拍照/录像的固定管线	基于请求-结果的流水线模型
帧率控制	由HAL内部固定帧率，上层干预有限	上层通过request精确控制每一帧参数
Buffer管理	HAL内部管理buffer队列，回调通知	Framework通过`process_capture_request`传入buffer句柄
多流支持	受限，通常仅支持预览+拍照双流	原生支持多路输出流（YUV/RAW/JPEG/HEIC）
元数据传递	通过固定结构体，扩展性差	使用`CameraMetadata`键值对，灵活可扩展
帧同步复杂度	低，HAL内部串行处理	高，需处理多路request并发和结果排序
典型帧率抖动场景	预览启动阶段、分辨率切换时	多流并发、AE/AWB收敛、HDR合成时

帧率排查要点： 在HAL3下，帧率抖动通常源于request下发延迟、result回传超时或buffer dequeue阻塞。排查时需重点抓取process_capture_request的调用时间戳和notify回调的SHUTTER时间戳，计算request到shutter的延迟。

2.2 HAL3核心接口：process_capture_request

process_capture_request是HAL3中最关键的入口函数，Framework每次下发一帧拍摄请求时都会调用该接口。其原型定义在hardware/libhardware/include/hardware/camera3.h中：

typedef struct camera3_callback_ops {
    int (*process_capture_request)(const struct camera3_callback_ops *ops,
                                   camera3_capture_request_t *request);
    // ... 其他回调
} camera3_callback_ops_t;

调用契约与性能约束：

同步调用： Framework在调用process_capture_request后会阻塞等待HAL处理完成，因此该函数必须快速返回（通常要求< 5ms），否则会阻塞Framework的请求下发线程，直接导致帧率下降。
请求不可修改： HAL不能修改request中的任何字段，包括settings、output_buffers等。如需修改参数，必须在result中返回新的settings。
Buffer所有权转移： 调用后，HAL获得output_buffers中所有buffer的使用权，必须在完成填充后通过process_capture_result归还。
多线程安全： Framework可能从多个线程同时调用process_capture_request，HAL必须保证线程安全。

性能优化建议： 在process_capture_request中避免做任何I/O操作（如读写文件、网络请求）、避免长时间加锁、避免调用驱动ioctl时使用阻塞模式。建议将耗时操作（如ISP参数计算）异步化，或使用预计算缓存。

2.3 HAL3核心接口：process_capture_result

process_capture_result是HAL向Framework回传帧结果和填充后buffer的接口。它由HAL主动调用，通知Framework一帧处理完成：

void (*process_capture_result)(const struct camera3_callback_ops *ops,
                               const camera3_capture_result_t *result);

关键字段与帧率关系：

字段	含义	帧率抖动影响
`frame_number`	帧序号，与request中的frame_number对应	乱序回传会导致Framework帧排序延迟
`result`	帧元数据（AE/AWB/传感器时间戳等）	元数据缺失或时间戳异常会触发重算
`output_buffers`	已填充的图像buffer数组	buffer回传延迟直接阻塞下一帧dequeue
`partial_result`	部分结果标记，用于分阶段回传	合理使用可减少首帧延迟，滥用则增加调度开销
`shutter`	通过`notify`回调的曝光时间戳	shutter延迟是帧率抖动的关键指标

常见陷阱： 部分HAL实现为了降低延迟，在process_capture_result中只回传部分buffer（如只回传预览流，延迟回传拍照流），但未正确设置partial_result标志，导致Framework认为帧未完成而阻塞后续请求。这是帧率抖动的常见根因之一。

2.4 HAL3请求-结果流水线架构

下图展示了HAL3从request下发到result回传的完整流水线，以及各阶段可能引入帧率抖动的关键点：

request下发延迟： process_capture_request 执行时间 > 5ms，阻塞Framework请求线程 ② 驱动响应延迟： ioctl调用后驱动未及时启动曝光，或ISP处理超时 ③ SHUTTER回传延迟： notify回调未在预期时间内触发，导致Framework帧同步超时 ④ result回传乱序： frame_number回传顺序与下发顺序不一致，触发Framework重排序 ⑤ buffer dequeue阻塞： 驱动或HAL未及时释放buffer，导致下一帧无法获取输出buffer

2.5 HAL1与HAL3在帧率抖动排查中的差异

在实际的帧率抖动排查工作中，HAL1和HAL3的排查路径有显著不同：

HAL1排查重点： 关注HAL内部的预览循环是否稳定，检查preview_stream的buffer dequeue/queue延迟，以及takePicture调用时是否打断了预览帧率。
HAL3排查重点： 关注request下发速率是否匹配传感器帧率，检查process_capture_request的调用间隔是否均匀，以及process_capture_result的回传是否出现batch（批量回传）现象。

实战经验： 在HAL3下，如果发现process_capture_request的调用间隔出现周期性抖动（如每30帧出现一次延迟），通常是因为AE/AWB收敛算法在特定场景下触发了参数重算，导致HAL在process_capture_request中执行了耗时计算。解决方案是将3A参数计算异步化，或使用预计算缓存。

2.6 核心接口性能基准

以下是在主流平台（如Qualcomm SM8250、MediaTek Dimensity 1200）上实测的HAL3接口性能基准，供排查帧率抖动时参考：

接口	正常延迟	警告阈值	异常阈值	帧率影响
`process_capture_request`	< 2ms	2-5ms	> 5ms	直接降低最大帧率
`notify(SHUTTER)`	< 10ms（从request到shutter）	10-20ms	> 20ms	导致帧同步超时，丢帧
`process_capture_result`	< 1ms（回传调用本身）	1-3ms	> 3ms	阻塞后续result回传
Buffer dequeue（驱动侧）	< 8ms（30fps下）	8-16ms	> 16ms	直接导致帧率下降