4. 帧率调优基础：帧率计算公式、影响帧率的关键因素
帧率（Frame Rate）是衡量 Camera 系统实时性能的核心指标，通常以 FPS（Frames Per Second）为单位。在 HAL 层进行帧率调优，首先需要理解帧率的数学本质，以及从 Sensor 曝光到最终图像输出的完整流水线中，哪些环节会成为瓶颈。
4.1 帧率计算公式与理论极限
帧率的倒数即为单帧耗时（Frame Time），它由流水线中最慢的环节决定。对于典型的 Camera 系统，帧率上限由以下公式约束：
FPS = 1 / max( T_sensor, T_ISP, T_CPU, T_GPU, T_transfer )
其中：
T_sensor = Sensor 曝光时间 + 读出时间
T_ISP = ISP 管线处理时间（含统计、降噪、缩放等）
T_CPU = CPU 端算法处理时间（如 3A 统计、HDR 合成）
T_GPU = GPU 端渲染或后处理时间（如滤镜、畸变校正）
T_transfer = 数据搬运时间（MIPI 传输、DMA、内存拷贝）在实际系统中，帧率往往低于理论值，因为各模块之间存在等待、同步和资源竞争。下表列出了常见场景下的帧率上限估算：
| 场景 | Sensor 最大帧率 | ISP 处理能力 | CPU 负载 | 实际可达帧率 |
|---|---|---|---|---|
| 1080p 30fps 预览 | 60 fps | 60 fps | 低 | 30 fps（受应用层限制） |
| 4K 60fps 录像 | 60 fps | 30 fps | 中 | 30 fps（ISP 瓶颈） |
| 高帧率慢动作 240fps | 240 fps | 120 fps | 高 | 120 fps（ISP 瓶颈） |
| 多路并发（双摄） | 30 fps × 2 | 30 fps（分时复用） | 高 | 15 fps（ISP 分时瓶颈） |
关键洞察： 帧率优化的本质是识别并消除流水线中的“短板”。不要盲目提升 Sensor 帧率，而应优先解决 ISP 或 CPU 端的处理延迟。
4.2 影响帧率的关键因素
帧率并非由单一硬件决定，而是 Sensor、ISP、CPU/GPU 以及系统总线共同作用的结果。以下从四个维度逐一分析。
4.2.1 Sensor 端：曝光与读出
- 曝光时间（Exposure Time）： 暗光环境下，Sensor 需要更长的曝光时间，直接拉长 T_sensor。例如，30fps 要求单帧 33ms，若曝光时间设为 30ms，则留给读出和处理的时间仅剩 3ms，极易丢帧。
- 读出时间（Readout Time）： 取决于 Sensor 的行扫描速率和分辨率。4K 传感器的读出时间通常是 1080p 的 4 倍以上。
- 帧同步（Frame Sync）： Sensor 的 VSYNC 信号决定了帧起始时刻。若 HAL 层未正确配置帧同步，可能导致帧率减半或抖动。
调优建议： 在暗光场景下，适当降低帧率（如 30fps → 15fps）以换取更长的曝光时间，比强行维持高帧率但画面过暗更符合用户体验。
4.2.2 ISP 端：管线处理能力
ISP 是帧率优化的核心战场。现代 ISP 包含多个处理模块，每个模块的处理延迟都会累加：
| ISP 模块 | 典型延迟 (ms) | 对帧率的影响 |
|---|---|---|
| Bayer 去马赛克 | 2-5 | 低 |
| 自动白平衡统计 | 1-3 | 低 |
| 自动曝光统计 | 1-3 | 低 |
| 降噪（空域+时域） | 5-15 | 高 |
| 缩放与裁剪 | 2-5 | 中 |
| HDR 合成 | 10-30 | 极高 |
ISP 瓶颈通常出现在高分辨率、高帧率或启用复杂算法（如多帧 HDR、时域降噪）时。此时，HAL 层需要合理配置 ISP 的管线调度策略，例如：
- 关闭不必要的 ISP 模块（如高精度降噪在预览场景可降级）。
- 使用 ISP 的硬件加速路径（如直接输出 YUV 而非 RGB）。
- 调整 ISP 的帧缓冲深度，避免因等待统计结果而阻塞流水线。
4.2.3 CPU/GPU 负载：算法与后处理
当 Camera 系统启用计算摄影功能（如多帧 HDR、夜景模式、人像虚化）时，CPU 和 GPU 的负载会显著增加，成为帧率瓶颈。
- CPU 端： 3A 算法（自动曝光、自动对焦、自动白平衡）的统计计算、HDR 帧合成、人脸检测等。若 CPU 被其他进程抢占，Camera 线程可能无法及时处理帧数据。
- GPU 端： 滤镜渲染、畸变校正、超分辨率等。GPU 渲染时间与分辨率成正比，4K 分辨率的 GPU 处理时间可能是 1080p 的 4 倍。
- 内存带宽： 高帧率下，数据搬运（MIPI → DDR → ISP → DDR → GPU → DDR → Display）会消耗大量内存带宽。若带宽不足，DMA 传输将产生等待。
常见陷阱： 很多开发者只关注 Sensor 和 ISP 的帧率，却忽略了 CPU/GPU 端的帧处理线程优先级。在 Android 系统中，Camera 服务线程的优先级若被降低，即使硬件流水线无瓶颈，帧率也会因调度延迟而下降。
4.2.4 系统级因素：总线与调度
| 因素 | 影响机制 | 典型表现 |
|---|---|---|
| MIPI CSI 带宽 | 数据 lane 数不足或时钟频率低，导致传输延迟 | 高分辨率下帧率无法达到 Sensor 标称值 |
| DDR 带宽争抢 | Camera 与 GPU/Display/NPU 争用内存带宽 | 帧率周期性抖动，丢帧 |
| 中断处理延迟 | VSYNC 中断响应不及时，导致帧处理错过 deadline | 帧率不稳定，出现卡顿 |
| 电源管理策略 | CPU/GPU 降频导致处理能力下降 | 长时间录像后帧率逐渐降低 |
4.3 帧率调优的通用步骤
- 测量基线： 使用 systrace/perfetto 或 Camera 内置的帧率统计工具，获取当前各模块的实际耗时。
- 定位瓶颈： 对比 T_sensor、T_ISP、T_CPU、T_GPU，找出耗时最长的环节。
- 分析根因： 针对瓶颈环节，进一步拆解子模块。例如，若 ISP 耗时过长，检查是降噪模块还是 HDR 模块导致。
- 制定优化方案： 根据根因选择优化手段（降低算法精度、关闭非必要模块、调整线程优先级、提升时钟频率等）。
- 验证与迭代： 优化后重新测量，确认帧率提升效果，并检查图像质量是否满足要求。
实战口诀： 先测后调，瓶颈优先；Sensor 看曝光，ISP 看降噪；CPU 看线程，GPU 看渲染；带宽不足降分辨率，调度延迟提优先级。