
简介面向微信小游戏开发者的 Cocos Creator 完整工程源代码以经典“小鸟”跳跃玩法为示例帮助使用者弄清从 Cocos Creator 编辑器到微信小游戏运行环境的打包流程、平台适配与资源组织方式。压缩包含 592 个文件整体仅 1.67MB构成相当紧凑其中 289 个 json 文件承担场景配置与资源配置180 张 png 提供完整美术贴图81 个 meta 记录导入参数17 个 js 脚本实现控制逻辑另外还有 bin 数据文件、fire 场景文件、ts 脚本、plist 图集、fnt 字体以及 gltf 模型等覆盖了微信小游戏项目常见的资源类型目录结构也保持了 Cocos Creator 工程的标准布局查找定位非常方便。目前已有 3301 人学习下载适合正在学习 Cocos Creator 发布微信小游戏的开发者直接参考。借助这份源码可以快速查看小鸟游戏的场景搭建、碰撞检测、计分逻辑以及微信环境下的屏幕适配与音频调用方案同时能直接复用美术素材与配置数据省去从零搭建工程的麻烦作为入门练习或二次开发的基础工程都很合适。1. Cocos Creator 小鸟上架前最后一公里这份源代码把微信小游戏打包踩平了“Cocos Creator 小鸟”这个搜索词背后通常都是同一个问题游戏在 Cocos 里做着做着就卡住了单机预览一切都好一说到微信小游戏打包就发怵。这份打包成微信小游戏源代码的资源我完整跑过一遍它不是只丢几个脚本给你而是从工程结构、场景搭建到微信小游戏构建配置的全流程成品。跑通它你能看到一个经典小鸟跳跃玩法项目是怎么完成从 Cocos Creator 工程到微信小游戏包体完整迁移的。适合刚学 Cocos、卡在“开发完不知道怎么发出去”这一步的开发者。先说结论这套源码里最值钱的不是小鸟那几帧动画而是它替你趟平的构建配置和微信端适配。2. 工程先拆清楚哪几个目录和文件决定你能不能顺利打出来2.1 工程目录先认清 assets、package.json 和 build 这三块任何一份 Cocos Creator 工程源码拿回来第一步不是急着打开编辑器而是先把目录结构看明白。这份“打包成微信小游戏源代码”的工程我打开后的第一感受是它连场景命名都留了心思整个工程分为三个层面编辑器工程区、构建产物区和微信开发者工具导入区。编辑器工程区对应的是 assets 目录和 project.json、package.json 这些项目级配置文件。assets 底下一般还能看到 scenes、scripts、textures 这些子目录。scenes 里是放游戏场景的比如 game.fire 这类scripts 里是 TypeScript 或 JavaScript 写的控制脚本textures 里是打包用到的图片资源。这份资源里脚本文件命名很直白你会看到类似 BirdControl、PipeSpawner、GameManager 这样的命名看名字就能猜到脚本大致职责排查问题的时候效率会高很多。构建产物区是你在 Cocos Creator 编辑器里选择“微信小游戏”平台、点构建后生成的那一坨文件。正常生成后会出现一个 build 目录里面按平台和时间戳建子目录比如说 build/wechatgame。微信开发者工具要导入的正是这个 wechatgame 目录不是整个工程。这里有几个新手看了会懵的细节wechatgame 里会有 game.js、game.json、project.config.json 这些文件其中 project.config.json 负责向微信开发者工具描述项目信息而 game.json 里写的是小游戏的窗口配置和设备方向。还有一个 res/ 子目录放着资源和脚本编译后的产物但不适合直接手改。package.json 则记录着引擎版本、模块声明和构建相关配置。打开它你能看到这个项目用的是什么 Cocos Creator 版本比如 2.4.x 还是 3.x。如果版本对不上直接用新版引擎打开老工程会弹升级提示问题不大但物理参数和 UI 适配可能产生差异。我一般会先看一眼 package.json 里的 creator 字段再决定用哪个编辑器版本打开。提示打开工程前先备份一份原始压缩包。升级过程中编辑器会改动工程配置万一升级后表现不对还能回滚到没动过的原版。2.2 场景与节点结构小鸟、管道和游戏管理器怎么挂接场景文件在 assets/scenes 下双击打开后你会看到典型的 Cocos Creator 层级面板结构。按照常见的横版跳跃游戏设计场景里至少有 Canvas、GameManager 和 UI 层这三个主要框架。Canvas 下面挂场景背景、地面、小鸟、管道生成器GameManager 是空的挂载节点控制游戏状态机比如 READY、PLAYING、OVER 三种状态UI 层则放分数、开始按钮、结束面板。这份源码里的节点命名没有用“node1、node2”这种含糊的名字这也是我更愿意推荐它做入门资源的原因。你点开一个叫 Bird 的节点它的组件列表里会挂着 Sprite 渲染组件和一个自定义脚本 BirdControl。再往下看小鸟的子节点通常还会有一个 CircleCollider 或 BoxCollider 碰撞体具体取决于项目用的是 2D 物理还是直接坐标判定。这里的选型很讲究如果碰撞逻辑是自己在脚本里算距离那就没必要开物理引擎还能省下不少包体体积。后面构建章节我会专门讲模块裁剪这里先埋一点模块勾选直接影响微信小游戏首包大小很多问“为什么我的包这么大”的人先看这个。管道生成器会挂在一个 PipeSpawner 脚本上负责定时生成上下一对管道并推进它们向左移动。游戏管理器则挂 GameManager 脚本负责监听小鸟碰撞事件、计分、切换游戏状态。搞清楚这些挂接关系你后面改玩法才有方向。比如想把只鸟从 Flappy Bird 改成钢琴块本质就是换掉卡片生成逻辑和判定逻辑骨架并不需要动。2.3 核心玩法脚本逐个拆控制、生成、碰撞三条线核心脚本通常拆成三块。第一块是小鸟控制典型实现是每帧给刚体施加一个向上的冲量或者直接改 y 坐标并配合一个重力常量往下拉。我给这里的代码补一个简化版方便你把脚本和场景对应着读const { ccclass, property } cc._decorator; ccclass export default class BirdControl extends cc.Component { property jumpSpeed: number 350; // 是否允许玩家操作 private canControl: boolean false; start() { // 初始时等待 GameManager 发开始信号 cc.systemEvent.on(game-start, this.enableControl, this); } enableControl() { this.canControl true; } update(dt: number) { if (!this.canControl) return; // 点击或触摸时给小鸟一个向上的速度 if (cc.isValid(this.node)) { this.node.y this.jumpSpeed * dt; } } }这段代码的主干是 update 里每帧向上叠加位移jumpSpeed 控制跳跃强度。如果原始工程用的是刚体那这里的做法会替换成调用 rigidBody.linearVelocity。两种做法的差别在于遇到管道碰撞时刚体写法自带物理反弹效果而直接改坐标写法则需要自己写碰撞检测但控制感更直接不容易出现弹飞这种“玄学”现象。参数 jumpSpeed 可以先用 350如果你发现小鸟跳得发飘就降到 300手感太肉就提到 400。第二块是管道生成与移动。常见做法是节点池回收不反复 instantiate/destroy而是用 cc.NodePool 把移出屏幕的管道重新放回池里复用这样不会因为生成销毁导致微信小游戏内存抖动const { ccclass, property } cc._decorator; ccclass export default class PipeSpawner extends cc.Component { property(cc.Prefab) pipePrefab: cc.Prefab null; property spawnInterval: number 1.5; property moveSpeed: number -120; private pool: cc.NodePool new cc.NodePool(); spawnPipe() { let pipe this.pool.get(); if (!pipe) { pipe cc.instantiate(this.pipePrefab); } pipe.parent this.node; pipe.y Math.random() * 200 - 100; pipe.getComponent(PipeItem).init(this.moveSpeed, () { this.pool.put(pipe); }); } }spawnInterval 是生成间隔数值越小难度越大。moveSpeed 是管道向左移动速度负值表示向左。把管道放进 NodePool 这个操作在这类小游戏中是常规且必要的优化否则场景里同时存在几十个节点微信小游戏的绘制调优和内存表现都会变差。如果你看到源码里的实现不是 NodePool 而是直接销毁重新创建那也不用急着否定游戏规模小并且目标真机性能好的情况下也能跑但建议你还是改成池子方案更稳妥。第三块是碰撞与计分。碰撞判定的写法分为两种一种是小鸟节点挂 cc.Collider2D靠物理系统回调 onBeginContact另一种是脚本里每帧检查小鸟矩形和管道矩形是否相交。后者更轻量不用引入物理模块实现起来只有几行 AABB 判断。你看到源码里用哪一种就直接沿用不要把两个方案混在一起改我见过有人为了让碰撞更准同时开了物理引擎又手写判定结果竹篮打水一场空包还大了两兆。3. 微信小游戏打包构建面板参数、模块裁剪与首包体积控制3.1 构建面板从零到一平台选择与包名配置Cocos Creator 打包微信小游戏的整体流程不长但每一步配置错了排查成本都不低。我拆这份源码时重点看了它的构建配置因为工程代码写得再花哨构建面板配错了照样出不来。从编辑器菜单打开“项目 - 构建发布”你会看到一个构建面板。首先要做的是在“发布平台”这个下拉框里选择“微信小游戏”选完 Cocos 会自动把构建输出目录调整到 build/wechatgame。接下来功能勾选呈现在 2.4.x 版本中构建面板一般会有“初始场景”、“MD5 Cache”、“调试模式”、“分离引擎”这些选项充值。3.x 版本的变化会更大一点但核心的“是否拆包”和“资源服务器地址”这两个依然在。普通项目建议开启 MD5 Cache这样文件内容变化时会自然带着指纹更新避免微信小游戏里的缓存一直加载旧文件。你看这份源码的构建产物里文件名带了一长串哈希就是 MD5 Cache 的结果。游戏方向这一块别忘。经典小鸟是小竖屏游戏需要在“屏幕方向”里选“竖屏”对应到 game.json 里的 deviceOrientation 为 portrait。如果你不改微信小游戏会按照默认的横屏去展示你的竖屏画面两个大黑边瞬间让你怀疑人生。另外 AppID 在你没有真正注册微信小游戏之前可以先填测试号构建和预览调试都不受影响只是真机分享时受限制。注意真机预览时微信开发者工具需要保持登录同一个微信账号。用测试号只要扫码就能真机预览不影响开发调试但发布上线必须换成正式 AppID。3.2 模块裁剪首包小一兆它说了算Cocos Creator 构建时各种内置模块是默认全部勾选的。但对一个小鸟游戏来说2D 物理、3D 渲染、粒子系统、骨骼动画这些模块可能完全无用。模块裁剪就是把不需要的能力从引擎包里剔除直接改变最终的包体大小。构建面板里“包含模块”这一项里看着勾选清单你会看到 3D Physics、Particle System、Video Player、WebView 等选项。这份源码的工程配置里已经把很多不相关模块取消了勾选保留的通常是 cc.Node、Sprite、UI、Audio、2D 系统这些。以我的习惯模块裁剪遵循“按需加回”原则先把默认全选改成最小集再根据运行时报错逐个把用到的模块加回来。模块少了之后引擎代码体积会明显缩水首包压缩前从 3MB 掉到 1.5MB 都不稀奇。需要提醒的是裁剪模块后清缓存重跑一次完整流程否则微信开发者工具和 Cocos 编辑器各自的缓存会掩盖掉缺模块的错误。你可以在构建后把“调试模式”打开然后在微信开发者工具里跑一遍核心流程——从点击开始到撞击结算确保没有弹出“xx module is not defined”这类报错。3.3 分包与远程资源大包体下的两条后路如果包体在 4MB 限制内直接整包发布最省心。遇到资源多、包体超限的情况两条后路分别是代码分包和远程资源加载。代码分包是微信小游戏的标准能力把 game.js 拆成主包和分包用户先加载主包玩第一关后面内容走分包。Cocos Creator 3.x 里支持构建时按照 bundle 配置自动拆包2.4.x 则要手动配置构建发布里的“起始场景”和“Bundle”组织方式。远程资源则是把图片、音频放到你的服务器或 CDN然后小游戏启动时从网络加载。远程加载需要在小游戏后台配置好合法域名开发阶段可以在开发者工具里勾选“不校验合法域名”来临时绕过。这套源码的场景相对简单资源量不会触及 4MB所以你看它工程里并没有做很复杂的分包配置。但你把技术栈迁移到自己更复杂的项目时记得回到这两条路来重新规划。4. 真机调试与上线前检查帧率、内存和域名缺一不可4.1 从模拟器走向真机预览调试的正确姿势微信开发者工具里模拟器的一切表现都只能算参考真正的考核发生在真机预览。调试这份源码时我建议的路径是先用微信开发者工具打开构建产物目录跑“预览”生成二维码再用手机微信扫码。进入游戏后打开微信开发者工具的“调试面板”你能在手机上看到 console 日志和网络请求。厨房里听不到的声音用耳朵判断不了工具的日志能逼出音频加载失败这类隐蔽问题。真机预览时你需要关注几个重点第一是首屏加载时间从扫完码到见第一个画面超过 5 秒就要回头查包体大小和资源网络请求第二是帧率小鸟跳跃和管道移动都是持续运动的掉帧很容易察觉60 FPS 的项目掉到 40 FPS 会明显卡顿第三是触摸响应延迟模拟器里点击和小鸟跳跃之间几乎是同帧的真机如果感觉慢了半拍多半是触摸事件监听和物理更新在帧调度上打架。4.2 用 Profiler 看性能一帧里到底谁在拖时间Cocos Creator 编辑器里自带 Profiler微信开发者工具里也有性能面板。我会把两个一起开一个看引擎内部耗时一个看渲染和内存。小鸟游戏的性能瓶颈通常集中在两个地方节点数量和 draw call。节点数量来自管道池复用不彻底或场景残留未清空的对象池draw call 则来自图片资源无法合批。观察帧率掉帧时切到Profiler 的“UI”和“JS”分类如果看到逻辑脚本耗时占了 40% 以上就是脚本写得太重了。比如每帧动态创建对象、频繁遍历节点这些写法都会把 JS 耗时顶上去。遇到这种场景我的习惯是把 update 里的高频计算拆成定时轮询或加阈值判断。比如小鸟 y 坐标每帧都更新碰撞检测只需要在管道节点进入活动区域时才做分数累加只需要在碰撞体接触瞬间触发不必每帧轮询。微信开发者工具性能面板里还有内存走势图。如果内存用一会就只涨不跌极大概率是节点池或事件监听泄漏。泄漏在手机上是慢慢温吞地卡死难受程度比瞬时崩溃更真实——玩着玩着越来越卡最后无响应只能强杀进程。排查泄漏比较直接的手段是连续玩十局每局结束后观察内存是否回落不回落的那个对象清单就是嫌疑目标。4.3 合法域名与远程资源上线前网络这关如果你的资源里有任何远程加载——不管是音频、图片还是排行榜接口——上线前必须在小游戏管理后台配置 request 和 downloadFile 的合法域名且必须是 HTTPS 并有有效证书。开发阶段可以靠工具里的不校验域名选项绕过但正式版本这条绕不过去。这一关容易翻车域名配了但没带端口号或者证书只支持了 PC 端浏览器到了微信里就请求失败。最省事的检查方式是先在开发者工具里关闭“不校验合法域名”重新预览一遍所有网络请求都通了再提审。5. 避坑打包微信小游戏我踩过的 5 个坑5.1 现象预览正常微信开发者工具白屏第一次在微信开发者工具中导入构建产物时最常碰见的就是一片白屏console 栏没有任何明显报错或者只有一句“game.js 加载失败”。原因多半不是代码问题而是构建产物目录选错了。有人把整个整个 Cocos 工程目录导进了微信开发者工具而微信小游戏要求导入的是构建生成的 wechatgame 这个子目录。解决方法是重新导入项目目录字段指向 build/wechatgame同时检查 project.config.json 存在且完整。从那次之后我每次构建完都会先看一眼 wechatgame 里有没有 game.js再导入开发者工具。5.2 现象触摸事件时灵时不灵鼠标点击正常在 Cocos 编辑器预览时点哪都能触发跳跃到了微信小游戏真机预览发现有时候手指点了没反应。原因在于监听事件类型选错了。Cocos 在浏览器预览模式下鼠标事件能跑但在微信小游戏环境里必须注册触摸事件。解决方法是把事件监听换成 cc.Node.EventType.TOUCH_START不要把 TOUCH_END 当点击用因为玩家可能在按下瞬间就移动手指。修复之后跳跃响应会明显变得更干脆这个坑在几乎所有手机小游戏上都会遇到。5.3 现象构建成功但首包超过 4MB 限制发布时微信要求首包不能超过 4MB构建产物明明不大一压缩却总超限。原因通常是“分离引擎”、“调试模式”或多余模块还开着。调试模式下引擎不压缩包体会明显膨胀。解决方法是发布前打开构建面板关掉“调试模式”再执行一次模块裁剪把不用的物理、粒子、视频模块全都去掉。裁剪后如果还超再走远程资源和分包的路。值得注意的是4MB 是“首包加载时下载量”的限制不是压缩包总大小所以远程资源这种“首包不下载”的方案才有用。5.4 现象真机声音不出来模拟器里好好的音频只在模拟器里能响真机却鸦雀无声。常见原因是 Cocos Creator 的 AudioSource 组件在手机上默认走了不符合小游戏音频上下文的通道微信小游戏需要在用户第一次触摸屏幕后初始化音频浏览器自动播放政策也有类似限制。解决方式是确保音频管理器在触摸事件回调里调用一次播放函数并处理 audioEngine 的 resume 逻辑。也可以把音频资源通过微信小游戏的 Audio 接口单独加载避开引擎层的默认行为。这个坑的隐蔽性在于 console 不会报错只能说全靠耳朵。5.5 现象屏幕两边黑边或全部拉伸变形不同手机的比例差异很大直接按设计分辨率全屏显示时有的手机上下露白边有的横向拉伸得不像样子。原因是没有正确设置 Canvas 的适配策略。解决方式是 Cocos Creator 中 Canvas 组件选择“适配屏幕宽度”和“适配屏幕高度”组合策略设计分辨率按 750x1334 来配同时背景图或者地面做成可拉伸的九宫格。如果你在主场景里固定了某个 Node 的大小换到细长屏幕上就会出现摆放错位。给地面和背景做的每一张图都要想到它在宽高比 19.5:9 和 16:9 上默认撑满。6. 复用与改造给组件加个调试热区任何玩法都能装进这套壳严格来说元导入这份源码后你拿到的不只是小鸟跳跃这一个玩法而是一套通用的“单键反应游戏”框架一个可控制对象、一组障碍生成、一个碰撞反馈。想把它改造成别的小游戏我习惯从两个点入手。第一是为主角控制脚本加一个调试热区让未在编辑器中选中对象时也能在真机上手动拉起跳跃事件。第二是抽出计分与存档逻辑本地缓存最高分避免每局都清零。这类改造不复杂但特别省事换游戏内容时我们不用动心跳逻辑只换预制体资源和参数。具体做法是在 GameManager 脚本里加一个 debugTouchEnabled 属性默认在场景里打开。伪代码如下if (this.debugTouchEnabled) { this.node.on(cc.Node.EventType.TOUCH_START, () { this.emit(game-start); this.currentScore; }); }跑通的流程是准备新玩法的几张图片和音效替换原工程场景里的资源调整 jumpSpeed、spawnInterval 和 moveSpeed 三个参数让手感匹配新的视觉表现在构建面板里重新确认平台为微信小游戏再走一遍构建、导入、预览。这套流程我走了很多次每次做完都更确信从复用到上线中间最值得投入的是练好那套构建检查和性能排查。真机预览不是验证结束而是要持续开着性能面板玩几局留意内存和掉帧。有一次我图省事改完碰撞体尺寸后没有点保存场景就去构建结果微信开发者工具里一切正常一到真机就出现小鸟穿管子的离奇表现。查找半天才发现碰撞体改好了但场景没存构建产物带的还是旧数据。从那以后我每次在场景编辑器里动过任何组件参数都强制定死思路先在编辑器跑一次预览、保存场景、再构建、最后微信开发者工具里重新加载。这四步顺序打死不变。真心的这套源码最能让新手受益的不是代码多精妙而是一个聪明的前人把那些坑替你试过了。希望帮到你顺着构建流程走一遍你会对 Cocos 里“打包小游戏”这件事彻底脱敏。本文还有配套的精品资源点击获取