3、帧率与刷新率：FPS 与 Hz 的匹配艺术

做动画开发这么多年，我见过太多人把帧率和刷新率混为一谈。说实话，这两个概念虽然经常一起出现，但本质完全不同。今天我们就把它彻底讲清楚。

帧率，全称 Frames Per Second，就是每秒能渲染多少帧画面。你可以把它想象成动画的心跳——心跳越快，动作越流畅。

我个人习惯把帧率分成三个档次：

关键认知：帧率是应用层的指标，它取决于你的渲染逻辑、CPU/GPU 性能、以及数据准备速度。说白了，帧率是“我能画多快”。

我在项目中遇到过一个问题：某个粒子动画在模拟器上跑 60 FPS 稳稳的，但一到真机就掉到 20 FPS。后来发现是每帧都在重新分配大量内存，GC 频繁触发。嗯，这里要注意——帧率掉得厉害，不一定是渲染引擎的问题，很多时候是数据层在拖后腿。

刷新率是显示器每秒刷新画面的次数，单位是赫兹（Hz）。常见的刷新率有 60Hz、90Hz、120Hz、144Hz。

你想想看，显示器其实是个“傻大个”——它不管你的应用画了多少帧，它只按自己的节奏工作。每 1/60 秒（60Hz 下），显示器就会问：“有新画面吗？没有？那我再显示一遍旧的。”

避坑指南：我曾经以为刷新率越高就一定越好。直到有一次在 144Hz 显示器上跑一个 30 FPS 的动画，画面反而比 60Hz 显示器更卡——因为每帧被重复显示了将近 5 次，视觉上出现了明显的“微停顿”。刷新率不是越高越好，关键看匹配。

这是本章的核心。帧率和刷新率的关系，说白了就是“生产”和“消费”的匹配问题。

帧率是生产者，刷新率是消费者。两者节奏一致时，画面丝滑；节奏错位时，就会出现掉帧、撕裂、卡顿。

最理想的情况。比如 60 FPS 配 60 Hz，每帧刚好在显示器刷新前准备好。每一帧都被完美呈现，没有浪费，也没有等待。

如果你的应用能跑 120 FPS，但显示器只有 60 Hz，那多出来的 60 帧就白画了。显示器每 16.67ms 才取一次画面，你画得再快也没用。

我记得有个团队优化粒子系统，把帧率从 60 提到了 120，但显示器是 60Hz 的，用户根本感觉不到变化。白白浪费了 CPU 和电量。

这是最常见的问题。比如帧率只有 30 FPS，但显示器是 60 Hz。显示器每刷新两次，才等到一个新画面。中间那次刷新只能重复显示旧帧，视觉上就是一顿一顿的。

注意：帧率低于刷新率时，掉帧的感知会被放大。因为显示器“空转”的次数越多，人眼越容易察觉到停顿。这也是为什么 30 FPS 在 60Hz 屏幕上看起来比在 30Hz 屏幕上更卡——空转比例更高。

下面这张图展示了帧率与刷新率的三种匹配关系，以及它们如何影响最终画面。

知道了原理，那我们在代码里怎么处理？我总结了几条实战经验：

先获取显示器刷新率：大多数平台都提供 API。比如浏览器用 window.screen.refreshRate（部分浏览器支持），或者通过 requestAnimationFrame 的回调时间戳推算。
锁定帧率上限：不要无脑跑满帧。如果显示器是 60Hz，把帧率锁在 60 FPS 就够了。多出来的性能留给其他计算。
动态降级：当帧率低于刷新率时，考虑降低渲染质量。比如减少粒子数量、降低阴影精度。

我的习惯：在开发调试阶段，我会在屏幕上同时显示 FPS 和当前刷新率。一旦发现两者差距超过 20%，就触发告警。这帮我提前发现了很多潜在的掉帧问题。

很多人以为“帧率越高越好”。其实不对。帧率超过刷新率的部分，用户根本看不到，反而增加了功耗和发热。

我曾经优化一个游戏，把帧率从 60 提到 120，结果手机发烫严重，电池续航直接砍半。后来锁在 60 FPS，体验没变，续航翻倍。嗯，这就是典型的“过度优化”。

记住：帧率的目标不是“跑得最快”，而是“跑得稳”。稳定的 60 FPS 比忽高忽低的 120 FPS 体验好得多。掉帧的感知，更多来自帧率的波动，而不是绝对数值。

帧率和刷新率，一个是应用的生产速度，一个是硬件的消费速度。两者匹配，画面才流畅。匹配的核心原则就三条：