移动端动画卡顿主因是软件渲染，应优先用transform和opacity触发GPU加速，慎用will-change，控制合成层数量与尺寸，并配合合理缓动和时长。
移动端动画卡顿，多数是因为浏览器默认用软件渲染，没走 GPU 加速。开启硬件加速能显著提升流畅度，但不能滥用，否则反而增加内存开销、触发重绘抖动，甚至导致页面白屏或耗电加快。
优先用 transform 和 opacity 触发硬件加速
CSS 动画中，只有部分属性能高效触发 GPU 渲染。推荐只对 transform（如 translate3d、scale、rotate）和 opacity 做动画。它们不触发 layout 和 paint，仅影响合成层。
- ✅ 推荐写法：
transform: translate3d(0, 0, 0);或transform: translateZ(0); - ❌ 避免写法：
top、left、width、height、background-color等会频繁触发重排重绘的属性 - 示例：轮播图滑动用
transform: translateX(-50%);，别用left: -50%;
慎用 will-change，按需声明，及时清除
will-change 是提示浏览器“这个元素即将变化”，让其提前升格为独立合成层。但它不是万能开关，过度使用会提前创建过多图层，占用显存。
- ✅ 合理用法：在动画开始前 1–2 帧设置，动画结束后立即移除（例如用 JS 控制 class 切换）
- ❌ 错误用法：全局加在导航栏、列表项上；或长期保留在 hover 状态里
- 替代方案：对简单交互动画，
transform: translateZ(0)已足够；will-change更适合复杂多阶段动画
检查并减少合成层数量与尺寸
每个被加速的元素都会生成一个合成层（compositing layer），层数过多或单层过大（比如全屏模糊滤镜）会拖慢合成器性能。
立即学习“前端免费学习笔记（深入）”；
- 用 Chrome DevTools → Rendering → ✅ “Layer Borders” 查看当前合成层分布
- 避免给大图、长列表每一项都加
transform: translateZ(0) - 对
filter: blur()、backdrop-filter等高开销属性，限制作用区域，或降级为静态阴影替代
补充优化点：动画节奏与兼容性
硬件加速只是基础，还需配合合理的时间控制和降级策略：
- 动画时长建议 200–300ms，过长易感知卡顿，过短则丢失反馈感
- 用
@keyframes时搭配ease-out或cubic-bezier(.25,.46,.45,.94)（即easeInOutCubic），比linear更自然 - 对低端 Android（如 Android 5–7），可检测
prefers-reduced-motion或 UA，降级为淡入/位移等轻量效果
不复杂但容易忽略：真正决定移动端动画是否丝滑的，不是“有没有开 GPU”，而是“有没有让浏览器少干活”。聚焦 transform/opacity、按需升层、控制图层规模，再配上合理的缓动和时机，大多数卡顿问题都能解决。
