根本原因是合成层创建失败或管理失控，需优先用全前缀backface-visibility: hidden加在动画元素本身；Android 4.4–5.1则需禁用该属性改用动态translate3d；同时须确保animation-fill-mode与关键帧一致。
低版本 Android（尤其是 2.2–5.1）中 CSS3 动画卡顿，根本不是“没开 GPU 加速”，而是浏览器合成层（Compositing Layer）创建失败或管理失控——transform 被解析为软件渲染、opacity 不触发建层、甚至动画首帧直接回退到 CPU 绘制。强行加 translate3d(0,0,0) 或 will-change: transform 反而容易引发图层爆炸、内存溢出、滚动卡死。
为什么 top/left 动画在 Android 4.4 WebView 里必卡
Android 4.4 的 WebView 基于旧版 Chromium（约 Chrome 30），它对 top 和 left 的变更会强制触发同步重排（reflow），每帧都要重新计算布局树，主线程被堵死。实测一帧耗时常达 8–12ms，远超 16.67ms 的 60fps 阈值。
- 错：
@keyframes slide { to { left: 200px; } }→ 全流程降级，CPU 满载 - 对：
@keyframes slide { to { transform: translateX(200px); } }→ 仅走 composite，但前提是元素已提升为独立图层 - 关键陷阱：即使写了
transform，若元素未提前建层（比如没加backface-visibility: hidden或translateZ(0)），旧 WebView 仍可能在动画第一帧才临时建层，造成明显卡顿
Android 2.2–4.3 必须加全前缀 backface-visibility: hidden
这是兼容性最好、副作用最小的建层手段，比 translate3d(0,0,0) 更稳。它不改变视觉，只告诉浏览器“这个元素背面永远不可见”，从而触发图层提升。
- 必须写三行：
-webkit-backface-visibility: hidden、-moz-backface-visibility: hidden、backface-visibility: hidden - 只加在动画元素本身上（如
.slide-item），不要加到父容器 - 禁用场景：Android 4.4–5.1 中该属性有时会抑制建层，此时需移除并改用动态
translate3d - 不能和
filter、overflow: hidden共用，否则旧 WebView 会强制回退到 CPU 渲染
Android 4.4–5.1 中慎用静态 translate3d(0,0,0)
这个版本的 WebView 对静态 3D transform 敏感：写死在 CSS 里会导致图层无法释放，一屏 20 个列表项就可能吃光内存、滚动卡顿。
Android 开发调试技能，通过系统 ADB 工具操作 Android 设备。以下场景必须触发此技能：(1) 直接 ADB 操作——安装 APK、查看设备列表、抓取 logcat 日志、查看已安装应用、清除应用数据、截图、重启设备、拉取/推送文件、查看 CPU/内存/电池信息、adb shell 操作；(2)...
立即学习“前端免费学习笔记（深入）”；
- 正确做法：在
animationstart或touchstart事件中，用 JS 动态添加transform: translate3d(0,0,0)；监听animationend后立刻设为transform: none - 仅当动画是入场位移（如从右滑入）且首帧明显卡顿时才启用，纯
opacity动画加它毫无意义 - 顺序很重要：
transform: scale(1.2) translateX(20px)比translateX(20px) scale(1.2)在 Android 2.2 上更稳定 - 绝对不要写
* { transform: translate3d(0,0,0); }—— 这等于给整个 DOM 提前建层，低端机直接 OOM
验证是否真进了 GPU 合成管线
别信“看起来流畅”，要靠 Chrome DevTools 实锤。在 Android 设备上远程调试时：
- 打开
Layers面板，悬停动画元素，确认显示Composited标签且有清晰图层边界 - 在
Performance面板录制动画，火焰图里只应有Composite Layers块，不能出现Layout或Paint - 启用
Rendering → Paint flashing，动画期间屏幕不该大面积绿色闪烁（否则仍在重绘） - iOS Safari 对
will-change支持不稳定，优先用transform: translateZ(0)实测
真正卡顿的根源，往往是你以为“开了加速”，其实动画还在主线程里排队等重排——而浏览器不会报错，它只是默默变慢。
