企业官网建设流程全解析

从注册工作室到第一款微信小游戏过审上架，我大概花了三个月。这三个月里踩过的坑，比我之前做两年Web前端开发踩的还多。今天这篇东西，不吹不黑，就是Vibe Gaming一人工作室做微信小游戏的完整复盘，包括Unity怎么打包到微信小游戏、视频播放方案怎么选、包体怎么压、审核要哪些资质、以及最现实的钱的问题。如果你也是一个人，或者刚组了个两三人小团队，想用Unity做微信小游戏并顺利上架，这篇实战记录应该能让你少走不少弯路。

先说下背景：我自己是前Web开发，会一点Unity但远谈不上精通，美术属于"能画但丑"的水平，第一款产品选的是3D休闲解压类玩法。我会尽量把每个环节的取舍逻辑都讲清楚，而不是只甩结论。毕竟一人工作室最贵的不是软件订阅，是试错时间。

1. 一人工作室：先把路子选对，再谈开发

1.1 为什么是微信小游戏，而不是App

很多人问我，一个人做游戏，为什么不直接上App Store？说实话，我一开始也纠结过。但算了一笔账就明白了：App要上架iOS和安卓两个渠道，iOS要开发者账号（99美元/年），安卓要应付各种应用商店的审核、加固、签名，而且用户下载成本极高。你做了一款休闲小游戏，想让用户专门去App Store搜到你、下载、安装、打开，这个链路对一个没有推广预算的个人开发者来说，几乎走不通。

微信小游戏最核心的价值就是“即点即玩”。用户从聊天窗口点开你分享的卡片，到进游戏，可能就两三秒。这种轻量触达对休闲品类是降维打击。对一人工作室来说，你不需要维护多端，微信开发者工具一套搞定开发、预览、调试、真机测试，后端如果不需要也能完全省掉。再加上微信自带社交分享和裂变场景，小游戏天然适合“一个人做出一个能被玩到的东西”。

我的结论是：如果你做的是玩法较轻、单局时间短、强社交传播属性的小游戏，微信小游戏是目前独立开发者最友好的平台。Unity 3D、Cocos 2D、平面合成类、答题类、解压类，都很适配。这也是我把第一款产品放在微信小游戏上而不是App的最重要原因：活下来最重要，而在微信生态里，一个人活下来的概率比在应用商店大得多。

1.2 技术栈取舍：Unity、Cocos还是原生JS

确定平台之后，第二个关键决策就是用哪套技术栈。我当时认真比较过三条路线：

• Unity + 微信小游戏适配插件：3D能力强、资源多、C#开发效率高、Asset Store里一堆现成素材和插件。缺点是打包到微信小游戏有内存和启动性能限制，需要专门做适配优化。
• Cocos Creator：2D小游戏几乎是主场优势，天然支持微信小游戏导出，文档和中文社区非常成熟，包体小、上手快。缺点是3D能力相对弱。
• LayaAir：性能很强，包体控制得也好，但社区和生态比Cocos小一截，踩坑时能搜到的资料比较少。
• 原生JavaScript/TypeScript + 微信API：前端开发最熟悉，没有引擎负担，但一切基础能力都要自己搭，做一个3D休闲游戏工作量会直接爆炸。

Vibe Gaming第一款产品定位是轻3D休闲解压游戏，需要在手机上有稳定的3D表现力，所以我选了Unity。为什么不是Cocos？因为真要写复杂一点的3D渲染和物理交互时，Unity的成熟度还是更高，而且我本身对C#更熟。这里其实没有绝对的最优解，选型的核心逻辑是“你的游戏类型 + 你的技术底子”交叉之后最顺手的那个。如果做2D游戏，我个人建议直接Cocos Creator，别折腾。如果做3D，Unity是目前微信小游戏生态里最成熟的方案。

1.3 一人团队怎么排期：范围控制是命门

一人工作室最容易死在哪？不是技术难，是贪。你既想做玩法，又想搞皮肤系统，还想加排行榜、签到、抽卡，最后三周过去什么都只做了一半。

我给自己定的原则是：第一款游戏只是用来跑通“开发到上架”全流程的，不是用来发财的。所以功能清单压缩到了极致——核心玩法、三个关卡变体、一个简单的商店页（看广告换皮肤）、数据统计。具体排期如下：

一个人做项目，最有效的做法就是给自己设置“砍需求节点”。比如玩法Demo做出来之后，如果自己玩了三遍都觉得没意思，直接砍掉重来，不要舍不得；如果核心玩法没问题，后期所有需求都要问一句“这个功能不加会影响上架吗？”，不影响就不加。这个习惯帮我省了至少三周时间。

2. Unity打包微信小游戏：从零到能跑

2.1 环境准备清单：版本一定要选对

Unity打包微信小游戏并不是官方的默认导出选项，而是需要安装Unity官方出的“微信小游戏适配插件”，通过这个插件做转换。整个环境由几个部分组成，缺一不可：

• Unity：建议用2021.3 LTS或2022.3 LTS，千万不要用刚发布的最新beta版。官方适配插件和一些三方库对新版Unity的兼容经常慢半拍，我试过一次在Unity 6预览版上导出失败，浪费了一整天。
• 微信开发者工具：装稳定版就行，它既是IDE，也是预览和调试的入口。
• Unity微信小游戏适配插件（minigame插件）：在Unity菜单栏导入后会出现“微信小游戏/WX”菜单，核心功能是转换游戏工程并生成小游戏项目目录。
• Node.js：部分流程和本地调试工具依赖node环境，建议装LTS版本。

安装顺序上没有特别严格的讲究，但有一个点要注意：微信开发者工具首次启动需要扫码登录，而Unity插件下一步的导出又需要读开发者工具的本地服务端口，所以建议先把微信开发者工具装好、登录一次并打开“安全设置-服务端口”，再回来导入Unity插件，否则导出过程可能找不到开发者工具的服务。

2.2 项目预处理：这些设置不改，导出必崩

Unity项目并不是点一下导出按钮就万事大吉。有几个关键的Player Settings如果不动，打出来的小游戏常有黑屏、加载卡死、甚至直接崩溃的问题。

先从最基本的说起：打开Build Settings，把平台切到WebGL。微信小游戏本质上跑的是Unity WebGL的编译产物，Unity导出成一个webgl项目，然后插件再把产物封装成小游戏目录结构。有些人的Unity安装里根本没加WebGL模块，打包时会报错，请先在Unity Hub里把“WebGL Build Support”模块装好。

然后是Player Settings里的几个关键选项：

• Color Space：建议保持Gamma或Linear，别乱试。如果你用Linear但项目光照贴图没有做好线性化处理，整体画面会偏灰。
• Scripting Backend：选Mono或IL2CPP。微信小游戏插件对这个的处理比较特殊，一般情况用默认或IL2CPP，但如果包体压不下来，Mono有时反而更稳定，需要实测对比。
• Strip Engine Code：启用，能去掉不用的Unity引擎模块，显著减小包体。
• Compression Format：选Gzip或Brotli，但要注意服务器需要有对应的Content-Encoding支持，如果资源走CDN，一定要确认CDN能正确处理压缩格式，否则加载会异常。

除了Player Settings，项目中有些Unity功能在微信小游戏环境里是不可用的，比如WebGL上用不了UNET旧版网络、部分多线程API、System.IO读写本地文件等。我踩过一次很深的坑：游戏里保存存档用了File.WriteAllText，在编辑器里跑得好好的，一上真机就报错。微信小游戏没有本地文件系统写权限，你需要用wx.setStorage或插件提供的存档接口。

2.3 用插件导出：分步操作记录

项目准备好之后，整个导出流程是这样的：

1. 在Unity菜单栏选择“微信小游戏 -> 转换小游戏”，打开转换工具窗口。
2. 填写小游戏AppID。这一步有两个选择：如果你已经注册了小游戏并拿到了AppID，直接填；如果还没有，可以先选“测试号”，用游客模式跑通流程。
3. 在“构建选项”里确认或调整：游戏名称、初始场景、是否压缩代码、是否开启引擎裁剪等。
4. 确保微信开发者工具的本地设置里“服务端口”是开启状态，然后点击“构建”按钮。
5. 插件会先调用Unity的WebGL构建流程，产出webgl构建物，再做转换，最终在项目目录下生成一个小游戏工程文件夹（默认叫wechatgame）。
6. 用微信开发者工具打开这个文件夹，如果一切正常，开发者工具里能看到game.js、game.json和一些webgl相关目录。

第一次见到这个输出目录时你可能会懵，因为它和你熟悉的Unity构建产物完全不一样。这里给个简单对照：webgl目录存放的其实是编译出来的binary资源和Unity loader，game.js是小游戏逻辑入口，game.json是小游戏配置文件（相当于Manifest），里面规定了屏幕方向、启动参数等。

导出成功不等于一切正常。第一次你大概率会在开发者工具里看到白屏或者一堆报错。别慌，先用开发者工具的Console看具体错误，绝大多数是资源路径不存在、跨域请求被拦、或者某个API不支持。开发模式下建议把日志等级调到Verbose，不然很多内部报错会被吞掉。

2.4 真机预览与联调：先学会看日志

开发者工具里跑通的是模拟环境，真机表现经常不一样。真机预览主要有两种方式：

• 二维码预览：开发者工具顶部点“预览”，会生成一个二维码，手机微信扫码即可打开你的小游戏。前提是手机和电脑在同一个局域网，如果扫码后加载不出来，先检查网络。
• 真机调试：在手机上打开调试模式，可以在手机上显示vConsole日志，这是查真机问题最常用的手段。

真机上的问题往往和性能有关：启动太慢、掉帧、内存被系统杀掉。这些都是模拟器里看不出来的。所以从项目一开始，你就要养成在真机看日志的习惯，别等到快上架了才第一次点真机预览，那会有一堆意外惊喜等着你。内存峰值和启动耗时这两个指标，建议在开发和优化的每个阶段都记录一次，后面压包体和排查崩溃都要用这些数据。

3. 微信小游戏视频播放方案：不要硬刚VideoPlayer

3.1 为什么视频播放是独立开发者的小游戏痛

很多做Unity小游戏的人都会遇到同一个需求：游戏里要放一段剧情动画、教学演示、或者广告视频。你翻了Unity的文档，发现有个VideoPlayer组件，兴冲冲地拖进去设置好视频剪辑，打包到微信小游戏里，结果发现黑屏、没声音、或者直接崩溃。

原因其实很简单：微信小游戏运行在浏览器内核里，本质上是WebGL渲染环境，Unity的VideoPlayer在WebGL平台依赖的是浏览器解码能力，而微信小游戏对这套解码体系做了严格限制，Unity的VideoPlayer大部分情况下根本拿不到可用的视频解码资源。再加上视频属于流媒体格式，浏览器对编码、码率、分辨率都有要求，直接用传统思路去播，不炸才怪。

所以微信小游戏里要播放视频，最主流、最可靠的做法只有一条：走微信原生的video能力，绕开Unity的解码。这也是我要讲的方案核心。

3.2 核心方案：用wx.createVideo接管一切

微信小游戏提供了原生视频接口，你可以在小游戏代码里创建视频对象，控制它的位置、尺寸、播放、暂停、结束回调等。因为走的是原生能力，解码、渲染、音频全都不经Unity的WebGL层，所以稳定性是最好的。

这里补一段示例代码，在小游戏工程里这样创建视频：

const video = wx.createVideo({ src: 'https://your-cdn.example.com/videos/tutorial.mp4', objectFit: 'contain', poster: 'https://your-cdn.example.com/images/video-poster.png', controls: false, autoplay: true, muted: false, initialTime: 0, pageGesture: true }); video.show(); video.onEnded(() => { console.log('视频播放结束'); video.destroy(); });

注意事项：视频地址必须是https协议的网络地址，暂时不支持本地文件路径。如果视频不显示，先检查URL能不能在手机上直接访问，再检查域名有没有配置到小游戏后台的downloadFile合法域名里。这里的域名配置进“开发设置 - 服务器域名”，只配置request域名是不够的，视频加载走的是媒体能力，一些特殊资源还需要在后台单列授权。

3.3 Unity侧的封装：用jslib搭桥

既然视频能力在微信侧，你就需要在Unity的C#代码里调用微信小游戏的JS API。Unity WebGL支持jslib机制，可以把C#函数映射到JavaScript函数，这样Unity逻辑和微信原生能力就能打通。

第一步，在Unity项目的Assets目录下创建一个名为Plugins的文件（如果没有的话），再在里面放入一个jslib文件，比如MiniGameVideo.jslib。内容大致如下：

mergeInto(LibraryManager.library, { MiniGameVideo_Play: function (url, x, y, width, height) { var videoUrl = UTF8ToString(url); var video = wx.createVideo({ src: videoUrl, x: x, y: y, width: width, height: height, objectFit: 'contain', controls: false, autoplay: true }); video.show(); video.onEnded(function () { video.destroy(); }); }, MiniGameVideo_Stop: function () { // 这里可以维护一个全局video对象，调用停止并销毁 } });

第二步，写C#封装类：

using System.Runtime.InteropServices; public static class MiniGameVideoPlayer { [DllImport("__Internal")] private static extern void MiniGameVideo_Play(string url, float x, float y, float width, float height); [DllImport("__Internal")] private static extern void MiniGameVideo_Stop(); public static void Play(string url, float x, float y, float width, float height) { #if UNITY_WEBGL && !UNITY_EDITOR MiniGameVideo_Play(url, x, y, width, height); #else Debug.Log("非WebGL环境，跳过视频播放"); #endif } public static void Stop() { #if UNITY_WEBGL && !UNITY_EDITOR MiniGameVideo_Stop(); #else Debug.Log("非WebGL环境，跳过视频停止"); #endif } }

这样你只要在游戏任意位置调用MiniGameVideoPlayer.Play(videoUrl, 0, 0, 750, 1300)，就能在小游戏里弹出原生视频。这里有个坑必须提醒：C#层不要用Debug.Log打印太多帧率信息，jslib和C#之间的传参如果是字符串，要注意内存释放，很多人就是在动态传字符串时引发了内存泄漏。

3.4 视频编码与iOS适配：编码没选对，白搭

方案选对了，视频本身也可能出问题。微信小游戏在不同系统上对视频编码的容忍度不一样，我踩到的典型情况是：安卓上播得好好的视频，iOS上黑屏；或者iOS有声音没画面。最后排查出来的原因基本都集中在编码参数上。

实践下来，最稳的视频参数组合是：

• 编码格式：H.264（AVC），不要用HEVC/H.265，兼容性差。
• 视频帧率：30fps或以下，60fps的视频在低端机器上解码压力太大。
• 分辨率：建议压到1920x1080以内，很多小游戏场景根本不需要4K。
• 码率：控制在2-4Mbps，如果视频是压缩后的剧情或教学，1-2Mbps也够用。
• 音频编码：AAC，采样率44100或48000。
• 不要带B帧，或者明确不要高编码层级，否则部分Android机型无法硬解。

打包视频时用FFmpeg做一次转码是最稳的，我给你一条常用的转换命令：

ffmpeg -i input.mp4 -c:v libx264 -profile:v baseline -level 3.0 -pix_fmt yuv420p -b:v 2M -c:a aac -b:a 128k -movflags +faststart output.mp4

这个命令核心做了三件事：指定H.264 baseline规格，保证老设备能硬解；把颜色格式改成yuv420p，这是兼容性最广的格式；加上faststart标记，让视频可以在线边下边播。

还有一个iOS专属问题：视频控件在iOS上是以原生控件的形式浮在canvas之上的，你没法用Unity的UI遮挡它。在策划阶段就要考虑这个层级问题，比如在iOS上弹视频之前，先把游戏暂停，画面切到深色背景，免得玩家看到渲染层级穿帮。

4. 性能优化、包体控制与机型适配

4.1 微信小游戏的包体红线：主包和资源包要拎清

微信小游戏对包体有硬性限制，不搞清楚会直接卡在上架环节。当前的基本标准是：主包体积不能超过4MB（不过不同时期、不同类目会有微调，以官方文档为准），如果总包要超过20MB，就需要做分包加载，把非核心资源拆到子包里并配置加载策略。

我第一款游戏最初把全部资源都塞进包里，效果是启动加载5秒、转圈转得人心慌。后来按方案整改，主包压到2.8MB，视频、音乐、大图片全部挪到CDN，启动时间缩短到2秒左右。这个优化带来的体验提升是质的飞跃。

控制包体我主要做了这几件事：

• 贴图格式：全部转成ASTC或ETC2，不要用RGBA32裸存。ASTC在低端Android手机上支持也还可以，是当前比较适合游戏的协议格式。
• 音频转压缩格式：背景音乐用MP3或AAC，压缩比高，音效可以用低码率。不要直接用WAV。
• 剔除无用shader变体：Unity的shader会包含很多变体，如果不做剔除，shader体积可能比模型还大。用“Shader Variant Collector”收集真正用到的shader和keyword，然后关闭多余的。
• AssetBundle分包：把界面图、角色、场景资源拆到不同的AB包，按需加载、用完释放。

4.2 启动速度和内存的平衡术

很多新手只盯着包体大小，忽略了运行时的内存占用。Unity WebGL在微信小游戏里跑，实际上是在wasm的内存空间里做游戏渲染，而这个内存空间是有上限的。如果游戏场景资源过多、对象池没做好、贴图全部常驻内存，很容易在真机上被系统直接杀掉。

我的一个习惯是：主界面只保留核心资源，切场景时彻底卸载上一个场景的asset。在Unity里做这件事最直接的是Resources.Load和AssetBundle搭配使用，避免所有贴图都被打包进默认场景。另一个容易被忽略的点是，代码里用了太多FindObjectOfType和GetComponent，这类调用会造成临时GC分配，累积多了就会卡顿甚至掉帧。建议养成在Awake或Start里缓存组件引用的习惯。

性能监控方面，微信开发者工具自带真机调试面板，可以看到帧率、内存、CPU占用等实时曲线。我的做法是在游戏里做一个隐藏的性能开关，长按5秒触发，在屏幕上实时显示FPS和内存占用，方便在真机各机型上测性能时快速定位瓶颈。

4.3 低端机和中端机的适配策略

一人工作室往往没有条件搞一堆测试机，但两种设备一定要覆盖到：一款两年前的千元Android机、一台两年前的iPhone。微信小游戏用户里很大一部分用的是中低端Android机，如果只拿自己旗舰机测，可能发布会变成灾难。

我的实际测试经验是这样的：很多中低端Android机内存只有4GB甚至3GB，纹理压缩格式不完全支持ASTC 4x4或8x8，需要做fallback处理。iOS机型对WebGL渲染的支持比较统一，但也别忽略iPhone 8、iPhone SE这类性能有限的机型，高画质特效在这种机型上会明显掉帧。

一个比较省心的做法是做一个简单的画质自适配：通过SystemInfo拿到设备型号和内存大小，低端机就关掉抗锯齿、降低渲染分辨率、减少粒子数量，中端机开中等画质，高端机开满特效。别觉得这个功能复杂，在Unity里其实只需要几个配置开关，却能帮你省掉一大半的适配投诉。

5. 上架、审核与成本明细

5.1 资质准备：软著和版号到底怎么回事

微信小游戏上架是需要一些资质的，这和你做App完全不一样。App主要看开发者账号和隐私合规，小游戏审核时会更关注版号和著作权。

先说普通休闲类小游戏（纯广告变现，不含需要付费解锁的核心权益），目前的核心要求是非游戏类小程序主体也能发布小游戏，但游戏提审时必须提供软件著作权证书。如果没有软著，连提审入口都进不去。

软著申请可以直接去中国版权保护中心官网提交，费用为零，但审核周期一般要一到三个月。时间紧张的话可以找代理加急，一般几百到一千多不等，通常一到两周出证。我个人的建议是：从项目立项那天起就整理开发文档、代码截图和操作说明，等项目做了一半就可以着手申请软著，不要等到游戏做完了再申请，白白多等一个多月。

至于版号，如果小游戏涉及充值、内购、虚拟支付等，一般需要版号。但微信小游戏目前对纯广告变现的轻休闲游戏，多数情况下是不强制提供版号的，具体执行口径经常调整，提审前务必去官方文档或社区看最新要求。做之前就规划好变现模式，别陷入“游戏做完了才发现资质不够”的处境。

5.2 审核避坑清单：这些坑我替你踩了

提审被拒一次，至少额外等一周，这对一人工作室来说非常肉疼。我整理了一份自己踩过和见过别人踩的审核高频被拒原因：

• 无软著或软著信息不符：申请时填写的游戏名称必须和提交的小游戏名称一致，很多人软著下来了但作品名称和游戏名称对不上，照样被拒。
• 隐私协议缺失：微信后台没有配置隐私保护指引，或者游戏内没有展示用户隐私政策入口。独立开发者经常忽略这个，其实是硬指标。
• 广告频次过高：小游戏里广告弹出过于频繁，审核方会以“影响用户体验”为由打回。建议在提审版本里把广告频率刻意调低，过审再按你的设计上线。
• 内容违规：涉及低俗、暴力、侵权、过度恐怖等内容的，基本没戏。小游戏里的美术素材绝对不能直接用明星照片、动漫角色或任何可能涉及版权的素材。
• 需要测试账号未提供：如果你的游戏有登录体系，提审时必须提供可用的测试账号和说明文档，否则审核无法体验完整流程。
• 包体过大或加载异常：审核真机上如果加载时间过长、白屏、崩溃，会直接被打回。这个只能靠提前真机测试解决。

我在第一次提审时就栽在没有提前准备好隐私政策上，多花了整整一周。后来学聪明了，把提审资料做成一个checklist，每一项确认无误后再提交，再也没因为资料问题被拒过。

5.3 一个人做一款小游戏，到底要花多少钱

这个问题在我的私信里被问过太多次：“开发一个app并上架大概要多少钱”。如果是微信小游戏，答案可能比你想象中更少。我给你列一份真实成本明细，按“全部自己做”的最低预算来算：

如果完全零外包、零服务器、用免费资源加自己画，整款游戏上线前的现金成本可以控制在几百元以内，大头其实就是软著加急费。这是微信小游戏对独立开发者最友好的地方，现金流压力极小。

但如果你把人力成本算进去，就是另一回事了。三个月的全职工作量，按一个中级开发者的市场薪资来算，机会成本大概在几万元到十几万元之间。所以我一直建议业余开发者先不要裸辞，用业余时间做第一作，跑通流程、验证能力，比一上来就ALL IN稳得多。另外如果资金预算比较充足，可以花几百到几千元去外包美术或音效，把单人最费时间的部分外包出去，性价比会更高。

6. 常见问题与排查技巧实录

6.1 启动白屏或一直卡在加载页

启动白屏是Unity转微信小游戏最常见的现象，原因五花八门，但按顺序排查基本能解决。先看微信开发者工具Console里有没有JS报错，如果报错指向“Cannot find module”“Url not found”之类，大概率是资源路径或CDN配置问题。如果Console没报错但一直白屏，可以试试把game.json的“showStatusBar”临时关掉，有些版本会因为这个参数导致渲染异常。

另外，很多白屏是因为Unity构建产物和插件版本不匹配。Unity升级版本后，旧的小游戏适配插件没同步升级，构建出来的webgl产物和加载器对不上，就会加载失败。所以每次升级Unity或插件后，都重新导出一遍，不要把旧构建物改一改就传上去。

6.2 视频在iOS上黑屏、没声音或自动全屏

iOS端微信小游戏的视频播放有两个经典问题：第一个是iOS对视频播放的“用户手势触发”要求很严格，如果游戏在没有任何用户交互的情况下直接调用play，很可能被系统静音或忽略。解决办法是在玩家点击事件的回调里再调用播放，或者先用muted的video预热一次，后续再从头播放。第二个问题是iOS上视频控件层级最高，全屏播放时会盖住游戏画面，如果你要的是内嵌式视频，需要做特殊适配，比如把视频高度设置在屏幕逻辑像素的安全区内，并接受“播放时游戏画面被覆盖”的现实。

之前我在Unity侧遇到一个更隐蔽的问题：视频播放完成后，Unity游戏声音变小了。这是因为iOS视频播放时音频会话（AudioSession）被接管，播放结束后没有切回游戏音频。处理方式是在jslib里监听onEnded，调用wx.setInnerAudioOption重置音频会话，或者视频播完后再重新触发一次游戏内音频的play。

6.3 真机上内存持续上涨，最终崩溃

Unity WebGL在移动端的内存管理不是简单看堆大小就够，wasm线性内存和Unity内部的托管堆是两回事。我用的一款空闲型小游戏在真机上长时间挂机后内存一直涨，最后崩掉，排查下来是AssetBundle加载后没有卸载，场景切换时旧的纹理和mesh没被GC。解决办法是采用引用计数管理资源：加载AB包后记录引用，用完调用Unload并清理实例，同时在切场景时调用Resources.UnloadUnusedAssets。

还要注意一个点：不要在Update里持续动态实例化GameObject。我最初做粒子特效时图省事，每帧生成一个粒子对象，肉眼看到的内存不算高，但GC导致的帧率抖动非常明显。改用预实例化对象池后，帧率高了几帧而且稳定多了。

6.4 广告组件不生效或提审被拒

广告变现是很多休闲小游戏的核心收入，但广告组件在真机上不展示也是非常常见的问题。常见原因有：未在微信后台开通流量主、广告位ID填写错误、测试阶段用非测试广告位、广告组件和游戏逻辑互相抢资源导致加载失败等。建议从第一天接入广告就严格区分测试ID和正式ID，用官方文档提供的测试广告位做开发调试，上线前再用正式广告位替换。

还有一个我观察到的坑：广告加载其实有较长的异步流程，如果玩家在广告未ready的时候就调用AdUnit.show()，可能只看到一个空白区域，甚至没有任何回调。正确做法是在进入游戏时提前load()一次广告，监听onLoad，然后在合适的展示时机再show()。安卓机上广告和Unity游戏之间的内存竞争比较明显，展示广告前最好主动释放一些不在屏幕上的资源，能明显降低广告展示时的崩溃率。

6.5 常见问题速查表

7. 最后的一点心里话

如果你问我一人工作室做微信小游戏这三个月最大的收获是什么，我会说不是游戏上线赚了多少钱，而是终于把“一个人也能完整做出一款上架的游戏”这件事跑通了。独立开发的崩溃感往往来自不确定性：你不知道自己能不能做出来，不知道平台会不会通过，不知道投入的钱和时间能不能回来。但当你走到“过审上线”这一步，这些不确定性至少已经破除了大半。

在做这款游戏的过程中，我也接触了不少AI辅助开发工具，比如用AI帮忙生成代码注释、补充文档、快速搭场景原型，确实能省一些琐碎时间。但我个人的体会是，AI工具适合做“加速器”，不适合做“决策者”。独立开发者最该靠自己的地方是玩法定位和体验决策——你知道什么东西好玩，什么东西不好玩，这个能力任何工具都替代不了。

最后再分享一个小技巧：上线之后不要急着做第二款，先盯着第一个版本的玩家反馈和漏斗数据看两周。微信小游戏的后台可以看到启动次数、人均时长、次留、广告点击分布，这些数据比你自己空想"玩家喜欢什么"靠谱得多。我第一款游戏的第二版优化，就完全是靠后台数据找出来的方向——发现某关卡的卡关率特别高，于是调整了难度曲线，次留立刻回升了一截。做小游戏，真的不是"做完就完"，上架才是真正的开始。