如何用javascript实现动画_css动画和requestanimationframe谁更优【教程】_技术教程

必须用 requestAnimationFrame 的情况是 CSS 无法实现的动画：贝塞尔曲线+随机扰动的粒子运动、拖拽中动态参数的缓动回弹、需逐帧读取布局信息（如 getBoundingClientRect）、与 Web Audio 精确同步的音画帧对齐。

纯 CSS 动画在绝大多数场景下比 requestAnimationFrame 手写 JS 动画更优—

—它更省电、更流畅、更易维护，且天然支持硬件加速和浏览器优化。只有当动画逻辑依赖运行时数据（比如鼠标位置、滚动偏移、物理模拟）或需精确控制暂停/跳帧/动态插值时，才该用 requestAnimationFrame。

什么时候必须用 `requestAnimationFrame`

不是“想自定义就用”，而是被 CSS 能力卡住时的必要选择：

transform 或 opacity 无法表达的运动逻辑，例如：粒子系统中每个点按贝塞尔曲线+随机扰动移动
动画状态需实时响应用户输入，例如：拖拽中跟随鼠标做缓动回弹，且回弹参数随拖拽距离动态变化
需要逐帧读取并修改 DOM 布局（如 getBoundingClientRect()），再基于结果决定下一帧行为——CSS 无法读取布局信息
与 Web Audio API 同步播放音效+视觉反馈，要求帧精度对齐（requestAnimationFrame 时间戳可与 audioContext.currentTime 对齐）

CSS 动画的隐藏性能陷阱

很多人以为加了 will-change: transform 就万事大吉，实际容易踩坑：

滥用 will-change：对非频繁变化的元素设置，反而触发不必要的图层提升和内存开销
动画属性选错：用 left/top 触发重排（layout），而应始终用 transform: translateX() 和 opacity
过度嵌套动画：父容器设 animation，子元素又设独立动画，可能因图层合并失败导致掉帧
未关闭非必要动画：页面不可见时（visibility: hidden 或 display: none）仍运行 CSS 动画，浪费 GPU 资源

验证方式：打开 Chrome DevTools → Rendering → 勾选 “FPS Meter” 和 “Paint Flashing”，观察是否持续高亮、帧率是否稳定在 60fps。

`requestAnimationFrame` 的正确写法和常见错误

直接调 requestAnimationFrame 不等于写出高性能动画。关键在避免强制同步布局和冗余计算：

function animate(lastTime) {
  const now = performance.now();
  const delta = Math.min(now - lastTime, 16); // 防止丢帧过大
// ✅ 在 rAF 回调里只做「读取」或「写入」，不要混用
const rect = element.getBoundingClientRect(); // 读取布局（仅此处）
// ✅ 所有样式更新集中到一次重排前完成
element.style.transform = translateX(${easeInOutCubic(delta / DURATION) * 100}px);
// ❌ 错误：在读取后又立即读取（触发二次 layout）
// element.offsetWidth; // 不要这样
if (isAnimating) {
requestAnimationFrame(animate);
}
}

永远用 performance.now() 而非 Date.now()，前者精度更高、不受系统时间调整影响
避免在回调中调用 getComputedStyle、offsetHeight 等触发重排的 API，除非你明确需要当前布局快照
用 element.animate()（Web Animations API）替代手动 requestAnimationFrame，它底层复用 CSS 动画引擎，支持时间轴控制且更省资源

真正难的不是选哪个 API，而是判断动画是否真的需要脱离 CSS 生命周期——多数所谓“复杂动画”，其实只是没拆解清「驱动源」和「表现层」。一旦把数据流（如 scrollY、mouseX）抽出来作为输入，渲染层依然可以交给 CSS。