低端设备的掉帧会放大不适
别名: 掉帧 · 卡顿 · jank · 低端机动画
概念解释
动画一旦开始，视觉系统就按连续运动去预期下一帧的位置。低端设备若赶不上垂直同步，就会掉帧（dropped frames）：运动变成一顿一顿的跳跃。这种不平滑比“整段动画更慢但帧齐”更难受——预期被打破，而不是速度变低。不适被放大的原因是设备算力不够维持帧预算，不是属性会不会触发重排本身，也不是有没有提供降级开关。
机制
60 Hz 下每帧大约 16.7 ms，120 Hz 更短。一帧里样式、布局、绘制、合成、加上业务脚本若超过预算，这一帧被跳过，物体从位置 A 直接出现在位置 C。视觉把这次位移读成突跳，而不是中间那帧该有的平滑插值。低端 CPU/GPU、热节流、后台进程抢核时，超预算更频繁。同一套 transform 动画在旗舰机上全在合成器里完成，在低端机上可能因层过多、超大模糊或主线程被 JS 占满而仍然掉帧。
掉帧的分布也重要。开头几帧掉、后面稳住，用户会把整段标成“卡”；周期性每几帧掉一次，比偶发一次更像闪烁。面积大、对比强、经过注视点的运动，掉帧更显眼。所以低端机上的不适是“连续性被抽样打孔”，不是平均帧率数字本身。
怎么研究
实验室用性能面板或帧时间线看是否错过 vsync、长帧是否落在动画区间；可在限核、限 GPU、开节流的设备上复现。现场 RUM 记录动画窗口内的长帧或掉帧计数，按设备分位，而不是只看实验室旗舰机的平均 FPS。实验室高帧率和现场低端分位经常 metric mismatch：实验室窗口聚焦、温度低，现场在热节流和多标签下。因变量用掉帧次数、最长帧、动画期间输入延迟；不要用平均 FPS 掩盖尾部。动画是否走布局是另一条叶子的自变量，这里只记录“帧有没有齐”。
边界
用户正在等的进度指示，偶发掉帧不如“完全不动”严重。电影式 24 fps 的内容本身就不是按 60 插值的，观感预期不同。关掉屏幕或后台标签通常不再合成，掉帧无对象。高刷新率设备的“掉一帧”时间更短，同样次数的掉帧主观上可能轻一些，但不能把旗舰 120 Hz 的余量当成低端 60 Hz 的预算。无动画的瞬时状态切换没有帧序列，这条的不适机制不成立。
怎么落地
- 在目标低端机（热、旧、限核）上跑真实动效，而不是只在开发机上看“很顺”。
- 动画窗口内把主线程长任务挪走：数据解析、图片 decode 不要和过渡叠在同一帧。
- 大面积模糊、多重阴影、超多层
will-change在低端机上先减，因为它们即使不重排也会吃掉合成预算。 - 验证：低端机录帧时间线，过渡期间长帧应接近零；现场按设备分位的掉帧应随这些削减下降。平均 FPS 好看但 p95 长帧仍在，不算过。