跳到主要内容

如何使用 CSS 实现“硬件加速”？

面试速答（30 秒版 TL;DR）​

  • 面试里说的“CSS 硬件加速”，本质是让动画尽量走 合成（Composite） 阶段，由 GPU 参与，把重排/重绘压力降到最低。
  • 实践口诀：动画只动 transform/opacity；必要时用 will-change: transform 让浏览器提前准备合成层（但别滥用）。
  • 验证方法：Chrome DevTools 看 Performance 面板的 Layout/Paint/Composite 占比，以及 Layers/Rendering（Paint flashing）。

心智模型：你在优化的是“渲染路径”​

浏览器渲染可以粗略分成：

  • Style（样式计算）
  • Layout（布局/回流）
  • Paint（绘制）
  • Composite（合成/图层拼接）

面试回答可以补一句（很加分）：

  • “硬件加速”不是一个 CSS 开关，而是浏览器的优化策略；我们能做的是选择更容易被合成器优化的属性与写法。

延伸阅读（本站已有更系统的性能文档）：CSS 在性能优化方面有哪些实践？。

实践 1：动画只动 transform/opacity​

最常见的对比题：用 left/top 移动 vs 用 transform 移动。

/* 不推荐：通常触发布局（Layout） */
.bad {
  position: relative;
  transition: left 200ms ease;
}
.bad.is-open {
  left: 200px;
}

/* 推荐：通常可以只走 Composite */
.good {
  transition: transform 200ms ease;
}
.good.is-open {
  transform: translateX(200px);
}

实践 2：will-change（提示浏览器提前做准备）​

will-change 的正确姿势：短期使用，只在即将发生动画时打开。

.card.is-animating {
  will-change: transform;
}

思路（可用 JS/状态类控制）：

  • 动画开始前加上 .is-animating
  • 动画结束后移除，避免长期占用图层资源

实践 3：translateZ(0) / translate3d(...)（老技巧，面试认识即可）​

你可能见过这种写法：

.hack {
  transform: translateZ(0);
}

它常用于“促使创建合成层”的旧技巧。面试里可以这样表述：

  • 了解这种 hack，但工程里更推荐 will-change，并且要控制使用时机与数量。

如何验证是否“真的加速了”​

  • DevTools Performance：看是否减少 Layout/Paint，更多落在 Composite。
  • DevTools Layers：观察是否产生了新的合成层（注意：有层不代表一定更快）。
  • DevTools Rendering：打开 Paint flashing，看动画时是否发生大面积重绘。

典型题 & 标准答法​

Q1：will-change 是不是越多越好？​

答：不是。它会增加图层与内存开销，滥用可能更慢。正确做法是对“即将动画”的少量元素短期开启，用完关闭。

Q2：为什么 transform/opacity 往往更流畅？​

答：因为它们更可能绕开布局与重绘，直接在合成阶段改变图层的位移/透明度，减少主线程压力。

易错点/坑​

  • 图层太多：内存飙升、合成开销变大，反而掉帧。
  • 文字发虚：某些场景下 3D transform/子像素位移可能导致文字抗锯齿表现变化。
  • transform 会创建新的层叠上下文：可能影响 position: fixed 子元素与 z-index。

速记要点（可背诵）​

  • 让动画尽量只走 Composite：优先 transform/opacity。
  • will-change 是“提示”不是“强制”，且必须少量短期使用；验证用 DevTools。