帧预算、渲染路径与测量

来源：animation-performance/SKILL.md，并汇总 STANDARDS/AUDIT 的性能规则。本章保留原文的优化意图，同时纠正“某属性永远 GPU”“换成 scale 完全等价”等过强表述。

6.1 一帧的预算属于整个页面

60Hz 约 16.7ms，120Hz 约 8.3ms；并非全给动画计算使用。输入处理、脚本、样式、布局、绘制和合成都要占时间。平均 FPS 掩盖偶发长帧，要观察帧时间分布、长任务和交互时的丢帧。

6.2 两条独立的性能轴

第一条：每帧产生多少渲染工作。第二条：动画推进是否依赖忙碌的主线程。Transform-only 的 rAF 动画仍会被主线程阻塞；合成线程推进的动画仍可能因图层过大而昂贵。优化要同时考虑这两条轴。

6.3 渲染路径

样式计算 → Layout → Paint/Raster → Composite

绝对定位、影响范围小的尺寸动画有时足够快；但不要只凭开发机的肉眼判断。背景色、滤镜“现在全部自动 GPU”不是可靠结论。Motion 性能指南。

6.4 属性替换必须保持语义

Left→translate 常能减少布局；width→scale 会缩放子文字、圆角且不推动邻居；display→opacity 不会移除布局和焦点；box-shadow→drop-shadow 的阴影形状也不同。先确认视觉、布局、命中和可访问语义一致，再讨论成本。

6.5 CSS、WAAPI 与 JS

CSS/WAAPI 的符合条件动画可在合成线程推进；JS rAF 驱动 DOM 更新要等主线程。JavaScript 也能在 Worker 做计算，所以“所有 JS 都在主线程”不准确；但 Worker 并不能随意直接操作 DOM。

Motion 是混合引擎，不能把整库判为“全部 rAF”或“全部 GPU”。原文建议在主线程繁忙时优先直接 transform 字符串，其依据是某些独立变换/变量路径不易加速。按实际版本、入口、属性和驱动实现验证，不以 prop 名称独断。

6.6 不在每帧 render

Pointermove→setState→组件渲染，是常见额外工作。用 motion value 或直接 style 写表现值，离散业务状态才入 state。也不是所有 state 更新都会掉帧；风险随组件树、工作量和更新频率增加。

即使不用 React，也要避免一边写样式一边读几何造成同步布局。可以批量读取，再批量写入；预先测量能够复用的尺寸，尺寸变化再更新。

6.7 继承变量的成本

在共同祖先每帧更新自定义属性，可能使依赖它的后代重新计算样式。内容越多越慢时检查这条路径。原文“所有后代必然全部重算”过于绝对，实际有浏览器依赖追踪和优化；关键是缩小影响域。可考虑直接写目标 transform，或使用合适的非继承属性设计并测量。

6.8 Will-change、contain 与图层

Will-change 是提示，不是“强制 GPU”指令，也不是普遍治愈 1px 抖动的药。观察问题后，在少数元素上预热并检查收益，完成后视情况清理。图层占用显存，超大透明层、巨大背景和大量滤镜都会增加成本。

Contain 会改变布局、绘制和溢出行为；contain:paint 可能裁切外部阴影/弹出内容。TranslateZ(0) 也不是无副作用的标准加速开关。不能为了消除一点抖动就给所有节点同时加这些属性。

6.9 Blur 与复杂 SVG

原文以约 20px 为警戒线、2–5px 为淡化双影的起点。实际成本还取决于面积、设备、像素密度和滤镜组合；10px 的全屏 blur 也可能昂贵。减少面积、同时运动数量和滤镜复杂度，比死守一个半径更有效。

6.10 诊断顺序

1. 录制问题交互，定位实际慢帧。

2. 查动画属性与 transition:all，区分布局与绘制。

3. 查是否与导航、数据处理、hydration 同时发生。

4. 查每帧 React render、强制同步布局、过多样式写入。

5. 查内容增长、祖先 CSS 变量和大图层。

6. 查滤镜及巨大 SVG。

7. 有证据后尝试图层提示，再录制比较。

CPU 节流只能模拟部分计算压力，不能完整模拟弱 GPU、低内存、热降频和触屏输入。真实中端手机仍需测。

自测与答案

1. Transform 动画仍卡，说明理论错了吗？还要查驱动线程、样式重算、图层成本。

2. ScaleY 能替换所有展开动画吗？不能，布局和文字形状可能不同。

3. 开始/结束偏 1px 只有 GPU 交接原因吗？还可能是子像素、字体栅格化、布局与坐标取整。

4. 应提交什么证据？复现条件、录制、慢帧归因和改前改后的同条件比较。