html5游戏手机掉帧主因是requestanimationframe误用、图片未适配dpr、touchmove监听泄漏及webgl纹理上传阻塞；应单层raf驱动、预切@3x图、被动事件+及时解绑、初始化上传纹理并用texsubimage2d更新。
Canvas 渲染卡顿：requestAnimationFrame 用错了
很多 HTML5 游戏在手机上掉帧，不是因为逻辑复杂，而是 requestAnimationFrame 被当成了“定时器”在用——比如在动画循环里嵌套 setTimeout 或手动控制帧率，反而破坏了浏览器的渲染调度。
正确做法是只用一层 requestAnimationFrame 驱动主循环，且每次回调必须完成绘制+更新，不能中途打断或跳帧。iOS Safari 对连续未完成的帧特别敏感，连续两帧超 16ms 就可能触发降频。
- 别写
setTimeout(gameLoop, 1000 / 60)，它不和屏幕刷新同步，还容易累积延迟 - 别在
requestAnimationFrame回调里再调一次requestAnimationFrame之前做 heavy work（比如遍历几百个实体） - 用
performance.now()测每帧耗时，真机上超过 12ms 就该拆分逻辑（比如把碰撞检测分几帧做）
图片资源没适配视口：drawImage 拉伸成性能杀手
开发者常直接把 PC 端的 2048×2048 大图塞进 canvas，再用 ctx.drawImage(img, x, y, width, height) 缩放到手机屏大小——这会让 GPU 每帧都做实时缩放，尤其在低端 Android 上直接卡死。
Canvas 的 drawImage 在缩放非 2 的幂次尺寸、或源图/目标尺寸比例差异大时，会触发软件插值 fallback，CPU 占用飙升。
立即学习“前端免费学习笔记（深入）”；
- 所有图片资源按目标设备像素比预切：比如 iPhone 13 是 dpr=3，就提供 @3x 图并用 CSS 控制
canvas显示尺寸 - 避免在运行时用
drawImage缩放原图；先用offscreenCanvas（或服务端）生成合适尺寸的贴图缓存 - 检查
img.width和img.height是否远大于 canvas 实际渲染区域，是的话立刻压缩或裁剪
事件监听器泄漏：touchmove 阻塞主线程
移动端游戏依赖 touchstart/touchmove，但很多人没移除监听器，或在 touchmove 里频繁调用 preventDefault() ——这会让浏览器无法做原生滚动优化，同时强制 JS 线程持续处理，帧率直线下滑。
更隐蔽的问题是：同一个元素绑了多个 touchmove 监听器（比如模块化加载后重复绑定），一次触摸触发 N 次回调，逻辑翻倍执行。
- 用
{ passive: false }显式声明需要preventDefault()的 touch 事件，避免 Chrome 主动禁用 - 在
touchstart中动态绑定touchmove，并在touchend/touchcancel中立即removeEventListener - 用
event.touches[0].identifier做多点触控去重，别让同一根手指触发多次逻辑
WebGL 纹理上传慢：texImage2D 阻塞渲染线程
用 WebGL 写游戏时，如果在每帧都调用 gl.texImage2D 上传新图像（比如动态生成 UI 贴图），等于每帧都触发一次 CPU→GPU 内存拷贝，在 Mali GPU 的安卓机上单次就卡 8–15ms。
纹理上传不是异步的，它会阻塞当前渲染上下文，直到数据真正进显存。而手机 GPU 显存带宽只有桌面级的 1/5 左右。
- 所有静态纹理在初始化阶段一次性上传，用
gl.generateMipmap预生成多级渐远纹理 - 动态纹理（如小地图）改用
gl.texSubImage2D更新局部区域，而非整张重传 - 确保图片已解码完成再传：监听
img.decode()promise，别直接传img给texImage2D，否则会隐式同步解码
真机调试时最容易忽略的是「渲染线程和 JS 线程争抢」——比如一边 texImage2D 上传，一边 JS 还在算物理，两者在单核手机上彻底互锁。得靠 OffscreenCanvas 或 Web Worker 把图像预处理挪出去，但注意 Worker 里不能直接操作 DOM 或 canvas 上下文。
