先给出几个关键判断：在低端安卓设备上，滚动卡顿问题几乎从来不是由单一因素引起。大多数开发者遇到过的典型瓶颈，归根结底可以归纳为四个方面——硬件加速未能触发、touchmove 事件未设为 passive、scroll 回调中读取了布局信息、长列表未实施虚拟滚动。这四个要点中只要遗漏任意一个，帧率就难以维持稳定，页面滑动时会严重掉帧，甚至像幻灯片播放一样卡顿。
滚动卡顿的深层原因：overflow: scroll 未触发硬件加速
低端安卓设备的 WebView 存在一个已知特性：默认将 overflow: scroll 容器视为普通 DOM 元素，采用 CPU 软件合成方式渲染，这会导致帧率直接降至 20–30fps。这种问题并非代码逻辑错误，而是浏览器没有被明确告知“此区域需要 GPU 来管理合成”。
解决方案本身并不复杂，但有一个容易被忽略的细节：必须同时添加两行 CSS 才能生效。
- -webkit-overflow-scrolling: touch（iOS 必备，Android WebView 同样识别）
- transform: translateZ(0)（强制创建独立合成层）
如果只添加其中一条——尤其仅仅添加 translateZ(0)——在大多数中低端安卓机上滚动依然会卡顿。根据长期实践经验，这两条 CSS 组合是硬性需求，缺一不可。
touchmove 监听器导致原生滚动降级为 JS 驱动
许多开发者未曾意识到：一旦给滚动容器绑定了 touchmove 事件，即使回调函数中只写了一行 console.log()，iOS 以及大量 Android WebView 都会立即禁用原生滚动优化机制——每帧都需要调用 JS，从而引发明显的一卡一卡现象。
修复方式并不复杂，但常常被忽视：
- 必须显式传递 { passive: true } 参数：element.addEventListener('touchmove', handler, { passive: true })
- 绝对不要在回调中调用 preventDefault()，否则 passive: true 将直接失效
- 如果确实有拦截滚动的需求（例如实现下拉刷新），推荐改用 touchstart + touchmove 组合，仅在必要时将 passive 设为 false
scroll 事件中读取布局信息直接引发掉帧
在 scroll 事件的回调里调用 getBoundingClientRect()、offsetHeight 这类“获取型”API，会触发强制同步布局（forced synchronous layout）。浏览器必须立即重新计算整个页面的布局流，单次执行耗时轻松超过 10ms，掉帧几乎不可避免。
可行的替代方案包括：
- 将布局读取操作移到 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、布局读取未做节流、DOM 数量未进行裁剪。这四个要点中只要遗漏其中一个，帧率就无法保持稳定。
