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或懒加载，得从请求源头分级兜底。
立即学习“前端免费学习笔记（深入）”；
- 图片：用
srcset提供@1x/@2x，但最低档必须 fallback 到 base64 占位（data:image/svg+xml;base64,...） - JS：主包拆成
vendor.js（含Vue/React）+app.js（业务逻辑），后者用type="module"+nomodule双入口，老WebView自动走nomodule降级版 - 字体：禁用WOFF2，只提供WOFF + TTF；中文用子集（如只含「支付」「确认」「返回」等20字）
触摸交互必须绕开click延迟，但别全绑touchstart
低端机WebView的click延迟确实高达300ms（HTC M8实测342ms），但盲目把所有click换成touchstart会引发新问题：误触、长按呼出菜单、与原生下拉刷新冲突。
- 仅对按钮、图标、切换开关等明确“瞬时响应”意图的元素绑定
touchstart - 表单控件（
,）必须保留click，否则朵唯/诺基亚部分ROM会拦截事件导致无法聚焦 - 用
{ passive: false }监听touchmove时，务必加e.preventDefault()，否则诺基亚G21会触发页面意外回弹
最常被忽略的一点：低端机没有“空闲内存”概念。你以为的“轻量H5”，可能因为多了一个requestIdleCallback polyfill就让朵唯L520直接OOM闪退——适配不是加功能，是持续做排除法。
