测量「流畅」 —— 从 FrameTime 到 Stutter

这是一篇沉浸式长文，建议在专属页面阅读 → 进入完整版

为什么高 FPS 仍然会觉得卡？为什么人眼对 24fps 的电影没有感觉，对 60fps 的 App 却能挑出毛病？性能工程的本质，是把「流畅 / 不流畅」这个主观感觉拆成可测量的判别函数。

六章节脉络

1. FrameTime —— 帧的最小单位：从 GPU 输出到屏幕扫描，一帧到底是什么、由谁决定。
2. FPS —— 帧率的两副面孔：平均 FPS 与瞬时 FPS 的差别，为什么平均数会骗人。
3. 流畅度 —— 视觉惯性与电影帧：人眼为何对均匀的低帧率宽容、对抖动的高帧率敏感。
4. Jank —— 一条判别式：把「卡了」翻译成数学条件 —— 当前帧时长 > 上 3 帧均值 × 2 且 > 50ms。
5. Stutter —— 用占比代替次数：Jank 次数受测试时长影响，Stutter 用「卡顿帧时长 / 总时长」做归一化。
6. 影响 —— 不同场景的指标侧重：交互流畅、视频播放、游戏战斗、滚动列表 —— 每类场景该看哪个指标。

为什么这套语言有用

• FPS 一个数字不够：60fps 平均下藏着的瞬时跌落（300ms 一帧），是 Big Jank。
• Jank 次数不可比：5 分钟测出 10 次 Jank 和 1 小时测出 10 次 Jank 不是一回事。
• 判别式可移植：PerfDog 的 Jank 公式是个 4 行代码就能复现的判别函数，不依赖工具本身。

读完你会有一套衡量「卡顿」的工程语言 —— 在你下一次说「这页不流畅」时，能说清楚是哪类问题、看哪个指标、怎么测。