根本原因是旧版WebKit WebView合成层管理失控，需优先用全前缀backface-visibility: hidden加在动画元素本身；Android 4.4–5.1则需禁用该属性改用动态translate3d；同时须确保animation-fill-mode与关键帧一致。
为什么安卓低版本（尤其是2.2–4.4）CSS3动画会闪屏
根本原因不是“没开硬件加速”，而是合成层（compositing layer）管理失控：旧版WebKit WebView对transform的解析不稳定，尤其在同时使用translate和scale、或动画首帧/结束帧触发重绘时，容易回退到CPU软件渲染，造成首帧空白、图层撕裂或背面意外显示。Android 2.2甚至会把-webkit-transform: matrix()直接解析错误。
优先用backface-visibility: hidden而不是translate3d(0,0,0)
这是最轻量、兼容性最好、副作用最小的修复手段，应作为第一道防线加在动画元素本身上：
- 必须写全前缀：
-webkit-backface-visibility: hidden、-moz-backface-visibility: hidden、backface-visibility: hidden - 不要加在父容器上——只加在真正执行
transform或animation的元素上（比如.num、.slide） - 在Android 4.4–5.1 WebView中，
backface-visibility: hidden反而可能抑制图层创建，此时要禁用它，改用transform: translate3d(0,0,0)+will-change: transform动态注入 - 避免和
filter、mask、overflow: hidden共用，这些属性在旧WebView中会强制降级为CPU渲染
translate3d(0,0,0)不是万能药，要按场景启用
它确实能触发GPU加速，但在低版本安卓上极易引发新问题：
- 静态写死在CSS里（如
.item { transform: translate3d(0,0,0); }）会导致图层爆炸，Android 5–7 WebView内存溢出、滚动卡顿 - 若动画只是
opacity变化，加translate3d毫无意义，还增加内存开销 - 真正该用的场景很窄：仅当Android 5–7或iOS 9–11中，
@keyframes入场动画首帧明显卡顿，且已确认是合成层未就绪时，才由JS在animationstart事件中动态添加，动画结束后立即移除 - 顺序很重要：先平移再缩放，即
transform: scale(1.2) translateX(20px)比translateX(20px) scale(1.2)在Android 2.2上更稳定
别忽略animation-fill-mode和关键帧一致性
很多“闪”其实不是渲染问题，而是逻辑跳变：
- 动画循环时突然回跳到初始状态？补上
animation-fill-mode: forwards或both - 缩放动画结束时“抽搐一下”？检查
@keyframes最后一帧是否和元素默认transform完全一致（包括空格、单位、顺序） - 使用
steps()时闪动？说明步进数与实际帧率不匹配，改用linear或手动调animation-duration -
background-image切换导致的闪？那是资源加载问题，和backface-visibility无关，需预加载或用opacity+z-index叠层过渡
真正稳定的动画，从来不是靠堆砌translateZ(0)或perspective，而是在明确设备能力的前提下，控制好合成层生命周期、守住关键帧边界、并让backface-visibility落在正确层级上。低版本安卓的“闪”，往往是一连串微小决策叠加的结果，而不是某一个属性没加对。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
