小游戏在微信内卡顿与浏览器无关，因其运行于微信自研minigame runtime；瓶颈多在资源加载、内存峰值、渲染逻辑或平台配置，如ios高性能模式误用、加载策略不当、纹理未压缩及真机内存限制等。
为什么小游戏在微信内卡顿，不是“浏览器”问题
微信里运行的小游戏根本没走 WebView 或 Chrome 内核，它跑在微信自研的 MiniGame Runtime 上，底层是 JS 引擎 + WebGL 渲染管线 + 原生加速层。所谓“微信浏览器卡顿”，其实是误判——真正瓶颈通常在资源加载、内存峰值、渲染逻辑或平台模式配置上。
常见现象包括：首屏黑屏超 4 秒、旋转模型掉帧、iOS 真机突然闪退、安卓低端机滑动卡顿。这些基本和“浏览器兼容性”无关，而是小游戏运行时环境与代码配合出了问题。
game.json 开启 iOSHighPerformance: true 的实操陷阱
高性能模式不是一开就灵，反而容易在 iOS 低配机型上引发内存异常退出。关键限制很具体：iPhone 6s/7/8（2GB RAM） 的内存上限被硬性压到 1GB，iPhone X 及之后（3GB+） 是 1.4GB。超过就直接 kill 进程，不会报错，只表现为“闪退”或“卡死不动”。
- 必须先确认微信客户端 >=
8.0.18，且 iOS 系统 >=14；低于这俩版本，iOSHighPerformance配置会被静默忽略 - 开通高性能模式后，需彻底删除本地所有版本（开发版、体验版、线上版），否则微信会缓存旧启动状态，扫码仍进普通模式
- 调试时务必看左上角调试面板——只有显示“高性能模式”字样才算生效，仅改
game.json不等于已启用
Loader.load() 加载资源时的三类典型卡点
卡顿常发生在资源加载阶段，但错误归因成“网络慢”。其实更多是加载策略不当：比如把几十 MB 的贴图打包进首包、未设重试、同步阻塞等待未完成资源。
-
httpRetryCount不设默认为 0，一次失败就中断，建议设为2或3，尤其对 CDN 节点不稳定的情况 - 避免在
onLoad回调里直接调用engine.loader.getAsset()——如果资源还没 load 完，会抛出异常并中断流程 - 大资源（如场景 prefab、骨骼动画）务必用
preload: true选项提前下载，但不要raw: true，否则后续解析仍要耗时 - 路径写错会导致静默失败，例如写成
"assets/role.prefab"，而实际路径是"resource/role.prefab"（注意根目录是/assets/，但load()参数是相对于/assets/的）
真机卡顿但模拟器流畅？重点查内存与纹理
模拟器跑得顺，不代表真机能扛住。iOS 真机有严格的内存压缩和 GPU 显存限制，而安卓碎片化严重，低端机显存可能不足 512MB。这时候最常被忽略的是纹理未压缩、Canvas 尺寸过大、每帧 new 对象。
- 所有
.png贴图必须开启压缩纹理（ETC2/ASTC），未压缩的 2048×2048 RGBA 图在 iOS 上占约16MB显存，压缩后可压到2–4MB - 避免在
update()中创建临时数组或对象，尤其是new Vector3()、[]、{}，这些会快速推高 GC 压力，导致帧率毛刺 - Canvas 分辨率别盲目设成屏幕物理分辨率，用
designWidth/designHeight控制逻辑分辨率，再靠缩放适配，否则 GPU 填充率爆表
性能优化不是堆参数，而是让每一 KB 内存、每一帧 CPU 时间都落在刀刃上。最容易被跳过的，恰恰是清理缓存路径、删掉未引用资源、关掉调试日志——它们不炫技，但天天在拖慢你。
