HTML5转APP在低端机运行是否吃力，取决于壳、代码和减法策略；WebView内核老旧导致API不支持、渲染偏差；需禁用GPU加速、三阶降级资源、精准绑定触摸事件，并持续做排除法。
HTML5转APP在低端机上运行是否吃力，不取决于“是不是HTML5”，而取决于你打包时用了什么壳、写了什么代码、有没有针对低配设备做减法——很多所谓“卡顿”其实是开发者把桌面级逻辑直接塞进了2GB内存+Android 8.1的诺基亚G10或朵唯L520里。
WebView内核版本决定下限
低端安卓机普遍用系统自带WebView（非Chrome），且长期不更新。比如HTC One M8（Android 4.4）、诺基亚G21（Android 11但WebView锁定在Chromium 75）、朵唯V5（Android 9 + WebView 61）——这些内核不支持IntersectionObserver、ResizeObserver、font-display: swap，甚至对flex-wrap: wrap渲染都有偏差。
- 别在JS里写
new IntersectionObserver然后不做fallback，低端机直接报undefined is not a constructor - 用
getComputedStyle(el).display读样式后立刻改el.style.height？会触发强制同步布局，在HTC旧机上单次操作卡顿300ms+ - 字体加载必须加
font-display: swap，否则白屏时间超5秒（小米/诺基亚入门机常见）
禁用GPU加速反而是提速关键
在低端机上，will-change: transform和transform: translateZ(0)不是加速器，是内存泄漏开关。Android WebView 61–75对图层合成极其敏感，给10个列表项都加will-change，内存占用翻倍，滚动直接掉帧。
- 只对真正高频动画的元素启用，比如轮播图容器、弹窗遮罩层
- 动画结束必须手动清除：
el.style.willChange = 'auto' -
translateZ(0)在诺基亚G系列上会导致失焦，换用opacity: 0.999更稳妥
资源加载要做“三阶降级”
低端机网络慢、解码弱、内存小，一张2MB的WebP图或一个未压缩的lodash.js就能让首屏等待超8秒。不能只靠CDN或懒加载，得从请求源头分级兜底。
