1. 卡顿的本质：从帧率到人眼感知，理解60fps与16ms的黄金法则
做性能优化这么多年，我见过太多人一上来就撸代码改逻辑。但说实话，如果不理解卡顿的底层原理，改来改去都是瞎忙活。今天咱们就从最根本的东西聊起——帧率、人眼感知，还有那个经典的16ms法则。
1.1 什么是帧率？为什么是60fps？
帧率，说白了就是屏幕每秒钟刷新多少次画面。单位是fps（Frames Per Second）。
你想想看，电影是24fps，电视是30fps，为什么我们做UI偏偏要死磕60fps？
原因其实很直接：人眼的视觉暂留效应。当画面切换速度超过某个阈值，大脑就会认为这是连续运动。24fps勉强能接受，但快速移动时会有明显卡顿感。到了60fps，绝大多数人已经感觉不到画面闪烁或跳动了。
核心结论：60fps是当前主流显示设备的刷新率，也是人眼感知「流畅」与「卡顿」的分水岭。低于这个值，用户就会觉得「有点不对劲」。
我在项目中遇到过一件事：有个页面列表滚动总是「一抖一抖」的，测试说「还好吧，能接受」。我让他盯着滚动条看三秒，他立马改口说「确实难受」。这就是60fps和40fps的差别——用户可能说不清哪里卡，但身体很诚实。
1.2 16ms的黄金法则
60fps意味着什么？我们来算一笔账：
1秒 = 1000毫秒
1000ms ÷ 60帧 ≈ 16.67ms也就是说，每一帧的渲染时间不能超过16.67ms。超过这个时间，下一帧就会延迟，帧率就会掉到60以下。
我习惯把这个16ms拆成三块来看：
| 阶段 | 耗时占比 | 说明 |
|---|---|---|
| JavaScript执行 | ~30% | 事件处理、数据计算、DOM操作 |
| 样式计算与布局 | ~30% | Recalculate Style、Layout（重排） |
| 绘制与合成 | ~40% | Paint、Composite、GPU合成 |
当然，这只是个粗略划分。实际项目中，任何一个阶段超时都会导致掉帧。我曾经优化过一个表格组件，JS执行只用了2ms，但布局阶段花了30ms——因为每次数据更新都触发了全表重排。这就是典型的「JS很快，但布局拖垮了帧率」。
我的经验：不要只看JS执行时间。用Chrome Performance面板录一段滚动操作，看看哪个阶段出现了红色三角警告。那个红色三角，就是你的16ms杀手。
1.3 人眼感知的真相
这里有个有意思的问题：是不是只要保证60fps，用户就一定觉得流畅？
答案是否定的。我踩过这个坑。
人眼对卡顿的感知，其实取决于帧率的稳定性，而不是平均值。举个例子：
- 场景A：稳定55fps，偶尔掉到50fps
- 场景B：平均60fps，但每3秒掉到20fps一次
用户会觉得哪个更卡？
答案是场景B。因为那一次掉帧造成的「跳帧感」非常明显。人眼对帧率突变极其敏感，哪怕只有一次掉到20fps，用户就会记住「这个页面卡过」。
避坑指南：我曾经优化一个动画库，把平均帧率从45fps提到了58fps，但没处理一个极端情况——首次加载时的布局抖动。结果用户反馈「比以前更卡了」。后来才发现，那一次掉到10fps的体验，直接毁掉了所有优化成果。
1.4 从帧率到卡顿：完整的链路
为了让你更直观地理解，我画了一张图。这张图展示了从用户操作到屏幕显示，一帧画面走过的完整路径。
这张图里，从用户操作到屏幕显示，中间经过了8个环节。任何一个环节超时，整帧就会延迟。我习惯把这个链路叫做「帧管线」——它就像一条流水线，最慢的环节决定了整条线的速度。
1.5 为什么16ms这么难守住？
你可能会想：16ms看起来挺宽裕的啊，为什么实际项目中总是掉帧？
原因有三个：
- 浏览器不是单任务——它还要处理网络请求、垃圾回收、定时器等等。这些任务会抢占主线程。
- 布局抖动——JS里读一个样式属性，再写一个样式属性，会导致浏览器被迫同步计算布局。这是最常见的掉帧元凶。
- 过度绘制——一个像素被重复绘制多次，GPU扛不住。
一个小技巧：打开Chrome DevTools的Rendering面板，勾选「Paint flashing」和「Layout Shift Regions」。前者告诉你哪里在重复绘制，后者告诉你哪里发生了布局抖动。这两个开关，我几乎天天开着。
1.6 总结：记住这三句话
这一章的内容，说白了就是三句话：
- 60fps是目标——低于这个值，用户就会感知到卡顿
- 16ms是红线——每一帧的总耗时不能超过这个数
- 帧率稳定比平均值更重要——一次掉帧毁所有