小游戏上线前，先把这三类崩溃测一遍

做小游戏最怕的不是玩法没人玩，而是上线第一天就崩。玩家不会给你写 bug 报告，他们只会直接划走、打一星、再也不回来。我自己的小项目上线前踩过几次坑，总结下来，崩溃基本逃不出三类：启动就崩、玩着玩着崩、切出去回来就崩。每一类都有对应的测法，花半天跑一遍，能省掉上线后一周的救火。

第一类：启动就崩——资源没加载完就急着进场

这是最常见也最致命的一类。表现是点开游戏黑屏、白屏，或者闪退回桌面。根子大多在启动流程：图片、音频、字体还没加载完，代码已经开始用它们了。

我以前写过一个叠塔小游戏，本地跑得好好的，一上真机就黑屏。查了半天，发现是背景音乐文件比较大，加载是异步的，而我第一帧就调用了播放接口。开发机上文件读得快，问题被掩盖了；真机上网络或存储慢一点，时序一错就崩。

测法很简单：第一，把启动流程拆成“加载”和“进入”两步，加载没完成之前不允许进入主场景，加载进度条要真实反映资源加载进度，而不是写死的动画。第二，用慢速网络和低端机各跑一次。微信开发者工具里可以模拟弱网，真机测试至少借一台两三年前的旧手机。第三，启动失败要有兜底：加载超时给重试按钮，别让玩家对着黑屏干等。

还有一个容易漏的点：首屏用到的所有资源都要在启动阶段就位，别把主角图片、第一关的贴图放到后面按需加载。按需加载没错，但首屏不行，首屏必须一次到位。

第二类：玩着玩着崩——状态越攒越多，内存越吃越满

这类崩溃最气人，因为它不发生在固定位置。玩家玩了十分钟、二十分钟，突然闪退。你在开发机上测三分钟没事，就以为没问题了。

根子通常是资源泄漏：每一局新生成的节点、粒子、音效没有及时释放，越攒越多；或者是对象池没做好，频繁创建销毁导致内存抖动。叠塔游戏里每落一块砖就生成一个节点，砖块落下后如果还留在场景树里不清理，一局下来几十个节点还好，连玩五局就是几百个。

测法：第一，连玩测试。不要只测一局，连续玩十局、每局都重新开始，看内存占用是不是一直在涨。微信开发者工具的性能面板能看到内存曲线，如果曲线只升不降，就是有泄漏。第二，重点盯“重新开始”和“返回大厅”这两个操作。很多泄漏都藏在这里：切场景时旧场景的监听器没注销、定时器没清掉。第三，粒子和动画效果要设上限。同屏粒子数、同时播放的音效数都要有上限，别让效果无节制叠加。

还有一个细节：分数、步数、金币这些数值要做上限保护。别觉得数值溢出是理论问题，放置类游戏挂机一晚上，数值能涨到你意想不到的量级，提前做钳制比事后修存档容易得多。

第三类：切出去回来就崩——前后台切换没处理好

手机游戏的特殊之处在于，玩家随时会切出去回个微信、接个电话。游戏从后台回来时，音频上下文可能已经丢了，定时器可能被系统挂起，网络请求可能超时了。如果代码假设“切回来时一切如旧”，就等着崩。

我踩过的一个坑是激励视频：玩家看完广告切回来，游戏还在等广告回调，结果回调因为页面不可见被系统丢了，游戏卡在“等待奖励”界面动不了，只能杀进程重进。

测法：第一，手动多切几次。玩到一半按 Home 键切出去，等十秒、三十秒、一分钟再切回来，每次都看看界面是不是正常、按钮还能不能点。第二，把音频和定时器做成“切回来时重新校验”的逻辑：回来先检查音频上下文还在不在，不在就重建；定时器按时间戳补算，而不是假设它一直在跑。第三，网络请求全部加超时和重试。切后台回来后发出去的请求很可能已经超时了，别让一次失败就卡住整个流程。

上线前半天，按这个顺序跑

先跑启动测试：冷启动、热启动、弱网启动各三遍。再跑长时测试：连续玩十局，盯内存曲线。最后跑切换测试：切出去、锁屏、接电话模拟，各来几遍。三种都过了，再考虑发版。

这三类测完，覆盖了小游戏九成以上的线上崩溃。剩下的那一成是机型适配和平台差异，靠灰度发布和崩溃上报慢慢收。发版不是终点，是开始收集真实数据的起点——但前提是，第一天别让玩家一进来就崩。