1. 卡顿的根源：理解帧率（FPS）与刷新率（Hz）的关系，为什么60fps是黄金标准？
做界面移植这么多年，我见过太多团队把「卡顿」归咎于网络慢或者手机配置低。其实，真正的罪魁祸首往往藏在两个基础概念里——帧率和刷新率。今天我们就来彻底掰扯清楚。
1.1 先搞懂两个核心概念
帧率（FPS）和刷新率（Hz），听起来像双胞胎，但干的活完全不同。
| 概念 | 英文 | 谁在干活 | 通俗理解 |
|---|---|---|---|
| 帧率 | FPS（Frames Per Second） | GPU/CPU 渲染 | 厨师做菜的速度 |
| 刷新率 | Hz（Hertz） | 屏幕显示 | 服务员上菜的速度 |
帧率，是显卡每秒能生成多少张画面。你玩游戏时看到的「60 FPS」，意思就是显卡每秒画了60张图。
刷新率，是屏幕每秒能刷新多少次画面。普通显示器是60Hz，意思是屏幕每秒刷新60次。电竞屏144Hz，就是每秒刷新144次。
我刚开始做移植时，一直以为这两个数字必须一模一样。后来踩了坑才明白——它们可以不同，但必须配合好。
1.2 为什么60fps是黄金标准？
这个问题，说白了跟人眼有关。
人眼对画面流畅度的感知，并不是线性的。你想想看：
- 15 FPS：明显卡顿，像幻灯片
- 30 FPS：勉强能接受，但快速移动时会有拖影
- 60 FPS：非常流畅，人眼基本感觉不到卡顿
- 120 FPS：更流畅，但普通人很难感知到明显差异
60 FPS 这个数字，恰好卡在「人眼感知阈值」和「硬件成本」的平衡点上。低于它，用户会抱怨卡；高于它，硬件成本翻倍，体验提升却微乎其微。
核心结论：60 FPS 是「够用且不浪费」的黄金标准。对于大多数界面移植场景，稳定在 60 FPS 就是满分。
1.3 帧率 vs 刷新率：谁拖了谁的后腿？
这里有个常见的误区。很多人觉得「只要帧率够高，画面就流畅」。其实不对。
我举个例子：
- 你的显卡每秒能渲染 120 帧（120 FPS）
- 但你的屏幕只有 60Hz
- 结果呢？屏幕每秒只显示 60 帧，剩下 60 帧被丢弃了
这叫帧率浪费。反过来更糟糕：
- 显卡每秒只能渲染 30 帧（30 FPS）
- 屏幕是 60Hz
- 屏幕每刷新两次，才等到一张新画面
- 结果就是画面撕裂、卡顿
我曾经在一个项目中，把 120Hz 的平板硬塞给一个只能跑 40 FPS 的界面。结果用户反馈「还不如 60Hz 的老手机流畅」。原因就在这里——帧率跟不上刷新率，反而会放大卡顿感。
1.4 卡顿的根源：掉帧与丢帧
搞清楚了概念，我们来看看卡顿到底是怎么发生的。
正常情况：
- 每 16.6ms（1000ms / 60），显卡生成一帧
- 屏幕每 16.6ms，刷新一次
- 完美同步，丝般顺滑
卡顿情况：
- 某帧渲染耗时超过 16.6ms，比如花了 30ms
- 屏幕到了刷新时间，发现新帧还没准备好
- 只能重复显示上一帧
- 用户感知到「跳了一下」
这就是掉帧。一次掉帧可能不明显，但如果频繁发生，用户就会觉得「卡」。
避坑指南：我曾经在移植一个动画库时，发现某个页面在低端机上频繁掉帧。排查了半天，发现是一个循环里做了大量 DOM 操作。每次操作耗时 5ms，循环 10 次就是 50ms——直接掉了 3 帧。后来改成批量操作，瞬间回到 60 FPS。
1.5 知识体系：帧率与刷新率的完整关系
下面这张图，是我做课程时画的。它把整个逻辑串起来了。
1.6 实际项目中的经验法则
做界面移植这么多年，我总结了几条铁律：
- 优先保证稳定 60 FPS，而不是追求更高帧率。偶尔掉到 55 FPS 比稳定在 30 FPS 体验好得多。
- 帧率波动比低帧率更致命。用户能适应 30 FPS，但受不了「60→30→60→20」这种过山车。
- 不要盲目上高刷屏。如果你的界面连 60 FPS 都稳不住，120Hz 屏幕只会放大卡顿感。
- 用工具量化，不要凭感觉。我习惯用 Chrome DevTools 的 FPS meter 和 Android 的 Profile GPU Rendering 来抓数据。
小技巧：在移植过程中，如果发现某个页面掉帧严重，先别急着优化代码。打开性能面板，看看是「渲染耗时过长」还是「JS 执行阻塞了主线程」。这两个问题的解法完全不同。
1.7 本章小结
帧率是显卡的产出速度，刷新率是屏幕的消费速度。60 FPS 之所以是黄金标准，是因为它刚好卡在人眼感知的「流畅阈值」上。卡顿的本质，就是帧率跟不上刷新率，或者帧率波动太大。
记住一句话：稳定 60 FPS，胜过一切花里胡哨的优化。