1. 动画系统概述：什么是动画刷新系统
说实话，我刚开始做动画系统时，也以为就是「每帧画个图」那么简单。直到我在一个数据可视化项目里，被用户吐槽「你这图表怎么一卡一卡的」——嗯，从那以后我才真正开始认真研究动画刷新系统。
动画刷新系统，说白了就是一套负责「在正确的时间点，把正确的画面呈现到屏幕上」的机制。它不关心你画的是什么，它只关心你画得够不够快、够不够稳。
1.1 为什么需要专门的刷新系统？
你可能会问：「我直接写个 while 循环不断画图不行吗？」行，但效果会很差。我见过不少新手这么干，结果 CPU 直接跑满，画面还撕裂。
原因很简单：显示器的刷新节奏和你的绘制节奏是两回事。显示器通常每秒刷新 60 次（60Hz），但你的循环可能跑 1000 次/秒，也可能跑 30 次/秒。没有刷新系统来协调，画面就会出现撕裂、卡顿、掉帧。
| 问题 | 表现 | 原因 |
|---|---|---|
| 画面撕裂 | 屏幕上半部分和下半部分显示不同帧 | 绘制和刷新不同步 |
| 卡顿/跳帧 | 画面突然停顿一下，然后快进 | 帧时间不均匀 |
| 输入延迟 | 操作后画面反应慢半拍 | 刷新周期过长 |
1.2 应用场景：我在哪用过？
动画刷新系统不是某个领域的专属，它几乎无处不在。我挑三个最常见的场景聊聊。
游戏
这是最「吃」刷新系统的场景。游戏需要每帧处理输入、更新物理、计算 AI、渲染场景。我曾经优化过一个手游的帧率，发现瓶颈不在渲染，而在刷新调度——事件队列处理得太慢，导致每帧都在等。
- 要求：稳定 60fps，动作游戏甚至要 120fps
- 难点：帧时间波动不能超过 2ms
- 我的经验：用固定时间步长比可变时间步长更稳
UI 动画
UI 动画看起来简单，其实坑不少。我记得有个项目，按钮点击后的过渡动画总是「抖一下」。排查了半天，发现是刷新系统在动画期间被其他任务抢占了时间片。
- 要求：60fps 即可，但必须平滑
- 难点：避免和主线程的布局计算冲突
- 我的经验：用 requestAnimationFrame 比 setTimeout 靠谱得多
数据可视化
这个领域最容易被忽视。大屏上的实时数据看板，每秒更新几十个图表。如果刷新系统没设计好，CPU 直接飙到 90%。
- 要求：30-60fps，数据量大时可降帧
- 难点：渲染开销大，需要增量更新
- 我的经验：只更新变化的数据点，别全量重绘
1.3 核心指标：怎么衡量刷新系统的好坏？
做动画系统，不能光凭「感觉」说它卡不卡。得有数据说话。我一般看三个指标。
FPS（Frames Per Second）
每秒渲染的帧数。60fps 意味着每帧约 16.67ms。但注意：FPS 是平均值，不能反映波动。我曾经见过一个系统平均 58fps，但每 10 帧就卡一帧——用户照样觉得卡。
帧时间（Frame Time）
这才是更关键的指标。帧时间 = 处理一帧实际花费的时间。理想情况是每帧都在 16.67ms 以内（60fps），且波动很小。
| 帧时间 | 对应 FPS | 体验 |
|---|---|---|
| 8.33ms | 120 | 丝滑 |
| 16.67ms | 60 | 流畅 |
| 33.33ms | 30 | 可接受 |
| 50ms+ | 20 以下 | 明显卡顿 |
流畅度（Smoothness）
流畅度是个综合指标，它不只和 FPS 有关，还和帧时间的稳定性有关。两个系统都是 60fps，但一个帧时间稳定在 16-17ms，另一个在 10-30ms 之间乱跳——前者流畅，后者卡顿。
我一般用这个公式估算流畅度：
流畅度 = 1 - (帧时间标准差 / 平均帧时间)值越接近 1，说明帧时间越稳定，画面越流畅。低于 0.8 就需要优化了。
1.4 刷新系统的两种驱动模式
做系统设计时，首先要选驱动模式。我两种都用过，各有优劣。
固定时间步长（Fixed Timestep）
每帧固定走一个时间步长，比如 16.67ms。不管实际耗时多少，逻辑更新都按这个步长来。如果渲染慢了，就多跑几次逻辑更新来追赶。
- 优点：物理模拟稳定，不会出现「跳帧」
- 缺点：如果渲染跟不上，CPU 会空转
- 适用场景：游戏、物理模拟
可变时间步长（Variable Timestep）
每帧根据实际耗时来更新。渲染快就多更新，渲染慢就少更新。
- 优点：适应性强，不会浪费 CPU
- 缺点：物理模拟可能不稳定，帧时间波动大时体验差
- 适用场景：UI 动画、数据可视化
1.5 本章小结
动画刷新系统不是什么高深的技术，但它决定了用户对「流畅」的第一印象。记住三个核心指标：FPS、帧时间、流畅度。选好驱动模式，别让系统在「卡顿」和「空转」之间摇摆。