14、帧率控制：固定帧率与动态帧率、VSync对齐渲染、丢帧补偿策略

帧率控制，说白了就是决定「画面什么时候刷新、刷多快」。

很多人觉得帧率越高越好，其实不是。你想想看，如果屏幕只有60Hz，你跑120fps，那多出来的60帧全是浪费——屏幕根本来不及显示。更糟的是，帧率不稳定带来的视觉卡顿，比稳定低帧率还难受。

我个人习惯把帧率控制分成三个层次：策略层（定多少帧）、对齐层（什么时候渲染）、补偿层（丢帧了怎么办）。今天我们就一层层拆开讲。

14.1 固定帧率：简单但不够灵活

固定帧率是最直接的做法。你设定一个目标帧率，比如30fps或60fps，然后让渲染循环按这个节奏跑。

在Android里，最简单的实现方式是用 Choreographer 的 postFrameCallback。我早期做的一个视频播放器就是这么干的：

// 固定帧率实现示例
private val TARGET_FRAME_INTERVAL = 1000L / 60  // 60fps

private val frameCallback = object : Choreographer.FrameCallback {
    override fun doFrame(frameTimeNanos: Long) {
        // 渲染一帧
        renderFrame()
        // 注册下一帧回调
        Choreographer.getInstance().postFrameCallback(this)
    }
}

// 启动渲染循环
Choreographer.getInstance().postFrameCallback(frameCallback)

嗯，这里要注意：doFrame 里的 frameTimeNanos 是硬件VSync的时间戳，不是你代码执行的时间。如果你在回调里做耗时操作，下一帧的VSync信号来了，你的回调还没返回——那就掉帧了。

固定帧率的优点很明显：实现简单，行为可预测。缺点也很致命：它不关心你当前在做什么。如果你在播放一个静态画面，60fps纯属浪费电。如果你突然切换到复杂场景，60fps又可能跑不动。

14.2 动态帧率：按需分配，能省则省

动态帧率的思路是：根据场景和负载，动态调整目标帧率。

我一般把场景分成三类：

• 静态场景（比如暂停、显示缩略图）：降到15~24fps，省电省CPU
• 普通动态场景（比如列表滑动、普通视频）：30fps足够
• 高动态场景（比如游戏、60fps视频）：跑满60fps

实现上，我习惯用一个 FrameRateController 来管理：

class FrameRateController {
    enum class Scene { STATIC, NORMAL, HIGH_DYNAMIC }
    
    private var currentScene = Scene.NORMAL
    private var targetFps = 30
    
    fun switchScene(scene: Scene) {
        currentScene = scene
        targetFps = when (scene) {
            Scene.STATIC -> 15
            Scene.NORMAL -> 30
            Scene.HIGH_DYNAMIC -> 60
        }
        // 通知渲染循环调整间隔
        onFrameRateChanged(targetFps)
    }
    
    fun getFrameInterval(): Long = 1000L / targetFps
}

你可能会问：场景切换的时机怎么定？我个人习惯用内容变化检测。比如视频播放器，如果连续N帧画面变化量小于某个阈值，就自动降帧率。如果用户突然滑动进度条，立刻切回高帧率。

14.3 VSync对齐渲染：别让屏幕等你

VSync（垂直同步）是硬件层面的机制。简单说：屏幕以固定频率刷新（比如60Hz），每次刷新前会发一个VSync信号。你的渲染工作必须在这个信号到来之前完成，否则就会出现撕裂——屏幕上半部分显示旧帧，下半部分显示新帧。

Android的 Choreographer 就是用来对齐VSync的。它会在每个VSync信号到来时回调 doFrame，让你在帧边界开始渲染。

但有个坑：doFrame 回调的时间点，并不等于VSync信号到达的时间。如果上一帧的渲染超时了，你的回调会被推迟到下一个VSync。这时候 frameTimeNanos 还是上一个VSync的时间戳——这就是所谓的掉帧。

我建议的做法是：

// VSync对齐渲染的正确姿势
private val frameCallback = object : Choreographer.FrameCallback {
    override fun doFrame(frameTimeNanos: Long) {
        // 检查是否掉帧
        val now = System.nanoTime()
        val vsyncInterval = 16666666L  // 60Hz下的VSync间隔（纳秒）
        
        if (now - frameTimeNanos > vsyncInterval * 1.5) {
            // 掉帧了！跳过这帧，或者做补偿
            handleDroppedFrame()
            // 但还是要注册下一帧回调
            Choreographer.getInstance().postFrameCallback(this)
            return
        }
        
        // 正常渲染
        renderFrame()
        Choreographer.getInstance().postFrameCallback(this)
    }
}

14.4 丢帧补偿策略：亡羊补牢，为时未晚

丢帧是不可避免的。网络抖动、GC暂停、复杂计算……总有一些因素让你的渲染超时。关键是丢帧之后怎么办。

我总结了几种补偿策略：

策略	原理	适用场景	风险
帧预测	根据前几帧的运动趋势，预测当前帧	视频播放、动画	预测不准会导致鬼影
插帧	在丢帧位置插入中间帧	游戏、UI动画	增加计算开销
降级渲染	降低画质、减少特效，保证帧率	复杂场景	视觉质量下降
异步回退	丢帧时直接复用上一帧	所有场景	画面静止，体验差

我个人最常用的是降级渲染。举个例子，我在做一个AR应用时，如果检测到连续掉帧，就自动关闭阴影和抗锯齿，等帧率稳定后再恢复。用户几乎感知不到这个切换。

// 丢帧补偿：降级渲染策略
class AdaptiveRenderer {
    private var droppedFrameCount = 0
    private var qualityLevel = Quality.HIGH
    
    enum class Quality { HIGH, MEDIUM, LOW }
    
    fun onFrameDropped() {
        droppedFrameCount++
        if (droppedFrameCount >= 3) {
            // 连续掉帧3次，降级
            qualityLevel = when (qualityLevel) {
                Quality.HIGH -> Quality.MEDIUM
                Quality.MEDIUM -> Quality.LOW
                Quality.LOW -> Quality.LOW  // 最低了，不再降
            }
            applyQualityLevel(qualityLevel)
            droppedFrameCount = 0
        }
    }
    
    fun onFrameRendered() {
        // 连续正常渲染10帧，尝试升级
        if (qualityLevel != Quality.HIGH) {
            // 这里可以加一个计数器，稳定后逐步恢复
        }
    }
}

14.5 实战建议：组合使用才是王道

说了这么多，你可能会问：到底该用哪种策略？

我的答案是：组合使用。

• 用动态帧率做宏观控制：根据场景设定目标帧率
• 用VSync对齐做微观调度：确保渲染在帧边界完成
• 用丢帧补偿做兜底：当意外发生时，优雅地降级

举个例子，一个视频播放器的帧率控制流程：

1. 用户播放视频，检测到是60fps内容 → 目标帧率设为60fps
2. Choreographer 回调，对齐VSync开始渲染
3. 突然网络抖动，解码延迟 → 连续掉帧3次
4. 触发降级策略：关闭后处理特效，帧率恢复
5. 网络恢复，稳定渲染10帧后，逐步恢复特效
6. 用户暂停播放 → 场景切换为STATIC，帧率降到15fps

这套组合拳打下来，用户几乎感觉不到卡顿。嗯，这就是我想要的体验。

---

公众号:蓝海资料掘金营，微信deep3321