旧安卓 WebView 渲染器存在图层泄漏问题：will-change 触发内存持续增长致 OOM；嵌套 transform 导致图层爆炸；ScrollReveal.js 等库引发主线程阻塞与图层堆积；关键在动画后未清理图层，需通过 Rendering 面板验证图层数量是否回落。
旧安卓 WebView 渲染器吃不消 will-change
Android 4.4–6.0 的系统 WebView（基于 Blink 旧分支）对 will-change 极其敏感，哪怕只在单个元素上设 will-change: transform，只要动画持续运行，就可能触发渲染线程内存持续增长，最终 OOM 崩溃。这不是 CSS 写错了，而是底层合成器资源管理机制缺陷。
实操建议：
- 全局搜索项目中所有
will-change声明，**优先删除**；仅当动画卡顿严重且已确认是合成层缺失导致时，才考虑局部启用 - 若必须用，改用更保守的写法：
will-change: transform仅在动画开始前 1 帧动态添加，动画结束立即removeProperty('will-change') - 避免在
@keyframes中通过animation-timing-function频繁触发动画重绘——旧引擎会为每次重绘新建图层缓存
嵌套 transform 动画叠加引发图层爆炸
当多个父容器同时设了 transform（比如 scale(0.95) + translateZ(0) + rotate(2deg)），旧安卓机无法复用合成图层，会为每一层单独分配 GPU 内存，3 层嵌套就可能吃掉 40MB+，远超 WebView 默认上限。
实操建议：
- 用
getComputedStyle(el).transform在真机控制台检查实际生效的 transform 矩阵，确认是否有多余嵌套 - 把多层 transform 合并到最内层元素：例如把父容器的
translateX和子元素的scale全部移到子元素上，用单个transform: translateX(...) scale(...) - 禁用所有非必要过渡效果：移除
transition: all或未限定属性的transition，旧引擎会为每个可动画属性预分配缓冲区
ScrollReveal.js 等库在低端机上的隐式开销
ScrollReveal.js 默认为每个目标元素创建 IntersectionObserver 实例，并在进入视口时批量触发 transform + opacity 动画。在 Android 5.1 上，10 个元素就可能造成主线程阻塞 + 合成图层堆积，进而触发内存回收失败。
实操建议：
- 降级使用原生
IntersectionObserver+ 手动加 class 控制动画，避免引入整套库 - 限制同时动画元素数量：用
threshold: [0.1, 0.5]减少触发频次，或加节流（如每 300ms 最多处理 1 个） - 动画结束后强制清理：在
animationend回调里执行el.style.transform = ''和el.style.opacity = ''，防止样式残留干扰后续 GC
真正要盯住的不是动画本身，而是图层生命周期
旧安卓机没有现代浏览器的图层回收机制，transform 一旦启用，对应图层可能一直驻留内存，直到页面刷新。所以问题常不在“怎么动”，而在“动完没撤干净”。别只看 CSS 是否优雅，得去 DevTools 的 Rendering 面板勾选 “Layer borders”，真机连调，看动画结束后图层数量是否回落——不回落，就是泄漏源头。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
