17370845950

应使用 requestAnimationFrame 替代 setTimeout/setInterval 实现动画，因其对齐浏览器刷新帧、避免强制同步布局与掉帧；需批量读写 DOM、优先用 transform/opacity、善用 CSS 动画与 will-change、节流事件并清理动画实例。

用 requestAnimationFrame 替代 setTimeout 或 setInterval

浏览器每秒重绘约 60 次（即 16.6ms 一帧），requestAnimationFrame 会把回调对齐到下一帧开始时刻，避免强制同步布局、掉帧或“抖动”。而 setTimeout(fn, 16) 无法保证准时执行，还可能在非绘制时机触发样式读写，引发 layout thrashing。

• 必须在每次动画帧内完成所有 DOM 读写：先批量读取（如 offsetTop、getBoundingClientRect()），再批量写入（如修改 style.transform）
• 不要在动画循环里调用 getComputedStyle 或访问 offsetHeight 等触发回流的属性——除非你明确需要且已缓存结果
• 如果只是位移/缩放/旋转，优先用 transform + opacity，它们走合成层，不触发重排重绘

避免强制同步布局（Forced Synchronous Layout）

当 JS 在同一任务中先读取布局信息（比如 el.offsetWidth），又立刻修改样式（比如 el.style.left = '100px'），浏览器不得不立即计算当前样式和布局，打断渲染流水线。这种模式在动画中尤其致命。

• 把所有读操作集中放在帧开头，所有写操作集中放在帧末尾
• 用 el.getBoundingClientRect() 代替多次访问 offsetTop / offsetLeft ——它返回一个快照对象，后续读取不触发新计算
• 若需动态计算位置，先用 getComputedStyle(el).transform 解析矩阵，再做运算，而不是靠反复读写 style.left

用 CSS 动画 + will-change 提前升层

纯 CSS 动画（@keyframes + animation）由浏览器直接交给合成器处理，比 JS 驱动更省资源。但需配合正确策略，否则无效甚至负优化。

• 只对真正需要动画的元素设 will-change: transform 或 will-change: opacity，不要全局滥用（会常驻纹理内存）
• 避免对 top/left 等触发重排的属性做 CSS 动画；改用 transform: translateX(100px)
• 用 transform: translateZ(0) 或 transform: scale(1.0001) 强制创建独立图层，适用于需要频繁更新但 JS 控制的场景（注意：现代 Chrome 已弱化该技巧效果，仅作兜底）

节流高频事件与清理未完成动画

滚动、鼠标移动等事件可能每秒触发上百次，若每个都调用 requestAnimationFrame，会堆积大量待执行帧，造成延迟或卡顿。

• 用闭包 + 标志位控制：只有上一帧结束才注册下一帧，例如

let isAnimating = false;
function animateScroll() {
  if (isAnimating) return;
  isAnimating = true;
  requestAnimationFrame(() => {
    // 执行动画逻辑
    isAnimating = false;
  });
}
window.addEventListener('scroll', animateScroll);

• 使用 element.animate() 时，记得保存返回的 Animation 实例，在组件卸载或条件变更时调用 animation.cancel() 或 animation.finish()，防止内存泄漏或状态错乱
• 监听 visibilitychange 事件，在页面不可见时暂停动画（animation.pause()），恢复时再继续，节省 CPU 和电量

实际项目中最容易被忽略的是“读写混合”这个细节——它不会报错，但会让 60fps 的动画掉到 20fps 以下，且很难定位。建议在 DevTools 的 Rendering 面板打开 “FPS Meter” 和 “Paint Flashing”，边操作边观察。