低端安卓机型HTML滚动卡顿结构化成因与修复

先说几个核心判断：滚动卡顿问题，尤其是在低端安卓机型上，从来不是单一原因造成的。大多数开发者遇到的情况，归纳起来无非四个——硬件加速未触发、touchmove事件未设置passive、scroll回调中读取了layout、长列表未做虚拟滚动。这四个点但凡遗漏一个，帧率就难以稳定，页面滑动起来如同幻灯片播放。

滚动卡顿是因为 overflow: scroll 未触发硬件加速

低端安卓 WebView 有个特点：默认将 overflow: scroll 容器当作普通 DOM 处理，走的是 CPU 软件合成，帧率直接降至 20–30fps。这不是代码写错了，而是浏览器未被告知“这个区域需要 GPU 处理”。

解决方案其实很简单，但有一个关键点：必须同时添加两行 CSS 才有效。
- -webkit-overflow-scrolling: touch（iOS 必开，安卓 WebView 也支持）
- transform: translateZ(0)（强制创建独立合成层）

仅添加其中一条——尤其是只加 translateZ(0)——在多数中低端安卓机型上依然会出现卡顿。实际经验表明，这条组合是硬性需求，缺一不可。

touchmove 监听器使原生滚动降级为 JS 驱动

很多开发者不了解的是：只要给滚动容器绑定了 touchmove，哪怕回调中只写了一行 console.log()，iOS 和大量安卓 WebView 就会直接禁用原生滚动优化——每帧都调用 JS，导致卡顿。

修复方法不复杂，但常被忽略：
- 必须显式传入 { passive: true }：element.addEventListener('touchmove', handler, { passive: true })
- 绝对不要在回调中调用 preventDefault()，否则 passive: true 会直接失效
- 如果确实需要拦截滚动（如下拉刷新），改用 touchstart + touchmove 组合，只在必要时设置 passive: false

scroll 事件中读取 layout 信息直接导致掉帧

在 scroll 回调中调用 getBoundingClientRect()、offsetHeight 这类“获取”型 API，会触发强制同步布局（forced synchronous layout），浏览器必须立即重新计算整个页面流，单次耗时轻松超过 10ms，掉帧几乎是必然的。

可行的替代方案包括：
- 将 layout 读取移到 requestIdleCallback() 或节流后的回调末尾
- 使用 IntersectionObserver 替代手动计算元素位置
- 如需实时读取，先缓存一次值，后续滚动中复用，直到 resize 或 orientationchange 时再更新
- 改用 transform: translateY() 移动元素，它不触发 layout，只走合成层

长列表未做虚拟滚动，DOM 数量压垮渲染线程

超过 200 行的列表，即便所有 CSS 和事件都已优化到位，低端安卓机依然会卡顿——不是因为逻辑慢，而是内存和 DOM 树遍历成本已达到极限。

虚拟滚动不是“可选优化”，而是硬性需求：
- 只渲染视口内及上下各 1–2 屏的节点（通常 ≤ 20 条）
- 用一个 div 占位撑起总高度：style="height: calc(var(--item-height) * var(--total-count))"
- 滚动时仅更新 scrollTop 和当前渲染索引，不增删 DOM
- 不要用 will-change: scroll-position 试图“欺骗”浏览器优化，旧版 WebView 不支持，新版反而增加内存开销

真正导致低端安卓机卡顿的，往往不是某一行 JS 写得不好，而是多个看似独立的优化点都没有打通：合成层未建立、事件未设置 passive、layout 读取未节流、DOM 未裁剪。四个点遗漏任意一个，帧率就难以稳定。