4. 帧率与流畅度优化：帧率瓶颈分析、Pipeline 并行化设计与动态调节策略
帧率这件事，说白了就是用户感知最直接的“卡不卡”。我见过很多项目，算法效果堆得不错，但一跑起来掉帧掉得厉害，用户直接给差评。今天我们就来聊聊怎么把帧率稳住。
4.1 帧率瓶颈分析：CPU/GPU/DSP/ISP 谁在拖后腿？
一个典型的拍照或预览 Pipeline，数据流是这样的：
- Sensor 输出 RAW → ISP 做第一级处理（Bayer、去噪、Demosaic）
- ISP 输出 YUV → CPU/GPU/DSP 做算法后处理（美颜、HDR、多帧融合）
- 处理完的数据 → 送显或编码
帧率掉在哪？我习惯先看 CPU 负载。如果 CPU 跑到了 80% 以上，大概率是算法没做硬件加速，全在 CPU 上裸算。GPU 瓶颈通常出现在渲染管线，比如实时滤镜、OpenGL 绘制。DSP 和 ISP 的瓶颈更隐蔽——它们往往是硬件流水线，但带宽或 buffer 配置不对，照样卡死你。
我的经验： 遇到帧率问题，先别急着优化代码。用 systrace 或 perfetto 抓一帧的完整流水，看每个模块的耗时占比。哪个模块的 bar 最长，哪个就是瓶颈。
举个例子，我在一个项目中遇到预览帧率只有 15fps。抓 trace 一看，ISP 输出到 CPU 的 buffer 拷贝占了 8ms。说白了就是内存带宽不够，DDR 被其他进程抢了。后来改成 GPU 直接读 ISP 的 DMA buffer，帧率直接翻倍。
4.2 Pipeline 并行化设计：让每一级都不闲着
传统的串行 Pipeline 是这样的：
Sensor → ISP → CPU算法 → 送显
(10ms) (15ms) (5ms)
总耗时 = 10 + 15 + 5 = 30ms → 33fps
但如果你把 CPU 算法和 ISP 处理做成 双缓冲 甚至 三缓冲，就能让它们并行跑。我常用的设计是：
- ISP 输出帧 A → CPU 开始处理帧 A
- 同时 ISP 开始处理帧 B（不等待 CPU 完成）
- CPU 处理完帧 A 后，直接取帧 B 处理
这样总耗时就变成了 max(ISP耗时, CPU耗时) + 送显耗时。如果 ISP 和 CPU 耗时接近，帧率能提升 40% 以上。
避坑指南： 我曾经在双缓冲里忘了加 buffer 同步锁，结果 CPU 读到了 ISP 还没写完的半帧数据，画面出现撕裂。后来加了 fence 机制，ISP 写完一帧才通知 CPU 去读。
4.3 双路/多路预览场景下的帧率保障
现在的手机经常要同时跑多路预览：比如主摄 + 广角同时显示，或者画中画、双景录像。这时候帧率问题特别容易爆发。
多路预览的核心矛盾是 ISP 带宽有限。一个 ISP 通常只能同时处理 1~2 路 sensor 数据。如果你强行开三路，ISP 就得分时复用，每路的帧率都会掉。
我常用的方案是：
| 场景 | 策略 | 效果 |
|---|---|---|
| 双路预览（主摄+广角） | 主摄走 ISP 全速，广角走 DSP 降分辨率处理 | 主摄 60fps，广角 30fps |
| 画中画 | 主画面走 ISP，小窗走 GPU 缩放（不经过 ISP） | 主画面不掉帧 |
| 双景录像 | 两路都走 ISP，但降低其中一路的帧率到 24fps | 主路 30fps，辅路 24fps |
你想想看，如果两路都要 60fps，ISP 的带宽根本扛不住。所以必须做 优先级调度：用户盯着的那一路给最高帧率，辅助路降帧或降分辨率。
注意： 降分辨率不是简单的裁剪。我见过有人直接把 1080p 缩成 480p，结果画面锯齿严重。正确的做法是用 GPU 做双线性插值或 lanczos 缩放，保证画质可接受。
4.4 动态帧率调节策略：省电与流畅的平衡
不是所有场景都需要 60fps。比如用户只是看照片预览，30fps 就够；但一旦开始滑动取景框，就得立刻跳到 60fps。这就是动态帧率调节的核心逻辑。
我习惯把帧率分成几个档位：
- 静态预览： 24~30fps，省电优先
- 轻度滑动： 45fps，平衡功耗和流畅度
- 快速滑动/录像： 60fps，流畅优先
- 低光环境： 自动降到 24~30fps，保证单帧曝光时间
调节的依据是什么？我常用三个信号：
- 陀螺仪数据： 检测用户是否在移动手机
- 触摸事件： 是否有滑动、点击操作
- 环境光照： 低光下降低帧率换取信噪比
举个例子，我在一个项目中实现了这样的逻辑：
if (陀螺仪角速度 > 0.5 rad/s) {
目标帧率 = 60fps;
} else if (触摸滑动中) {
目标帧率 = 45fps;
} else if (lux < 50) {
目标帧率 = 24fps;
} else {
目标帧率 = 30fps;
}
嗯，这里要注意：帧率切换不能太频繁，否则用户会感觉到“忽快忽慢”。我一般加一个 滞回区间，比如从 60fps 降到 45fps 需要持续低负载 500ms，避免来回跳变。
我的建议： 动态帧率调节最好和温控联动。手机发热时主动降帧，比系统强制降频要平滑得多。用户感知到的不是“卡”，而是“稍微慢了一点”。
4.5 本章知识结构图
下面这张图总结了帧率优化的核心逻辑：从瓶颈定位到并行设计，再到多路保障和动态调节。
帧率优化没有银弹。每个项目的瓶颈都不一样，但方法论是通用的：先抓 trace 看数据，再针对性地做并行或降负载。动态调节是锦上添花，但前提是你的 Pipeline 本身不能有硬伤。