17370845950

JavaScript动画核心在于控制requestAnimationFrame节奏、避免强制同步布局、用transform/opacity触发GPU加速；需分离状态计算与样式应用，用performance.now()和帧间插值实现精准动画。

JavaScript 动画效果不是靠“加个动画库”就完事的，核心在于你是否控制了 requestAnimationFrame 的节奏、是否理解 DOM 重排/重绘的代价、以及是否在用错时机更新样式。

为什么直接改 style.left 配合 setTimeout 效果差？

这种写法常见但低效：它绕过了浏览器的渲染调度机制，容易掉帧，且无法与屏幕刷新率同步。更严重的是，每次读取 offsetLeft 或写入 style.left 都可能触发强制同步布局（forced synchronous layout），尤其在循环中会指数级拖慢性能。

实操建议：

• 避免在动画循环中混用读写操作（比如先读 element.offsetTop，再立刻写 element.style.transform）
• 优先用 transform 和 opacity 触发 GPU 加速，它们不触发重排
• 用 getComputedStyle 替代 offsetTop 等属性读取，减少布局抖动风险

requestAnimationFrame 怎么写才不白用？

它只是告诉浏览器“下一帧请调用我”，但没规定你怎么更新状态或何时提交样式。很多人只把它当 setTimeout 的高刷替代品，却忘了做状态分离和帧间插值。

实操建议：

• 把动画逻辑拆成三部分：计算当前帧状态（如 progress = (Date.now() - startTime) / duration）、应用状态（如 el.style.transform = `translateX(${ease(progress) * 100}px)`）、递归调用自身
• 用 performance.now() 替代 Date.now()，精度更高，避免系统时间跳变干扰
• 动画结束时务必清除引用（如清空 rafId），否则可能内存泄漏

简单示例：

function animate(el, from, to, duration) {
  const start = performance.now();
  const rafId = requestAnimationFrame(function step(now) {
    const elapsed = now - start;
    const progress = Math.min(elapsed / duration, 1);
    const eased = progress; // 可替换为 easeOutCubic 等
    el.style.transform = `translateX(${from + (to - from) * eased}px)`;
    if (progress < 1) requestAnimationFrame(step);
  });
}

CSS 动画和 JS 动画到底该选哪个？

不是“JS 更灵活所以该用 JS”，而是看控制粒度需求。CSS @keyframes 适合声明式、固定路径的过渡；JS 适合需要响应用户交互（如拖拽跟随）、动态计算目标值、或逐帧干预（如物理模拟）的场景。

实操建议：

• 纯入场/退出动效（如 modal 淡入）、状态切换（如按钮 hover 缩放），优先

  

  用 transition 或 @keyframes，浏览器原生优化好
• 需要暂停、倒放、跳转到某进度、或根据鼠标位置实时调整的，必须用 JS 驱动 requestAnimationFrame
• 混合使用时，用 el.animate()（Web Animations API）比手写 RAF 更可控，但它在 Safari 中支持有限

动画卡顿的三个隐蔽原因

很多问题不是代码写错，而是被忽略的底层行为：

• will-change: transform 没加——对频繁动画元素提前提示浏览器准备图层，但别滥用，会增加内存开销
• 动画元素父容器用了 overflow: hidden 且子元素有 transform——某些版本 Chrome 会禁用合成层，导致回退到 CPU 渲染
• 监听了 scroll 或 resize 并直接触发动画——没节流或没用 passive: true，造成事件阻塞主线程

真正难的不是让东西动起来，是让动得稳、停得准、切得顺——这些细节藏在每一帧的读写顺序、每一处样式的触发条件、每一次 RAF 的生命周期管理里。