GSAP动画实战：从入门到项目优化的完整指南

优化前：卡得不行

上个月接了个移动端动画需求，用 GSAP 做一整屏的交互动画，元素多、层级深、还有滚动联动。一开始写得挺顺，效果也炫，但真机一跑——直接卡成幻灯片。iPhone 12 都扛不住，低端安卓机直接白屏几秒。用户反馈“点一下卡三秒”，我看着 Performance 面板里满屏的红色警告，心里直发毛。

最离谱的是，页面加载完后，光是静止不动，FPS 就掉到 30 以下。一动就崩。当时我就知道，这代码肯定哪里写炸了。

找到瓶颈了！

先打开 Chrome DevTools 的 Performance 面板，录了一段操作。结果一目了然：主线程被大量 layout 和 paint 占满，尤其是每次 gsap.to() 触发时，浏览器疯狂重排重绘。再看 Layers 面板，几十个 DOM 元素全被提升成了独立图层，GPU 内存直接爆了。

问题出在哪？我用了太多 transform 以外的属性做动画，比如 width、height、甚至 box-shadow。这些属性一动，浏览器就得重新计算布局，性能开销巨大。而且我还在 scroll 事件里直接调用 GSAP，没做任何节流，导致每帧都触发动画更新，CPU 直接干烧了。

还有一个隐藏坑：我用了 stagger 批量动画，但没限制同时运行的动画数量。一个列表有 50 项，全一起动，GSAP 内部调度器直接卡死。

核心优化：只动 transform 和 opacity

第一条铁律：**移动端动画，只用 transform 和 opacity**。其他属性一律别碰。这两者可以被 GPU 加速，不会触发 layout/paint。

比如原来这段代码：

gsap.to(".card", {
  width: "100px",
  height: "100px",
  backgroundColor: "#ff0000",
  duration: 0.5
});

改成：

// 先用 CSS 固定尺寸和颜色
// .card { width: 100px; height: 100px; background: #ff0000; }
gsap.to(".card", {
  scale: 1,
  opacity: 1,
  duration: 0.5
});

对，你没看错——把视觉变化用 CSS 静态定义好，GSAP 只负责控制显隐和缩放。这样动画完全走合成层，性能飙升。

这里注意我踩过好几次坑：box-shadow、border-radius 这些看似无害的属性，其实也会触发 paint。如果非要用，建议用伪元素 + transform 模拟，或者干脆用图片代替。

滚动联动：别在 scroll 里直接跑 GSAP

原来我这么写：

window.addEventListener("scroll", () => {
  gsap.to(".header", { y: -window.scrollY * 0.5 });
});

结果每滚动一像素，就新建一个 GSAP 实例，内存泄漏+主线程阻塞。改法很简单：**用 gsap.quickTo 或预创建 timeline**。

现在我这么干：

const headerY = gsap.quickTo(".header", "y", { duration: 0.1 });
window.addEventListener("scroll", () => {
  headerY(-window.scrollY * 0.5);
});

quickTo 会复用同一个 tween 实例，避免重复创建。实测内存占用降了 70%。

如果逻辑复杂，就提前建好 timeline，用 progress() 控制：

const scrollTimeline = gsap.timeline({ paused: true })
  .to(".title", { y: -100, opacity: 0 })
  .to(".image", { scale: 1.2 }, 0);

window.addEventListener("scroll", () => {
  const progress = Math.min(1, window.scrollY / 500);
  scrollTimeline.progress(progress);
});

这样 GSAP 只计算一次关键帧，滚动时只是调整进度，性能稳如老狗。

批量动画：控制并发数量

之前用 stagger 一次性动 50 个元素，低端机直接卡死。后来我加了个简单限制：只动画视口内的元素。

配合 Intersection Observer，只对可见元素启动动画：

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      gsap.from(entry.target, {
        y: 50,
        opacity: 0,
        duration: 0.6
      });
      observer.unobserve(entry.target); // 动一次就停
    }
  });
});

document.querySelectorAll(".item").forEach(item => {
  observer.observe(item);
});

这样首屏只动 5-10 个，后续滚动再逐个激活，CPU 压力小多了。

其他小技巧（带过）

• 禁用 will-change：很多人以为加 will-change: transform 能提升性能，其实滥用反而增加内存。GSAP 自动处理合成层，不用手动加。
• 避免嵌套动画：父元素动画时，子元素尽量别同时动，容易触发复合层爆炸。
• 用 autoAlpha 代替 opacity + visibility：autoAlpha: 0 会自动设 visibility: hidden，避免不可见元素仍接收事件。

性能数据对比

优化前后，我在 Redmi Note 10（中低端安卓机）上实测：

• 首屏加载时间：从 5.2s 降到 800ms
• 滚动 FPS：从平均 22 FPS 提升到 58 FPS
• 内存占用：从 180MB 降到 95MB
• 动画卡顿率（jank）：从 40% 降到 2%

最爽的是，现在低端机也能丝滑跑完整套动画，用户投诉清零了。

最后说两句

GSAP 本身性能其实很强，问题多半出在我们怎么用。记住：**少动 layout 属性、复用实例、控制并发**，基本能解决 90% 的性能问题。

当然，我的方案也不是完美的。比如那个 Intersection Observer 方案，在快速滚动时偶尔会有元素没及时动画，但加个 rootMargin: "100px" 就能缓解，无伤大雅。

以上是我踩坑后的总结，希望对你有帮助。有更优的实现方式欢迎评论区交流，比如你们怎么处理超长列表的 GSAP 动画？我还在找更好的方案。