17370845950

requestAnimationFrame比setTimeout更可靠，因其自动对齐60fps渲染节奏；应记录performance.now()起始时间、避免强制同步布局、启用硬件加速并减少裁剪计算。

用 requestAnimationFrame 做平滑动画比 setTimeout 更可靠

浏览器渲染帧率通常为 60fps，requestAnimationFrame 会自动对齐这一节奏，而 setTimeout(fn, 16) 只是“尽力而为”，实际执行时机受 JS 主线程阻塞影响，容易掉帧或抖动。

实操建议：

• 始终把动画逻辑写在 requestAnimationFrame 回调里，不要嵌套多层 setTimeout
• 动画开始前先记录起始时间（performance.now()），避免用 new Date()——精度低且可能被系统时钟调整干扰
• 每次回调中只做计算 + 修改样式，不触发强制同步布局（比如读取 offsetTop 后立刻改 style.left）

let startTime = null;
const animate = (timestamp) => {
  if (!startTime) startTime = timestamp;
  const elapsed = timestamp - startTime;
  const progress = Math.min(elapsed / 1000, 1); // 1秒完成
  element.style.transform = `translateX(${progress * 200}px)`;
  if (progress < 1) requestAnimationFrame(animate);
};
requestAnimationFrame(animate);

CSS transition 和 transform 配合最省心

纯 CSS 动画在大多数场景下性能更好、代码更短，尤其适合状态切换类动效（如展开/收起、悬停反馈）。关键在于：只对 transform 和 opacity 做过渡，这两者能走合成层，不触发重排重绘。

常见错误现象：

• 给 left/top 加 transition → 每次都触发 layout，卡顿明显
• 在 class 切换后立刻读取 offsetHeight → 强制同步布局，打断动画流水线
• 没加 will-change: transform（仅对复杂动画必要）→ GPU 提前准备不足，首帧延迟

.box {
  transition: transform 0.3s ease, opacity 0.3s ease;
}
.box.active {
  transform: translateX(100px) scale(1.1);
  opacity: 0.8;
}

用 Element.animate() 控制复杂关键帧动画

当需要多段变化、暂停/播放、精确时间控制（比如和音频同步），原生 Element.animate() 是比手写 requestAnimationFrame 更简洁的选择，且自带缓动、迭代、填充模式支持。

使用场景：

• 图标脉冲、加载旋转、路径描边动画
• 需要响应用户交互暂停/反向播放的动效
• 多个属性同时按不同曲线变化（如位移+缩放+透明度）

注意点：

• animate() 返回的 Animation 对象必须保存引用，否则会被 GC，动画立即停止
• Chrome/Firefox 支持良好，Safari 16.4+ 才完整支持 iterationStart 等高级参数
• 避免在循环中反复调用 animate() 创建新实例，应复用或调用 cancel() + play()

const anim = element.animate(
  [
    { transform: 'scale(1)', opacity: 1 },
    { transform: 'scale(1.2)', opacity: 0.5 }
  ],
  {
    duration: 600,
    easing: 'cubic-bezier(0.34, 1.56, 0.64, 1)',
    fill: 'forwards'
  }
);
// 后续可控制
anim.pause();
anim.reverse();

动画卡顿？先查是否触发了 Layout 或 Paint

90% 的“动画慢”问题不是代码写得不够快，而是无意中让浏览器做了大量额外工作。用 Chrome DevTools 的 **Rendering > Paint flashing** 和 **Layers** 面板能快速定位。

典型诱因：

• 动画中读取 offsetWidth、getBoundingClientRect()、computedStyle → 触发强制同步布局
• 频繁修改 innerHTML 或添加 DOM 节点 → 触发重排
• 用 background-image 做渐变动画 → 每帧都触发 Paint，且无法硬件加速
• 元素没有独立合成层（缺少 transform: translateZ(0) 或 will-change）→ 在主图层上绘制，拖慢整页

一个容易被忽略的点：动画元素的父容器如果有 overflow: hidden 且子元素超出，每次 transform 变化都可能触发额外裁剪计算。能不用就不用。