Cocos Creator 小游戏上线前检查清单：性能、包体、适配、审核全覆盖

第一次提交审核那天，我盯着”审核驳回”的弹窗，脑子嗡的一下。包体超限——主包6.8MB，微信硬性规定4MB。改了三天，从纹理压缩到音频转码，再到引擎模块裁剪，硬是把包体压到3.2MB才过审。

那次经历让我意识到，上线前的检查其实是有迹可循的。不是靠运气，而是有具体的数值标准、明确的检测方法。后来我把踩过的坑整理成一份清单，每次提交前逐项勾选。到现在，这份清单已经迭代了十几次，涵盖性能、包体、适配、审核四大模块15项检查。

这篇文章就把我用过的这份清单分享出来。每项都给出具体数值标准，告诉你用什么工具检测、最常见的坑在哪里。读完你就能拿着这份清单，一项一项自查，大大提高一次过审的概率。

一、性能检查：别让卡顿毁掉体验

性能问题是玩家流失的主要原因之一。你可能觉得游戏在自己手机上跑得很流畅，但别忘了——你的测试设备大概率是新机型，而真实用户可能用的是三年前的老手机。iOS 高端机和低端机的性能差距能达到 3-4 倍，这不是开玩笑。

1. FPS 稳定性检查

检查标准：高端机（iPhone X 及以上）目标 60 FPS，低端机（iPhone 6s/7/8）目标 30 FPS。峰值不低于目标值的 80%，也就是说高端机最低 48 FPS，低端机最低 24 FPS。

检测方法：Cocos Creator 内置 FPS 显示，在 cc.macro 里开启：

// 开发阶段显示 FPS
cc.macro.SHOW_FPS = true;

或者用 Stats.js，更直观一些。微信开发者工具的”性能面板”也能看到实时 FPS 曲线。

量化指标：

• 高端机稳定 55-60 FPS
• 低端机稳定 28-32 FPS
• 峰值波动不超过 20%

常见问题：DrawCall 过多、复杂场景切换卡顿、大量粒子同时触发。我之前有个项目，Boss 死亡时爆了 200 个粒子，低端机直接掉到 15 FPS，后来改成 50 个粒子加缓动动画，效果反而更好。

自测小技巧：找一台 iPhone 7，真机跑 10 分钟。如果 FPS 线一直在 30 上下波动没问题，但如果频繁掉到 20 以下，就要排查了。

2. 内存峰值检查

检查标准：iOS 对内存有硬性限制。低端机（iPhone 6s/7/8）上限 1GB，高端机（iPhone X/XR/11）上限 1.4GB。峰值不要超过设备限制的 70%，也就是低端机控制在 700MB 以内，高端机控制在 1GB 以内。

检测方法：

• 微信开发者工具：打开”调试器-Memory”面板，能看到内存曲线
• Safari 远程调试：真机连接 Mac，Safari 开发者菜单选择对应设备

// 定期打印内存使用情况
const memoryInfo = cc.sys.getMemoryInfo();
console.log('当前内存: ' + memoryInfo.used + 'MB');

量化指标：

• 低端机峰值 ≤700MB
• 高端机峰值 ≤1000MB
• 闪退率控制在 2% 以内（某项目优化后从 15% 降到 2%）

常见问题：双份纹理问题（同一资源加载两份）、资源未及时释放、大图集没切分。Cocos 官方文档提到，图集最好控制在 1024x1024 以内，太大的图集在低端机上容易爆内存。

自测小技巧：在低端机上反复进出同一场景 20 次。如果内存曲线持续上升不回落，说明有资源泄漏。

3. DrawCall 数量检查

检查标准：DrawCall 直接影响渲染性能。同一帧里 DrawCall 越多，GPU 压力越大。首屏（进入游戏的第一个画面）不超过 100，游戏过程中不超过 200。

检测方法：Cocos Creator 的”构建发布”面板里有渲染统计选项，勾选后能在运行时看到 DrawCall 数量。

// 查看当前 DrawCall 数量
const stats = cc.game._renderStats;
console.log('DrawCall: ' + stats.drawCalls);

量化指标：

• 首屏 ≤100
• 游戏内 ≤200
• 峰值不超过 350（极端场景可以放宽）

常见问题：没合图、动态合图没开启、BMFont 用得太多。我有个项目优化前 DrawCall 高达 350，后来把零散小图打包成大图集，BMFont 换成 TTF，直接压到 120。

优化技巧：

• 静态合图：TexturePacker 打包，减少碎片图
• 动态合图：Cocos Creator 默认开启，但要确保纹理尺寸小于 2048
• BMFont：能用 TTF 就用 TTF，BMFont 每个 char 都是一个 DrawCall

4. 首屏加载时间检查

检查标准：首屏加载超过 3 秒，用户流失率上升 7%。这不是我瞎说，是行业数据。微信云测试平台的数据显示，3.5MB 包体的游戏，首屏耗时 4500-9000ms，这个区间流失率明显上升。

检测方法：

• 微信开发者工具：“详情-本地代码”能看到包体大小
• 微信云测试平台：真机网络环境模拟，获取真实首屏耗时

// 记录首屏加载时间
const startTime = Date.now();
cc.director.loadScene('game', () => {
  const loadTime = Date.now() - startTime;
  console.log('首屏耗时: ' + loadTime + 'ms');
});

量化指标：

• 首屏渲染 ≤3000ms（理想 ≤1500ms）
• 进度条显示比例 ≥80%（用户看到进度条会更有耐心）

常见问题：首场景放太多资源、初始场景没分包、resources 目录资源全加载。我当时首场景放了 3 个角色、2 个背景、一堆 UI，结果首屏加载 5 秒，改成一张 loading 图 + 分包加载，压到 2 秒。

优化技巧：

• 首场景只放一张背景图 + 进度条
• 初始场景勾选分包
• 非必要资源放到远程加载

二、包体检查：4MB 这道坎必须跨过去

微信小游戏的主包硬性限制是 4MB，整包（包括分包）不超过 16MB。这是红线，超了直接驳回，没有任何商量余地。我当时就是踩了这个坑——主包 6.8MB，被拒后改了三天才压到 3.2MB。

5. 主包大小检查

检查标准：主包 ≤3.8MB。为什么要留 200KB 余量？因为构建时可能有动态生成的文件，而且微信的计量方式有时候会有细微偏差。留点空间给自己喘口气。

检测方法：构建完成后，在微信开发者工具点击”详情-本地代码”，能看到精确的包体大小统计。

量化指标：

• 主包 ≤3.8MB（安全线）
• 主包 ≤4.0MB（红线，必须压）

常见问题：

• resources 目录放太多资源：这个目录里的文件会全部打包进主包
• 未裁剪引擎模块：Cocos 默认打包所有模块，但你可能只需要其中几个
• 依赖库太大：引入了 npm 包没检查大小

自测小技巧：构建前先检查 resources 目录，把非必要资源移到其他目录。然后在 Cocos 的”项目设置-模块设置”里，把用不到的模块勾选掉。

// 模块裁剪配置示例（project.json）
{
  "modules": [
    "base",
    "2d",
    "ui",
    "audio"
  ],
  // 不需要的模块不要勾选，比如：
  // "physics" - 不需要物理引擎
  // "tween" - 不需要缓动系统
}

6. 整包大小检查

检查标准：整包（主包 + 分包）不超过 16MB。分包可以远程加载，但下载速度会受网络影响，所以核心内容还是放在主包和首屏分包里。

检测方法：构建输出日志会显示每个分包的大小，加起来就是整包大小。

量化指标：

• 整包 ≤15MB（安全线）
• 整包 ≤16MB（红线）

分包策略建议：

• 核心包（主包 + 首屏分包）<10MB
• 功能包（次要玩法）20-50MB
• 场景包（远程加载）30-100MB

常见问题：分包划分不合理，首屏分包太大，用户下载等太久。我有个项目把所有角色模型都放在首屏分包，结果用户进游戏要等 8 秒下载。

7. 资源压缩率检查

检查标准：纹理、音频、字体三类资源是包体的三大主力。实测数据：纹理占 45%，音频占 25%，字体占 15%。这三类压缩到位，包体能减一半。

检测方法：对比原始文件大小和构建后大小。

量化指标：

• PNG → JPG（无透明通道的图）：减少 50-70%
• WAV → OGG：减少 65-70%
• 字体提取（fontmin）：减少 80-90%

工具推荐：

• TinyPNG：PNG 压缩，网页版，拖进去就行
• TexturePacker：打包图集 + 压缩，一步到位
• Audacity：音频转码，WAV 转 OGG 很方便
• fontmin：字体子集提取，只保留游戏用到的字符

常见问题：

• 背景图用 PNG：其实没透明通道，用 JPG 就行
• 音频用 WAV：体积大好几倍，换成 OGG
• 字体没提取：完整字体文件 10MB+，只提取用到的字可能只有 100KB

自测小技巧：用 TinyPNG 压缩一张 PNG，对比前后大小，你会惊讶的。一张 500KB 的背景图，压缩后可能只有 150KB。

8. 分包配置检查

检查标准：分包加载策略要合理，不影响启动体验。首场景必须勾选分包，非必要资源不要放在主包。

检测方法：查看分包加载顺序和首场景依赖关系。

量化指标：

• 首场景分包勾选：是
• 首场景加载时间：≤3000ms
• 非必要资源不在主包：检查 resources 目录

常见问题：

• 首场景引用主包外资源：导致要先下载分包才能进场景
• 分包没按业务逻辑划分：用户进了某个玩法才发现分包没下载完
• 分包加载时机不对：应该在 loading 画面就开始下载后续分包

// 分包加载示例
cc.assetManager.loadBundle('level-pack', (err, bundle) => {
  if (err) {
    console.error('分包加载失败', err);
    return;
  }
  bundle.loadScene('level-1', (err, scene) => {
    cc.director.runScene(scene);
  });
});

自测小技巧：在 4G 网络环境下测试分包加载速度。如果首屏分包下载超过 5 秒，就要考虑分包策略是否合理。

三、适配检查：别在某个机型上翻车

适配问题是最容易被忽视的。你可能在自己的测试机上跑得挺好，但发布后收到一堆用户投诉：UI 被挡住了、黑边太丑、横屏切换错位。机型适配是个系统性问题，不能只测一台设备。

9. 屏幕适配检查

检查标准：设计分辨率、适配策略、黑边处理。竖屏游戏推荐设计分辨率 720x1280（9:16）或 750x1334，横屏游戏反过来。

检测方法：至少覆盖 3 种屏幕比例的真机测试：

• 16:9（传统比例，大部分安卓机）
• 18:9（现代比例，小米华为新机型）
• 19.5:9（iPhone X 系列，刘海屏）

量化指标：

• 设计分辨率：720x1280 或 750x1334
• 适配策略：竖屏适配高度，横屏适配宽度
• 黑边：无黑边，或黑边均匀分布

关键代码：

// 竖屏适配高度
cc.view.setDesignResolutionSize(720, 1280, cc.ResolutionPolicy.FIXED_HEIGHT);

// 横屏适配宽度
cc.view.setDesignResolutionSize(1280, 720, cc.ResolutionPolicy.FIXED_WIDTH);

// 获取实际可视区域
const visibleSize = cc.view.getVisibleSize();
console.log('可视区域: ' + visibleSize.width + 'x' + visibleSize.height);

常见问题：

• 适配策略选错：竖屏选了适配宽度，导致上下黑边
• Widget 组件没用好：节点没有自动跟随屏幕边缘
• 设计分辨率太宽：部分机型显示不全

自测小技巧：用 Widget 组件把关键 UI 固定到屏幕边缘。比如右上角的金币数字，用 Widget 固定到右上角，不管什么屏幕比例都不会跑偏。

10. 刘海屏/水滴屏检查

检查标准：安全区域处理，关键 UI 不被遮挡。iPhone X 系列的刘海、安卓的水滴屏、挖孔屏，都会占用屏幕顶部区域。

检测方法：真机测试 iPhone X/XR/11 系列，安卓刘海屏机型（华为 Mate 系列、小米高端机）。

量化指标：

• 关键 UI 距顶部 ≥50px
• 关键 UI 距底部 ≥50px（虚拟 Home 键区域）
• 安全区检测：使用 SafeArea API

适配技巧：

// iOS SafeArea 获取
const safeArea = cc.sys.getSafeArea();
const topPadding = safeArea.top;
const bottomPadding = safeArea.bottom;

// 节点适配
this.topNode.y = -topPadding;  // 向下偏移
this.bottomNode.y = bottomPadding;  // 向上偏移

或者用 Widget 组件直接设置靠边距离，数值设成动态获取的安全区数值。

常见问题：

• 标题被刘海挡住：用户看不到游戏名称
• 底部按钮被虚拟 Home 键挡住：点击区域重叠
• 没测试安卓挖孔屏：不同品牌的挖孔位置不一样

自测小技巧：在微信开发者工具模拟器里选择”iPhone X”机型，看 UI 是否被刘海遮挡。然后找一台安卓刘海屏真机再测一遍。

11. 机型兼容性检查

检查标准：覆盖主流机型，低端机性能表现达标。云测试平台能帮你批量测试，不用自己买一堆手机。

检测方法：

• 微信云测试平台：免费，覆盖微信小游戏主流机型
• Testin 云测：付费，覆盖更全面

覆盖机型建议：

• iPhone 6s/7/8：低端基准机，测试性能下限
• iPhone X/XR/11：中高端机，测试刘海屏适配
• 华为/小米/OPPO/vivo 主流安卓机：测试机型兼容性

量化指标：

• 低端机 FPS ≥30
• 低端机内存 ≤设备限制 70%
• 闪退率 ≤2%
• 安装成功率 ≥99%

常见问题：

• 只测 iPhone：安卓机型差异大，低端安卓比 iPhone 6s 还弱
• 忽略老机型：2024 年还有用户用 iPhone 7
• 没测 WebGL 支持：部分机型 WebGL 版本低，某些特效不显示

自测小技巧：重点测试 3 类机型：你的开发设备（高端）、iPhone 7（iOS 低端）、某款 2019 年的安卓中端机。这三类能覆盖大部分情况。

12. 横竖屏切换检查

检查标准：横竖屏适配方案、切换流畅度。部分游戏支持横竖屏切换（比如某些益智游戏），切换时 UI 要自动重排。

检测方法：真机旋转测试、强制横屏/竖屏场景测试。

量化指标：

• 切换耗时 ≤500ms
• UI 重排无错位
• 切换后场景正常渲染

常见问题：

• 切换时节点位置错乱：Widget 没更新
• 切换后黑屏：场景重新加载失败
• 切换卡顿：场景太大重新渲染太慢

// 监听屏幕旋转
cc.view.on('resize', () => {
  const isLandscape = cc.view.getFrameSize().width > cc.view.getFrameSize().height;
  this.updateUILayout(isLandscape);
});

// UI 重排逻辑
updateUILayout(isLandscape: boolean) {
  if (isLandscape) {
    // 横屏布局
    this.scoreLabel.x = -200;
    this.scoreLabel.y = 300;
  } else {
    // 竖屏布局
    this.scoreLabel.x = 0;
    this.scoreLabel.y = 600;
  }
}

自测小技巧：如果你的游戏只支持竖屏或横屏，在项目设置里强制锁定方向，避免用户旋转手机导致画面错乱。

四、审核检查：资质、隐私、内容三道关

审核环节是最让开发者头疼的。技术问题你能自己测，但审核规范你很难提前知道。微信的审核规范写得很详细，但实际执行时还有很多细节需要注意。2026 年开始，微信引入了 AI 辅助审核，更新版本 2-4 小时就能完成，但首版审核还是要 1-2 个工作日。

13. 资质完备性检查

检查标准：软著、ICP 备案、版号（内购必需）。这三项是硬性要求，缺一项直接驳回。

检测方法：对照官方资质清单逐一检查，确保名称、主体完全一致。

量化指标：

• 软著：主体、名称与账号完全一致（一字不差）
• ICP 备案：审核通过（7-20 工作日）
• 版号：内购游戏必备，纯广告变现可免

常见问题：

• 软著名称多了个字：比如软著叫”比邻消消乐”，游戏名叫”比邻消消乐小游戏”，直接驳回
• ICP 备案没等审核通过就提交：审核周期 7-20 天，提前提交会被拒
• 版号主体不一致：版号是公司 A 的，游戏账号是公司 B 的，不通过

自测小技巧：把软著证书、ICP 备案截图、版号（如果有）放在一起，逐字核对名称和主体。多一字少一字都不行，这点真的要仔细。

14. 隐私政策与未成年人保护检查

检查标准：隐私协议入口、实名认证、防沉迷系统。这三项是未成年人保护的强制要求，2026 年审核会重点检查。

检测方法：模拟未成年用户登录流程，检查防沉迷逻辑是否生效。

量化指标：

• 隐私协议：首页显著位置有入口（弹窗或按钮）
• 防沉迷：未成年人每日 ≤1 小时，22:00-8:00 禁玩
• 适龄提示：首页展示健康游戏忠告

常见问题：

• 隐私协议未弹窗授权：用户进游戏直接开玩，没弹隐私协议
• 防沉迷逻辑缺失：没有实名认证入口，或者认证后没执行防沉迷
• 健康游戏忠告不显示：审核时会被要求补充

自测小技巧：用一个未成年身份证号（18 岁以下）测试登录流程。看看是否触发防沉迷限制，22:00 后登录是否提示禁玩。

15. 内容合规检查

检查标准：名称规范、广告合规、内容红线。名称要和资质一致，广告不能遮挡核心功能，内容不能触碰红线。

检测方法：对照审核规范自查，逐项检查名称、广告、内容元素。

量化指标：

• 名称：不含英文/品牌词、与资质一致
• 广告占比：≤50%、不遮挡核心功能
• 内容：无暴力、色情、赌博、政治敏感元素

常见问题：

• 名称含”软件”字样：比如”XX软件小游戏”，会被驳回
• 广告遮挡关键按钮：用户想点击”开始游戏”，结果点到广告
• 诱导分享：“分享给好友解锁关卡”，审核直接驳回
• 名称含英文：比如”CocosGame”，要改成中文

常见驳回原因 TOP 5：

1. 包体超限（主包 >4MB）
2. 名称与软著不一致
3. 隐私协议未弹窗授权
4. 诱导分享/关注
5. 广告遮挡核心功能

自测小技巧：对照这份 TOP 5 清单逐项自查。这 5 个原因占了驳回案例的 80%，避开这些基本能一次过审。

快速自查表：上线前 15 项勾选清单

下面这份清单可以直接打印出来，提交审核前逐项勾选：

模块	检查项	标准	是否达标
性能	FPS 稳定性	高端≥55，低端≥28	□
性能	内存峰值	低端≤700MB，高端≤1000MB	□
性能	DrawCall 数量	首屏≤100，游戏≤200	□
性能	首屏加载时间	≤3000ms	□
包体	主包大小	≤3.8MB	□
包体	整包大小	≤15MB	□
包体	资源压缩率	PNG 减少 50%+，音频 65%+	□
包体	分包配置	首场景分包勾选	□
适配	屏幕适配	无黑边、无遮挡	□
适配	刘海屏处理	UI 距边缘≥50px	□
适配	机型兼容	低端机 FPS≥28	□
适配	横竖屏切换	≤500ms 无错位（如支持）	□
审核	资质完备	软著+ICP 备案+版号（内购）	□
审核	隐私与防沉迷	协议入口+防沉迷逻辑	□
审核	内容合规	名称/广告/内容规范	□

每项达标后打勾，15 项全勾完再提交审核。不要心存侥幸，任何一项不达标都可能被驳回，浪费时间重新整改。

总结

上线前的检查不是可有可无的流程，而是直接影响审核通过率的关键环节。性能问题会导致用户流失，包体超限直接驳回，适配问题会收到用户投诉，审核不合规浪费一周时间整改。

这份清单的核心价值在于：每项都有具体数值标准，不用猜；每项都有检测方法，不用蒙；每项都有常见问题，帮你避开别人踩过的坑。

建议你把这份清单打印出来，贴在显示器旁边。每次提交审核前，一项一项勾选。可能觉得麻烦，但比起被驳回改三天，这点时间投入绝对值得。

最后说一句：第一次上线紧张是正常的，但有了这份清单，你就能系统排查、心中有数。祝你的小游戏一次过审，顺利上线。