YoYouFun 笔记

外观

Stage05｜Performance ​

Lesson070｜微信小游戏的包体、内存、渲染与平台限制 ​

Tags： #Creator2.x #Stage05 #MiniGame #Memory #PackageDifficulty： ⭐⭐⭐⭐☆

真实问题：Web 预览正常，微信真机为什么启动失败 ​

项目在 Creator 预览中资源齐全、内存充足，微信开发者工具也能运行；低端真机却出现首包超限、远程资源失败或内存退出。

小游戏不是“把 Web 页面换一个壳”。它有独立的：

text
代码包/分包规则
文件系统与缓存
网络域名和下载
内存与生命周期
Canvas/WebGL 能力
音频与后台规则
平台审核与版本变化

平台限制会更新，本课不把某个历史数值写成永远有效结论。

一、本课目标 ​

小游戏不是“把 Web 项目换个平台运行”。它有自己的包体、分包、网络、内存和渲染约束。

二、需要同时关注的指标 ​

text
首包大小
分包和远程资源
下载与解压时间
JS / Native / Texture 内存
页面和后台生命周期
GPU 能力和分辨率
网络请求限制

平台规则会随版本变化，具体限制必须以当前官方文档和目标基础库验证。

三、包体和资源拆分 ​

常见思路：

text
首包：启动和首屏必需
分包：用户路径中的功能模块
远程：大型或高频更新资源

拆分不是免费优化，远程资源还需要版本、失败、缓存和弱网策略。

四、内存限制更敏感 ​

小游戏设备差异大，内存峰值可能比桌面开发机更早触发问题。重点检查：

  • 大图和图集峰值。
  • 场景切换重叠。
  • WebView/JS 侧临时对象。
  • 长时间运行趋势。
  • 后台恢复后的资源状态。

五、渲染限制 ​

低端设备上常见风险：

  • 大面积半透明 UI。
  • 复杂 Shader。
  • 高分辨率 RenderTarget。
  • 过多 Mask 和粒子。
  • DrawCall 和纹理切换。

必须使用真实目标机测试，模拟器只能用于逻辑和流程验证。

六、网络和异步加载 ​

小游戏资源常依赖网络，需处理：

text
弱网、超时、重试、版本不一致、缓存失效、用户中途离开

加载回调必须和页面生命周期绑定，不能假设请求一定按发起顺序完成。

七、案例：首包过大 ​

如果所有活动图、音频和 Spine 资源都放入首包：

text
下载慢
→ 解压慢
→ 首屏等待长
→ 内存峰值高

可以按用户路径拆分，并对远程资源做版本和失败兜底。

八、常见误区 ​

误区一：压缩包体后一定更快 ​

解压、网络、缓存和设备 IO 也会影响实际体验。

误区二：小游戏只要降低 DrawCall ​

内存、首屏、网络和 Fill Rate 同样重要。

误区三：模拟器不卡就可以上线 ​

目标手机的 GPU、内存和网络条件可能完全不同。

误区四：远程资源不需要版本管理 ​

客户端缓存和资源更新不一致会产生大量线上问题。

九、练习与答案 ​

  1. 小游戏性能至少要同时看哪些指标？
  2. 为什么首包拆分可能改善首屏？
  3. 远程资源需要哪些兜底？
  4. 为什么必须用真实目标机验证？

答案：

  1. 包体、下载、解压、内存、纹理、GPU、网络和后台行为。
  2. 减少启动下载和解压，只保留首屏必需内容。
  3. 版本、缓存、失败、重试、超时和本地备用资源。
  4. 模拟器无法准确代表目标设备的内存、GPU 和网络。

平台约束必须建立“当前事实表” ​

每次发布记录：

text
微信基础库版本：
Creator 2.4.x 小版本：
目标最低系统：
主包/分包实际大小：
远程资源域名：
缓存目录与预算：
峰值内存设备：
首屏时间：
DrawCall/GPU 基线：

包体上限、分包能力和 API 支持以发布当日微信官方文档与开发者工具为准。

Creator 2.4.x 构建实验：从预览到真机 ​

只通过 Creator Build 面板和微信开发者工具完成构建验证，不直接修改 build/ 生成文件。需要修改时回到源资源或构建配置重新构建。

实验步骤 ​

  1. 建立最小 Boot Scene。
  2. 将非首屏模块组织为 Asset Bundle/分包策略。
  3. 用 Creator 构建微信小游戏目标。
  4. 在微信开发者工具查看代码包构成、网络请求和启动日志。
  5. 清缓存做冷启动。
  6. 使用真机调试低端设备。
  7. 记录主包/分包、首屏、内存峰值和远程失败。

平台探针 ​

ts
const { ccclass } = cc._decorator;

@ccclass
export default class MiniGameProbe extends cc.Component {
    start() {
        cc.log(
            '[mini-game]',
            'platform=', cc.sys.platform,
            'os=', cc.sys.os,
            'browser=', cc.sys.browserType
        );
    }
}

平台信息仅用于日志和选择经验证的能力，不应散落大量 if 分支。封装平台适配层。

包体优化不是删除文件 ​

正确方向：

  • 首包只放启动与核心入口；
  • 业务 Bundle 按用户路径拆分；
  • 远程资源有版本与回退；
  • 清理未引用资源要通过依赖审计；
  • 图片/音频按平台格式优化；
  • 第三方库按实际使用裁剪；
  • Source Map 和调试内容按发布策略处理。

不要手工删构建输出后发布，下一次构建不可重复。

小游戏内存为什么更敏感 ​

text
有限进程预算
+ JS 堆
+ 引擎原生/运行时
+ Texture/RenderTarget
+ 下载与解码缓冲
+ 音频
+ 平台自身

大型资源并发加载、缓存不设预算和超大 Canvas/纹理都可能触发系统终止。

真实项目故障：首包降了，首屏反而白屏 ​

团队把 Boot 背景和默认字体移到远程 Bundle。弱网下首包虽小，但没有本地可用的首屏资源，下载失败时只剩白屏。

修复：

  • 首包保留极小但完整的品牌/进度/失败 UI；
  • 远程配置和资源设超时与重试；
  • 弱网显示真实阶段，不假进度；
  • 关键默认字体/图片有本地降级；
  • Bundle 版本原子发布；
  • 冷缓存真机测试。

微信真机诊断顺序 ​

text
开发者工具日志
→ 真机日志
→ 基础库/系统版本
→ 包体与分包
→ 合法域名/HTTPS
→ 最终 URL/状态码
→ 缓存命中与磁盘
→ 内存峰值
→ WebGL/纹理/Shader 支持

不要用开发者工具成功替代真机结论。

版本边界与练习答案 ​

微信小游戏限制变化快，课程只提供方法。实际数值必须查询微信开放文档和当前开发者工具；Creator 2.4.x 适配也需查看对应版本发布说明。

  1. 为什么不在课程硬编码包体上限？ 平台规则会更新，历史数值会误导发布决策。
  2. 主包越小越好吗？ 不是。必须仍能显示可用首屏和失败回退。
  3. 开发者工具流畅能代表真机吗？ 不能，CPU/GPU、内存、网络、文件系统和基础库环境不同。
  4. 如何验收远程 Bundle？ 冷缓存、弱网、版本更新、失败回退、内存和旧版本兼容共同验证。

十、本课总结 ​

text
小游戏优化是平台适配问题，不是单一 DrawCall 问题。
包体、网络、内存、渲染和生命周期必须一起设计。

十一、下一课预告 ​

text
Lesson071｜性能实战：完整排查一次页面打开卡顿