11、帧率稳定性优化：帧率抖动分析、VSync机制与Choreographer、丢帧检测与补偿、动态帧率调整策略
帧率稳定性，说白了就是你的摄像头预览画面能不能「稳如老狗」。我见过太多项目，帧率平均值看着还行，一抓实际曲线，抖得像心电图。用户感知到的卡顿，往往不是平均帧率低，而是帧率忽高忽低。今天我们就来聊聊怎么把帧率稳住。
11.1 帧率抖动分析
帧率抖动，专业术语叫 Jank。它指的是相邻两帧之间的时间间隔不均匀。比如你期望 30fps，每帧应该是 33.3ms，但实际可能是 20ms、50ms、30ms 这样跳。人眼对 50ms 以上的间隔非常敏感，一卡就能感觉到。
我在项目中遇到过最典型的场景：打开相机预览，前几秒很流畅，突然画面顿了一下，然后又恢复。抓 trace 一看，原来是某个后台服务在抢 CPU。嗯，这种问题最头疼，因为不是每次都能复现。
帧率抖动的常见原因有这些：
- CPU 调度延迟：线程被优先级更高的任务抢占
- GPU 渲染超时：一帧的渲染指令太多，GPU 忙不过来
- Buffer 分配阻塞：申请 buffer 时遇到内存紧张
- ISP 处理瓶颈：3A 算法或图像处理耗时波动
- 驱动层锁竞争：多个线程同时访问同一个硬件资源
怎么分析？我建议你抓 systrace 或者 perfetto。重点关注这几个关键节点：
- App 侧的 dequeueBuffer 时间
- HAL 侧的 processCaptureRequest 耗时
- ISP 的中断响应时间
- SurfaceFlinger 的合成时间
任何一个环节出现毛刺，都会反映到最终帧率上。
核心思路：帧率抖动分析，就是找到那个「最慢的环节」。别上来就优化代码，先定位瓶颈在哪。
11.2 VSync 机制与 Choreographer
VSync，垂直同步信号。它是 Android 显示系统的「心跳」。每 16.6ms（60Hz 屏幕）硬件会发出一个 VSync 信号，告诉系统：该准备下一帧了。
Choreographer 是 App 层的「节拍器」。它监听 VSync 信号，然后回调 doFrame()。你的 UI 更新、动画、绘制，都应该在 doFrame() 里完成。如果 doFrame() 执行时间超过 16.6ms，就会丢帧。
为什么会这样？你想想看，如果 App 在 doFrame() 里做了耗时操作，比如加载图片、解析数据，那下一帧的 VSync 来了，上一帧还没处理完。Choreographer 会跳过这一帧，直接等下一个 VSync。这就是丢帧的本质。
我建议你在 Camera 预览场景下，重点关注 Choreographer 的回调延迟。可以用这个代码来检测：
Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() {
@Override
public void doFrame(long frameTimeNanos) {
long delay = (System.nanoTime() - frameTimeNanos) / 1000000;
if (delay > 16) {
Log.w("CameraPreview", "丢帧！延迟 " + delay + " ms");
}
Choreographer.getInstance().postFrameCallback(this);
}
});这个回调会告诉你每一帧的实际延迟。如果 delay 经常超过 16ms，说明你的 UI 线程被阻塞了。我曾经在一个项目里发现，预览帧率不稳，查了半天，结果是某个第三方 SDK 在主线程里做了网络请求。嗯，这种坑踩过一次就记住了。
小技巧：Camera 预览的 SurfaceView 或 TextureView 更新，尽量走独立的渲染线程，不要依赖 Choreographer 的 doFrame。因为 Choreographer 受 UI 线程影响太大。
11.3 丢帧检测与补偿
丢帧检测，说白了就是「数数」。你期望 30fps，实际 1 秒内只收到了 25 帧，那丢了 5 帧。但更精细的做法是检测「连续丢帧」和「帧间隔异常」。
我常用的检测方法：
- 帧计数器：在 HAL 层维护一个 sequence ID，App 侧检查 ID 是否连续
- 时间戳分析：比较每帧的 timestamp，如果间隔超过阈值，标记为丢帧
- Buffer 回调监控：在 onImageAvailable 里记录时间，统计 1 秒内的回调次数
丢帧补偿，这个比较 tricky。你不能凭空「补」出一帧来，但可以做一些策略：
- 重复上一帧：如果丢了一帧，把上一帧再显示一次。画面会感觉「顿」一下，但比黑屏好
- 插帧预测：根据前后两帧的运动矢量，插值生成中间帧。这个计算量大，适合高端平台
- 降低预览分辨率：如果持续丢帧，说明当前分辨率下性能不够，主动降一档
注意：丢帧补偿只是「遮羞布」，不能解决根本问题。我见过有些方案强行插帧，结果画面出现鬼影，用户反馈更差。优先解决丢帧原因，再考虑补偿。
11.4 动态帧率调整策略
动态帧率调整，就是根据当前场景和负载，自动切换帧率。比如光线充足时跑 60fps，暗光下降到 30fps。或者预览时 30fps，录像时 24fps。
我建议的策略是这样的：
| 场景 | 目标帧率 | 触发条件 |
|---|---|---|
| 高亮环境 | 60fps | lux > 300，且 CPU 负载 < 60% |
| 普通室内 | 30fps | lux 50-300 |
| 暗光环境 | 24fps | lux < 50，或 ISP 处理时间 > 30ms |
| 低功耗模式 | 15fps | 电池电量 < 20%，或温度 > 45°C |
实现上，我习惯在 HAL 层做帧率决策。因为 HAL 最清楚当前 ISP 的负载和 sensor 的能力。App 层只需要监听帧率变化，更新 UI 显示即可。
核心代码逻辑：
// HAL 层伪代码
void processRequest(CaptureRequest& request) {
float currentFps = getCurrentFps();
float targetFps = decideTargetFps();
if (currentFps < targetFps * 0.8) {
// 持续丢帧，降低目标帧率
targetFps = targetFps * 0.75;
log("帧率不足，降级到 " + targetFps);
}
// 设置 sensor 的帧率
sensor->setFrameRate(targetFps);
// 调整 ISP 的 pipeline 配置
isp->configureForFps(targetFps);
}这里要注意，帧率切换不能太频繁。我见过一个方案，每 1 秒判断一次，结果用户在暗光和正常光之间来回走动，帧率在 30 和 60 之间反复跳，画面反而更不稳定。我建议加一个滞回区间，比如从 60 降到 30 需要持续 3 秒低于阈值，从 30 升到 60 需要持续 2 秒高于阈值。
避坑指南：我曾经在一个项目里，动态帧率调整做得太激进，结果导致 sensor 的曝光参数来不及收敛，画面忽明忽暗。后来加了帧率切换的「冷却时间」，每次切换后至少保持 5 秒，问题就解决了。
知识体系总览
下面这张图总结了帧率稳定性优化的核心逻辑，从问题分析到检测手段，再到补偿和调整策略，形成一个完整的闭环。
这张图展示了从问题分析到最终目标的完整链路。帧率抖动分析是起点，VSync 和 Choreographer 是核心机制，丢帧检测和补偿是辅助手段，动态帧率调整是最终策略。它们之间形成一个反馈闭环，不断优化。
最后说一句，帧率稳定性优化没有银弹。每个平台、每个 sensor、每个场景都不一样。我建议你先把 systrace 抓明白，把每一帧的耗时拆解清楚，然后再对症下药。别一上来就改代码，先搞清楚问题在哪。