实现丝滑动画效果的CSS技巧与性能优化实践

又踩坑了，动画卡顿问题折腾了一天

昨天做移动端页面的时候，遇到一个特别烦人的动画性能问题。用CSS做的一个卡片滑动效果，在低端安卓机上卡得不行，掉帧严重。这里我踩了个坑，一开始以为是样式写得不够精简，结果折腾了半天发现根本不是这回事。

这个项目是一个活动页，要求用户上下滑动时，卡片会有视差滚动的效果。代码逻辑其实挺简单的：

window.addEventListener('scroll', () => {
  const scrollTop = window.scrollY;
  document.querySelectorAll('.card').forEach((card, index) => {
    card.style.transform = translateY(${scrollTop * (index + 1) * 0.2}px);
  });
});

看起来没什么问题对吧？但实际运行起来，特别是在一些老安卓机上，就露馅了。

排查过程：从CSS到JS都试了一遍

最先怀疑的是CSS部分，毕竟之前踩过不少关于重绘重排的坑。于是把所有可能触发layout的操作都检查了一遍：

• 确保用了transform而不是直接修改top
• 把will-change: transform加上去
• 确认没有使用昂贵的box-shadow和复杂的渐变

改完这些后发现还是卡，真是让人头大。后来试了下把JS里的scroll事件监听去掉，直接写死动画值，发现流畅了不少。这才意识到问题出在scroll事件的处理频率上。

三种方案对比，我选了最简单的

针对scroll事件的优化，我试了三种方案：

• 防抖（Debounce）：通过设置定时器来降低触发频率。确实能减少调用次数，但动画会变得断断续续。
• 节流（Throttle）：限制一定时间内的最大触发次数。效果比防抖好点，但依然不够平滑。
• requestAnimationFrame：这才是正解！利用浏览器原生的动画帧调度机制，可以完美匹配屏幕刷新率。

核心代码就这几行

最终改成用requestAnimationFrame来处理动画更新，代码如下：

let ticking = false;

window.addEventListener('scroll', () => {
  if (!ticking) {
    window.requestAnimationFrame(() => {
      const scrollTop = window.scrollY;
      document.querySelectorAll('.card').forEach((card, index) => {
        card.style.transform = translateY(${scrollTop * (index + 1) * 0.2}px);
      });
      ticking = false;
    });
    ticking = true;
  }
});

这里要注意一个小细节：ticking标志位一定要加，否则会出现重复触发的问题。另外，我把动画计算放在了requestAnimationFrame里，这样就能保证每次屏幕刷新时只执行一次动画更新。

踩坑提醒：这三点一定注意

在这个过程中，我总结了几个容易踩坑的地方：

• 不要过度依赖CSS动画：虽然CSS动画性能通常比JS好，但在需要动态计算的场景下，还是要用JS来控制。
• 慎用scroll事件：这个事件的触发频率非常高，很容易造成性能瓶颈。记住要搭配节流或者requestAnimationFrame使用。
• 测试设备要多样化：这次问题就是在高端机上完全看不出异常，但在低端机上就原形毕露了。建议多找几台不同配置的手机测试。

还有一些小瑕疵

虽然改完后整体流畅度提升了很多，但还是有两点不太满意的地方：

• 快速滑动时偶尔会出现一点延迟，特别是在首屏加载还没完成的时候
• 在某些特殊机型上（比如某款老版小米），动画依然会有轻微的卡顿感

不过考虑到项目工期和实际影响范围，暂时就这样了。等以后有空再研究下Web Worker或者其他更激进的优化方案。

以上是我踩坑后的总结

经过这一番折腾，总算把这个动画性能问题给搞定了。其实很多时候我们遇到的性能问题，本质上都是因为对浏览器渲染机制理解不够深入。就像这次，要是早知道scroll事件这么耗性能，一开始就该想到用requestAnimationFrame来处理。

如果你也有类似的经验或者更好的解决方案，欢迎在评论区交流。这类性能优化的话题，我觉得还挺值得深挖的。