安卓WebView中transition卡顿主因是混用非合成属性触发CPU渲染，应仅用transform/opacity、禁用transition:all、通过Layer Borders验证图层提升并动态管理will-change。
安卓浏览器（尤其是 Android 5–8 的 WebView）里 transition 卡顿，基本不是动画写得不够“顺”，而是你无意中触发了 CPU 渲染——只要混入一个非合成属性，整条过渡就退化，帧率掉到 20fps 以下，且不报错、不警告。
为什么 transition: left 0.3s 在安卓上必卡
改 left 或 top 会强制每帧重排（reflow），浏览器得在主线程里重新计算盒模型、流式布局、文本换行……低端机一帧耗时直接冲到 5–10ms，远超 16.67ms 的 60fps 阈值。而 transform: translateX() 只挪 GPU 图层，不碰 layout/paint，才是真·合成动画。
- 错误写法：
transition: left 0.3s, background-color 0.3s;→ 只要任一属性非合成，整条过渡降级 - 正确写法：
transition: transform 0.3s, opacity 0.3s;→ 且 JS 或 class 切换时，只改这两个属性 - 绝对别用：
transition: all 0.3s—— 它是隐形炸弹，某次改了margin或color就悄悄卡住
哪些 CSS 属性一用就拖垮 transition
安卓 WebView 对非合成属性极其敏感，混用即降级，且毫无提示。这些属性哪怕只出现在 @keyframes 或 transition 声明里，整段动画就回退到 CPU 渲染：
-
top/left/margin/width/height：改一次就触发重排，主线程瞬间堵死 -
box-shadow（尤其动态变化值）：阴影重建反复销毁/创建合成层，滚动中容易变淡或消失 -
filter: blur()和drop-shadow()：CPU 做高斯模糊，blur(1px)就可能拖垮动画 -
background-color、border-radius：触发重绘（repaint），高 DPI 屏上卡顿更明显
如何确认 GPU 加速真生效了
写了 transform: translateZ(0) 不等于就加速了。关键看浏览器是否真建了独立图层：
立即学习“前端免费学习笔记（深入）”；
- Chrome DevTools → Rendering → 勾选 “Layer Borders”：有绿色边框才是被提升的合成层
- 若没绿框，检查父容器是否含
overflow: hidden、filter、mask或clip-path—— 这些会抑制子元素提层 - 临时加
transform: translate3d(0, 0, 0)强制升层（比translateZ(0)在 Android 5.1 WebView 中更稳） - 慎用
will-change: transform：静态全局加等于提前塞满 GPU 内存；推荐 JS 动态加：el.style.willChange = 'transform'，transitionend后立刻设为'auto'，iOS Safari ≤16ms 动画可能不触发事件，加setTimeout(() => el.style.willChange = 'auto', duration + 100)兜底
滚动中 transition 卡顿怎么破
滚动监听里写 transition 是高危操作，常见问题不是动画本身，而是同步读写样式引发 layout thrashing：
- 避免在
scroll事件里读取offsetTop或getBoundingClientRect()后立刻写style.transform—— 旧版 WebView 会强制每帧同步 layout - 用
requestAnimationFrame包裹读操作，确保“先批量写，下一帧再读” - 滚动中禁用
transition：改用transform直接赋值（无过渡），或用page-container的enter/afterenter生命周期控制时机 - 视差效果别用
background-position动画（部分旧 Android 不硬件加速），改用transform: translateX()模拟
真正卡住的，往往不是“要不要用 transition”，而是有没有把过渡严格限定在 transform 和 opacity 上、有没有避开 WebView 的解析盲区、有没有让动画和滚动/JS 状态严格对齐。漏掉任一环，安卓 H5 的 transition 就大概率失灵。
