CSS 动画性能:GPU 加速与合成层

你写了一个动画,本该丝滑,结果在低端机和移动端上卡成 PPT。你怀疑是机器性能不够,其实是你的动画触发了浏览器的重排或重绘。

动画卡顿,90% 不是帧率目标设错了,而是你动错了属性。

本文从浏览器的像素管道讲起,讲清楚为什么只有 transform 和 opacity 配得上 60fps,以及 will-change、layout thrashing、prefers-reduced-motion 这些真正决定动画质量的细节。

一、动画卡顿的根因:重排与重绘

浏览器把一帧画到屏幕上,要走一条完整的「像素管道」:

JS → Style → Layout → Paint → Composite

• Style:重新计算选择器匹配、确定每个元素的最终样式。
• Layout(重排 / reflow):根据盒子模型重新计算每个元素的几何位置和大小。
• Paint(重绘):把元素画成一个个像素,绘制到多个图层上。
• Composite(合成):GPU 把这些图层按 z-order、transform 合并成最终画面。

这条管道上,越靠前的环节越贵。Layout 会牵一发动全身——一个元素宽度变了,兄弟元素、父元素、甚至全文档的几何都可能要重算。Paint 也不便宜,尤其是大面积、带阴影、带模糊滤镜的区域。Composite 最便宜,因为它只是 GPU 在已有图层上做矩阵运算。

动画卡顿的本质就是:你在每一帧里,反复触发了 Layout 或 Paint。

二、像素管道与「只走 Composite」的黄金法则

60fps 意味着每帧只有 16.6ms 的预算,扣掉浏览器自身开销,留给你的大概 10ms。在这 10ms 里跑一次完整的 Layout + Paint,基本不可能稳定 60 帧。

幸运的是,有两个属性天然只走 Composite:

• transform(translate / scale / rotate / skew)
• opacity

它们之所以快,是因为浏览器会为使用了这两个属性的元素(在满足条件时)单独开一个合成层(composited layer),直接交给 GPU。动画它们时,主线程不参与,布局和绘制都跳过,GPU 只是对这张已经画好的「纹理」做仿射变换或透明度混合——每一帧都是恒定开销,跟元素面积无关。

这就是所谓 GPU 加速 / 硬件加速 的真相:不是属性本身魔法,而是它让元素被提升为独立图层,后续动画只在合成阶段发生。

所以动画的第一原则是:只动画 transform 和 opacity。需要移动?用 transform: translate()。需要放大缩小?transform: scale()。需要显隐?opacity。

三、好动画 vs 坏动画:代码对比

先看坏榜样。一个最常见的错误——用 left/top 做位移动画:

/* 坏:每帧都触发 Layout,主线程爆掉 */
.box {
  position: absolute;
  left: 0;
  transition: left 0.3s ease;
}
.box.move { left: 200px; }

left/top/margin/width/height 这些属性会改变元素的几何,每一帧都强制浏览器重新 Layout,父级、兄弟节点跟着重排,然后还要 Paint、Composite。在低端机上,这一个动画就能把帧率拉到 20fps 以下。

正确写法——用 transform:

/* 好:只走 Composite,GPU 接管,60fps 稳定 */
.box {
  position: absolute;
  left: 0;
  transform: translateX(0);
  transition: transform 0.3s ease;
  will-change: transform;
}
.box.move { transform: translateX(200px); }

对比一下:

• 几何属性(left/top/margin/width/height/padding):触发 Layout → Paint → Composite,主线程卡。
• color/background/border-color/box-shadow:跳过 Layout,但仍要 Paint,大面积时仍会掉帧。
• transform/opacity:只 Composite,GPU 干活,稳。

一个经验法则:在动效里搜一遍,凡是动画了 transform 和 opacity 以外的属性,先停下来想想——能不能用合成属性改写?95% 的情况,能。

比如「进度条宽度增长」,新人写 width: 0 → 100%,老手写 transform: scaleX(0 → 1),加上 transform-origin: left center,效果一样,性能天差地别。

四、will-change:用得好是利器,用得烂是负担

will-change 是一个「告知」属性的 API:你提前告诉浏览器「这个元素马上要变化」,浏览器就有机会提前为它创建合成层、预分配资源,第一帧不卡。

.modal-card {
  will-change: transform, opacity;
}

但 will-change 是有代价的。它会让元素常驻合成层,占用额外的 GPU 内存;每个合成层都要维护一张纹理,层级过多会导致内存暴涨、合成本身变慢(overdraw 增加)。把 will-change 加到列表的每一项、加到全局,是最常见的误用:

/* 大忌:每个元素都常驻合成层,内存和合成开销爆炸 */
li { will-change: transform; }

正确姿势有三条:

1. 只在马上要动的元素上加,动完移除。可以配合 JS:mouseenter 时加,transitionend 时去掉。
2. 不要长期挂着。它是「即将变化」的提示,不是性能开关。一个常年不动还挂着 will-change 的元素,纯粹是浪费。
3. 范围尽量小,只写真正会变的属性,而不是 will-change: all(这玩意儿既不规范也无意义)。

简单判断:will-change 解决的是「动画开始第一帧卡一下」的冷启动问题,不是「动画全程都卡」的解药。全程卡,问题在属性和 layout,不在 will-change。

五、layout thrashing:读写交替的隐形杀手

合成层动画本身很轻,但如果你在动画的每一帧里用 JS 读 DOM 的几何信息,会触发强制同步布局(forced synchronous layout / reflow),把主线程拖死:

// 坏:读一个写一个,每轮循环都强制浏览器立刻算一次 layout
boxes.forEach((box) => {
  const width = box.offsetWidth;       // 读 → 触发 layout
  box.style.width = width + 10 + 'px'; // 写 → 让 layout 失效
});

浏览器本来会把多次写操作合并、推迟到下一帧统一算 layout。但你中间插了一次「读」(offsetWidth / getBoundingClientRect / scrollTop / clientHeight 等),浏览器为了给你一个准确的值,只能立刻把当前所有写操作 flush 出来、算一遍 layout。循环 N 次,就强制重排 N 次。这就是 layout thrashing(布局抖动)。

正确写法是批量读、批量写:

// 好:先读完,再统一写,layout 只算一次
const widths = boxes.map((box) => box.offsetWidth); // 全部读
boxes.forEach((box, i) => {
  box.style.width = widths[i] + 10 + 'px';          // 全部写
});

或者用 requestAnimationFrame,把写操作推到下一帧;更复杂的场景可以用 FastDOM 这类库把读写队列化。在 React 里,避免在 render 阶段读 DOM 几何(本来就是反模式),用 ref + useLayoutEffect,并且只读不写,或读完缓存值再异步写。

一句话:读写分离,never 交替。

六、prefers-reduced-motion:无障碍不是可选项

有一部分用户(前庭功能障碍、晕动症、低视力)对动画敏感,持续位移、闪烁、大幅缩放会让他们眩晕甚至恶心。操作系统和浏览器都提供了「减少动态效果」的偏好开关,CSS 通过 prefers-reduced-motion 媒体查询暴露出来。

尊重它是工程师的本分,而不是 nice-to-have:

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

把时长压到几乎为 0、循环次数设为 1,动画「瞬间完成」,功能不丢,但不再产生运动。注意:不要直接 display: none 掉动画,也不要 opacity 隐藏元素——那会破坏功能状态切换。降级的是「动效」,不是「结果」。

进阶做法是分级:核心交互动画(状态切换反馈)保留极短时长,纯装饰动画(入场、视差、背景循环)在 reduce 模式下直接关闭。

在 JS 里也能读到这个偏好:window.matchMedia('(prefers-reduced-motion: reduce)').matches,用来决定要不要启动 GSAP、WebGL 粒子这类重型动效。

七、调试:用 DevTools 看清每一帧

写完动画不等于结束,得上工具验证。

1. Performance 面板:Cmd/Ctrl + E 录制一段,看帧序列。绿色条是 60fps,黄色/红色条就是掉帧。点开某一帧,下面的火焰图会告诉你这一帧时间花在哪——Layout?Paint?JS?如果 Layout 和 Paint 反复出现在每一帧,说明你动错了属性。

2. Layers 面板(更多工具里开启):可视化所有合成层,看哪些元素被提升成了独立 layer、层级有多少、纹理多大、overdraw 是否严重。如果一个不需要动画的元素被莫名提升成合成层(比如 will-change 乱加、或 transform: translateZ(0) 满天飞),这里会一目了然。

3. Rendering 面板:勾选 Paint flashing,页面重绘的区域会闪绿色;勾选 Layer borders、FPS meter,实时看帧率和合成层边界。这是排查「为什么我一动画整个屏幕都在闪」最快的方法。

实战定位流程:Performance 看是不是掉帧 → 火焰图看掉帧原因(Layout / Paint / JS)→ Paint flashing 看重绘范围 → Layers 看合成层数量和纹理大小。四步走完,90% 的动画性能问题无处遁形。

小结

• 只动 transform 和 opacity:它们是合成属性,只走 Composite,GPU 接管,稳 60fps。其他属性都有 layout 或 paint 代价。
• 几何属性是动画禁区:left/top/margin/width/height 每帧触发重排,必卡。把位移改成 translate、缩放改成 scale。
• will-change 是提示不是开关:只在即将变化的元素上短暂使用,动完移除;全局滥用反而吃内存、拖慢合成。
• 读写分离,告别 layout thrashing:JS 里绝不读写交替操作 DOM 几何,批量读、批量写,或推到 requestAnimationFrame。
• 尊重 prefers-reduced-motion,DevTools 验证帧率:无障碍降级是工程师本分;Performance + Layers + Paint flashing 三件套,让每一帧的耗时无所遁形。

一句话金句:动画的丝滑,不是堆出来的,是「少干活」省出来的——最好的那一帧,是浏览器根本没重排、没重绘的那一帧。