小游戏这条路上，我见过太多人卡在同一个位置：引擎装好了，场景也搭出来了，点导出之后却得到一堆看不懂的文件，扔进开发者工具里要么白屏，要么帧率掉到个位数。问题不在于引擎不好用，而在于很多人把「用团结引擎做微信小游戏」当成一次普通的打包动作，而它实际上是一条从 C# 逻辑到 WebAssembly、再到小程序容器的完整链路，链路上每一环都有自己的硬约束。这篇内容写给两类人：一类是完全没接触过小游戏导出流程、想从零跑通第一个可玩版本的新手；另一类是已经能导出、但包体和帧率一直压不下来的同行。我会以 Starter Kit 为主线，把环境搭建、模块拆解、第一个可玩循环、分包策略和真机验证这几件事讲透，中间穿插我自己踩过的坑和对应的处理办法。
1. 先搞清楚引擎在小游戏这条链路上到底做了什么
很多人对导出这件事的想象是「引擎直接编译出一个能在微信里跑的包」，于是按原生游戏的思路铺场景、堆特效、写长协程，等真机一跑才发现：drawcall 一超帧率就崩，贴图没压缩首包直接飙到八兆，音频播了三个就哑了。这些都不是玄学，是 Web 技术栈本身的约束在起作用。
先把这个链路讲清楚：引擎把你的 C# 脚本、场景、预制体、贴图、音频，通过构建管线编译成一份 wasm 二进制加一堆序列化后的资源文件，再套一层平台适配层，由小程序容器负责加载和调度。你在 C# 里写的每一行逻辑，最终都要跑在浏览器的 JavaScript 引擎里。理解这条链路，是后面一切优化和排错的前提。
1.1 三条硬约束决定了你的架构长什么样
我把小游戏开发中最需要提前算清楚的约束整理成下面这张表，这三条基本决定了一个项目能走多远：
| 约束维度 | 具体表现 | 对设计的直接影响 |
|---|---|---|
| 首包体积 | 主包通常要按 4MB 这个量级来做预算，超了必须重划分包结构 | 首屏场景、核心 UI 图集、必要音效放主包，其余资源全进分包 |
| 运行内存 | 移动端 WebView 里的可用堆内存远小于原生包，64 位机型和 32 位机型差异明显 | 纹理尺寸上限、对象池容量、同时存在的音频实例数都要提前定额 |
| 单线程执行 | 主逻辑、物理、渲染提交共用一个执行线程，没有独立的渲染线程 | 避免长时间同步计算，重活拆帧、预计算或挪到加载阶段 |
主包体积这个数字不是永远固定的，平台会周期性地调整规则，所以动手之前一定要去翻一遍当前的小游戏官方文档，用最新数字做预算，而不是拿两年前的笔记拍脑袋。我见过一个团队按旧数据规划包体，做完之后发现预算差了一大截，整个资源目录结构推倒重来，白干一周。
内存这条更隐蔽。编辑器里跑得好好的场景，真机上加载到第三个关卡就被系统回收，这种问题九成是因为贴图尺寸按 PC 标准设的——一张 2048 的 RGBA 贴图在内存里就是 16MB，放五六张直接把预算吃光。先定纹理规格，再谈美术风格，这个顺序不能反。
1.2 引擎给的是工作流，适配层负责翻译
团结引擎在这条链路上提供的是一套完整工作流：场景编辑、预制体、C# 脚本、动画状态机、材质系统，最后通过 WebGL 构建管线产出可交付物。而真正的「翻译」工作由平台适配层完成——它把引擎运行时的输入查询、音频播放、文件读取、渲染上下文调用，翻译成平台侧对应的接口。
这个翻译关系非常关键，因为它决定了你排查问题时该往哪个方向看。举几个具体例子：
- 你在 C# 里调
Input.GetTouch，底下对应的是平台的触摸事件回调，如果点击没反应，先看适配层的触摸映射有没有被 UI 层吃掉； - 你播一个
AudioSource，底下很可能是有限的音频实例池，超出池子的播放请求会被静默丢弃，表现出来就是「某些音效偶尔不响」； - 你读
StreamingAssets下的文件，底下走的是虚拟文件系统，路径大小写、前缀在真机上和编辑器里可能不一致。
我的经验是：任何「编辑器正常、真机异常」的问题，先怀疑适配层边界，再怀疑引擎内部。这个判断顺序能省掉大量无效排查。
1.3 Starter Kit 的价值不在 demo，在于把「必写代码」固化下来
市面上的起始工程包，很多人第一眼会看它有没有炫酷的示例场景，其实那是最不值钱的部分。Starter Kit 真正的价值在于把「每个小游戏项目都要写一遍、写错一次就要调两天」的公共代码提前写好了：
- 启动流程：引擎初始化、首屏资源加载、分包预加载、进入主场景，带进度条和失败重试；
- 音频管理：实例池、全局静音、切后台自动暂停与恢复；
- 本地存储：同步与异步封装、容量保护、数据结构版本迁移；
- 输入适配：把触摸、鼠标、键盘统一成一套接口，方便在编辑器里用鼠标调试；
- UI 适配：安全区处理、不同宽高比下的锚点与缩放策略；
- 性能开关：帧率上限、动态分辨率、低端机降级档位。
我做过一次对比统计：从零手写这套基础层，一个熟练的开发者大约需要三到五天，而且第一次几乎一定会漏掉两个东西——切后台时的音频暂停恢复、以及分包加载失败的重试。这两个坑如果不填，上线后大概率会收到「切出去回来就没声音」和「弱网下永远卡在加载页」的反馈。Starter Kit 提前把它们填了，省下来的时间够你把核心玩法多打磨两轮，这笔账很划算。
2. 把引擎、导出模块和调试工具串成一条能跑通的链
环境这一步，真正麻烦的不是安装，而是版本对齐。引擎编辑器、小游戏导出模块、开发者工具这三者之间是有版本耦合的，错配的表现往往不是明确的报错，而是构建成功但运行异常，查起来非常痛苦。
2.1 版本组合是最容易翻车的一环
我的建议是把版本号当成项目资产来管理，写进仓库根目录的一个说明文件里，团队所有人统一：
| 组件 | 选型建议 | 为什么这么选 |
|---|---|---|
| 引擎编辑器 | 选一个 LTS 版本，全团队锁死，不要随手升级 | 导出模块是跟着编辑器版本走的，升级编辑器往往要一起升模块 |
| 小游戏导出模块 | 与编辑器版本严格对应 | 模块里引用了引擎运行时的内部接口，版本错配会编译通过但运行崩 |
| 开发者工具 | 用较新的稳定版，不要用测试版 | 老版本对 wasm 的调试支持差，断点打不上，日志也容易丢 |
我吃过一次亏：队友为了让某个渲染问题消失，自己把编辑器升了一个小版本，构建出来的包在真机上黑屏且控制台无报错。前前后后查了两天，最后发现是导出模块没跟着升级，适配层和运行时对不上。版本锁定这件事，比任何优化都重要。
2.2 从新建工程到第一次成功导出
具体操作我按顺序列一遍，每一步都写清楚意图，别跳：
- 新建 3D 工程，渲染管线选内置管线。轻量管线在小游戏上能跑，但 shader 变体数量和后处理开销要仔细评估，第一个项目不建议一上来就用。
- 切平台到 WebGL，这一步会触发资源重新导入，耐心等。
- 在 Player Settings 里逐项配置，下面这几项是必改的：
- 关闭自动图形接口，只勾选 WebGL 2.0。部分老旧机型可以回退到 1.0，但需要单独做一次兼容性评估，别默认全开；
- 色彩空间选 Gamma。线性空间在 Web 环境下需要额外的转换开销，移动端收益不明显；
- API 兼容级别选 .NET Standard 2.1，别用 Full；
- 代码剥离级别从 Medium 起步，遇到反射相关的运行时错误再往上调；
- 关闭开发构建、自动连接性能分析器、脚本调试这三个选项，它们会让包体显著变大；
- 纹理压缩：Web 环境不支持某些压缩格式，优先用 ASTC 或 ETC2，低精度贴图可以直接用 RGBA16 加关闭 mipmap，比强行压缩更省心。
- 安装小游戏导出模块，在构建菜单里选择导出到小游戏平台，指定一个空的输出目录。
- 用开发者工具打开输出目录，填入项目标识，进模拟器看效果。
提示：第一次导出时把输出目录清空再构建。增量构建残留下来的旧资源经常会导致「本地改了没生效」这种迷惑现象，尤其是改了图集之后。
2.3 导出产物到底长什么样
搞懂产物结构，后面所有问题都能定位。典型的输出目录大致是这么个形态：
build/ ├── game.js // 入口，负责启动适配层和引擎运行时 ├── game.json // 小游戏配置：分包、屏幕方向、插件声明 ├── project.config.json // 开发者工具的项目配置 ├── wasm/ │ ├── game.wasm // 你的 C# 逻辑编译产物 │ └── game.framework.js // 运行时胶水代码 ├── data/ │ ├── resources.abi // 首包资源包 │ └── *.bundle // 各资源包 └── webgl/ └── ...game.json是你后面调整分包策略的主战场，分包列表、屏幕方向、网络超时都写在这里。wasm/game.wasm的体积直接受代码剥离级别影响，剥离调高一档，这个文件能小几百 KB。data/目录是资源体积的大头，绝大部分瘦身动作都发生在这里。
2.4 第一次打开开发者工具最常见的几种状况
| 现象 | 大概率原因 | 处理方向 |
|---|---|---|
| 白屏，控制台无报错 | wasm 文件路径不对或没被正确加载 | 打开网络面板看 wasm 请求是否返回成功，检查输出目录结构 |
| 报 WebAssembly 实例化内存不足 | 初始堆内存分配过大或首屏资源超量 | 降低初始内存设置，把首屏用不到的资源挪出主包 |
| 画面全黑但逻辑在跑 | 相机清除标志配置问题，或用了不支持的渲染特性 | 检查相机背景，关掉半浮点精度相关的后处理 |
| 点屏幕没声音 | 平台策略要求首次用户交互后才能播放音频 | 在首个点击回调里做一次静音播放触发，解锁音频上下文 |
这几条覆盖了新手 90% 的首次失败场景。我的建议是：第一次导出先别急着做玩法，先导一个只有相机和 UI 文字的空场景，确保这条链路完整跑通。链路通了再往上加东西，出问题时变量才少。
3. Starter Kit 拆包：六个模块各自管什么，哪些该先动
拿到 Starter Kit 之后，最忌讳的做法是直接往里面塞业务代码。先花半小时把目录结构和启动时序摸清楚，后面能省几十次「为什么这个初始化顺序不对」的排查。
3.1 目录结构与启动时序
典型的 Starter Kit 目录大致长这样（不同版本会有出入，但职责划分基本一致）：
Assets/ ├── _StarterKit/ │ ├── Runtime/ │ │ ├── Bootstrap.cs // 总入口，控制启动流程 │ │ ├── AssetLoader.cs // 资源加载与引用计数 │ │ ├── AudioService.cs // 音频实例池 │ │ ├── StorageService.cs // 本地存储封装 │ │ ├── InputAdapter.cs // 输入统一接口 │ │ └── PlatformBridge.cs // 所有平台差异集中在这里 │ ├── Editor/ │ │ └── BuildPipeline.cs // 构建前后的自动化钩子 │ └── Config/ │ └── starterkit.config.json ├── Scenes/ │ ├── Boot.unity // 启动场景，只有一个加载器对象 │ └── Main.unity // 主场景 └── Resources/启动时序是这样的：先加载 Boot 场景，这个场景里只有一个挂了 Bootstrap 脚本的空对象，画面是一片纯色加进度条。Bootstrap 依次做几件事——读取配置文件、初始化音频服务、拉取首屏资源、检查分包状态、切换主场景。把启动场景和主场景彻底分开，是 Starter Kit 里我认为最值得抄的一个设计，因为它让「首屏要加载什么」变成一个可控的显式列表，而不是隐式散落在各处的引用。
3.2 PlatformBridge：所有平台差异收在这一个文件里
这个模块是整个 Kit 里最值钱的部分。原则很简单：所有平台专有调用都必须经过这一层，业务代码里不允许出现任何直接的平台接口调用。
实现上用条件编译加 JavaScript 互调：
using System; using System.Runtime.InteropServices; using UnityEngine; public static class PlatformBridge { #if UNITY_WEBGL && !UNITY_EDITOR [DllImport("__Internal")] private static extern void WX_LoadSubpackage(string name, string callbackObj, string method); #else private static void WX_LoadSubpackage(string name, string callbackObj, string method) { // 编辑器与其它平台下走本地模拟，直接返回成功 var go = GameObject.Find(callbackObj); go?.SendMessage(method, name, SendMessageOptions.DontRequireReceiver); } #endif public static void LoadSubpackage(string name, Action<string> onDone) { var receiver = SubpackageReceiver.Create(onDone); WX_LoadSubpackage(name, receiver.name, "OnLoaded"); } }配套的 JavaScript 侧胶水文件负责把调用转到平台接口，并在完成或失败时回调回 C#。这样写的好处是：将来要适配到别的容器环境，只需要改这一个文件和对应的脚本文件，业务层一行都不用动。我在一个项目里就是这么做的，后来需要额外支持一种投放渠道的包，改动量控制在半天以内。
3.3 音频与存储：两个最容易被低估的服务
音频服务看着简单，实际坑最多。核心是三件事：
- 实例池：平台侧同时存在的音频实例数量是有限的，超出的播放请求会被直接丢弃。所以 AudioService 里要维护一个固定大小的池，播放时复用，池满时按优先级抢占；
- 切后台处理：应用切到后台再回来，音频上下文可能已经失效，必须显式恢复，否则表现为「切出去再回来就没声音」；
- 首次交互解锁：平台的自动播放策略要求首次播放必须发生在用户交互之后，做法是在第一个点击回调里播一段静音音频。
存储服务的问题在于容量和原子性。同步存储接口的单个键值有大小上限，整体也有总容量限制，写超了会抛异常。我在 StorageService 里做了三件事：所有数据序列化后统一走一个入口，写入前检查长度并做截断保护，以及给数据结构加一个版本号字段，方便后续做迁移。版本号这个字段，一定要在第一个版本就加上，否则第二次改数据结构时你会被迫写一堆判断旧格式的脏代码。
3.4 哪些模块一上来就该改，哪些先别碰
| 模块 | 建议 | 理由 |
|---|---|---|
| PlatformBridge | 立即按自己的需要扩充 | 分包、分享、震动这些能力都得从这里走 |
| 配置文件 | 立即改，把分辨率档位、帧率上限写进去 | 这是全局性能的开关 |
| Bootstrap | 立即改，调整加载顺序 | 你的首屏资源和 Kit 的默认假设大概率不一样 |
| AudioService | 调参数，不改结构 | 池大小按项目音效数量调整即可 |
| AssetLoader | 谨慎动 | 引用计数和卸载逻辑改错会导致资源泄漏，先跑通再说 |
| StorageService | 只加不删 | 接口可以扩，别改已有方法的签名 |
4. 第一个可玩循环：从空场景到三分钟能上手
链路跑通之后，下一步是做出一个真正能玩的东西。我强烈建议第一个版本做得越小越好——一个能点、能动、有反馈的循环，就足够验证整条管线了。别一上来就做完整关卡。
4.1 为什么第一个版本必须用对象池加固定步长
小游戏的目标设备跨度极大，从高端机到几年前的入门机都在跑。这种环境下，两件事必须从第一行代码就做对：
- 对象池：任何会反复创建销毁的东西——金币、子弹、飘字、特效——全部走池子。WebAssembly 环境下的内存分配和垃圾回收特性跟原生包不同，频繁创建销毁容易造成帧时间尖峰，表现为「每隔几秒卡一下」；
- 固定步长：逻辑更新用固定时间步累加，渲染保持每帧一次。切后台回来时
deltaTime会变得非常大，如果不做钳制，角色会瞬移、物理会穿模。
4.2 主循环与生成器的骨架代码
下面这段是我常用的小游戏主循环骨架，可以直接抄：
using System.Collections.Generic; using UnityEngine; public class GameBootstrap : MonoBehaviour { [SerializeField] private Transform player; [SerializeField] private Camera mainCam; [SerializeField] private GameObject coinPrefab; [SerializeField] private Transform poolRoot; [SerializeField] private float moveSpeed = 6f; [SerializeField] private float spawnInterval = 0.8f; private const float MaxDelta = 0.05f; private readonly Queue<GameObject> coinPool = new Queue<GameObject>(); private Vector3 targetPos; private float spawnTimer; void Awake() { Application.targetFrameRate = 60; QualitySettings.vSyncCount = 0; Screen.sleepTimeout = SleepTimeout.NeverSleep; targetPos = player.position; PrewarmPool(20); } void Update() { float dt = Mathf.Min(Time.deltaTime, MaxDelta); HandleInput(); player.position = Vector3.MoveTowards(player.position, targetPos, moveSpeed * dt); TickSpawner(dt); } void PrewarmPool(int count) { for (int i = 0; i < count; i++) { var go = Instantiate(coinPrefab, poolRoot); go.SetActive(false); coinPool.Enqueue(go); } } void TickSpawner(float dt) { spawnTimer += dt; if (spawnTimer < spawnInterval) return; spawnTimer = 0f; if (coinPool.Count == 0) return; var coin = coinPool.Dequeue(); coin.transform.position = new Vector3(Random.Range(-4f, 4f), 0.5f, 3f); coin.SetActive(true); } }注意Mathf.Min(Time.deltaTime, MaxDelta)这一行。很多人省略它，然后在真机上切后台回来发现角色飞出了地图。这行的成本几乎为零，收益是彻底消除这类问题。
4.3 输入适配：编辑器里用鼠标，真机上用触摸
输入适配层的目标只有一个：让业务逻辑不关心当前是什么设备。它对外暴露的接口应该只有「有没有发生一次点击、点在哪里」：
using UnityEngine; public static class InputAdapter { public static bool TryGetTap(out Vector2 screenPos) { #if UNITY_EDITOR if (Input.GetMouseButtonDown(0)) { screenPos = Input.mousePosition; return true; } #endif if (Input.touchCount > 0) { var t = Input.GetTouch(0); if (t.phase == TouchPhase.Began) { screenPos = t.position; return true; } } screenPos = default; return false; } }业务侧拿到屏幕坐标后，通过相机转成世界坐标，或者直接判断点击在屏幕的左半区还是右半区。我建议第一次做交互判定时用屏幕分区，而不是精确的物理射线，因为射线检测在不同分辨率下容易出边界问题，而屏幕分区永远稳定。
4.4 HUD 与安全区：别让按钮藏进刘海下面
UI 这一块新手最容易忽略安全区。做法是在 Canvas 下挂一个 RectTransform 作为安全容器，启动时根据平台返回的安全区信息设置锚点和偏移：
void ApplySafeArea() { // safeArea 由 PlatformBridge 从平台侧取回，值为屏幕比例 Rect safe = PlatformBridge.GetSafeArea(); var canvasRect = rootCanvas.GetComponent<RectTransform>().rect; var anchorMin = new Vector2(safe.xMin, safe.yMin); var anchorMax = new Vector2(safe.xMax, safe.yMax); safeRoot.anchorMin = anchorMin; safeRoot.anchorMax = anchorMax; safeRoot.offsetMin = Vector2.zero; safeRoot.offsetMax = Vector2.zero; }所有需要用户点到的按钮，全部放进这个安全容器里；纯装饰的背景图可以放在容器外面铺满。这条规则能让你的界面在所有机型上都不会出现「关键按钮点不到」。
4.5 给第一个版本定一份帧预算
预算这件事越早做越好，哪怕只是写在纸上。我的经验分配如下（以 60 帧为目标，单帧 16.6ms）：
| 模块 | 预算 | 说明 |
|---|---|---|
| 逻辑更新 | 3ms | 包括输入、状态机、对象池调度 |
| 物理与碰撞 | 2ms | 能用简单距离判定就别上物理引擎 |
| UI 重建 | 2ms | 避免每帧改文本，批量更新 |
| 渲染提交 | 7ms | drawcall 控制在 60 以内比较安全 |
| 余量 | 2.6ms | 留给系统波动和 GC |
这份表在实际开发中的用途是「吵架有依据」——当有人提出要加一个全屏后处理时，你把表拍出来，大家就知道要砍掉什么。
5. 导出、分包与真机验证：包体掉下来的地方全在细节里
这是整个流程里最容易被低估的阶段。很多项目在编辑器里跑得很顺，一进真机就原形毕露，而真机问题往往不能靠猜，必须有系统性的验证方法。
5.1 首包瘦身的六个动作
| 动作 | 预期收益 | 代价与注意 |
|---|---|---|
| 提高代码剥离级别 | wasm 减少数百 KB | 反射调用可能失败，需要做一轮完整的冒烟测试 |
| 关闭开发构建与调试符号 | 包体减少 30% 以上 | 无法远程调试，只能在导出前临时打开 |
| 纹理改压缩格式并限制尺寸 | 资源体积减少 50% 到 70% | 画质下降，需要按视觉重要性分档 |
| 音频统一转成压缩格式 | 音频体积减少 60% 左右 | 短音效有解码延迟，交互音效保留未压缩 |
| 未使用资源手动剔除 | 视项目而定，可能很可观 | 需要定期清理，建议写个构建前检查脚本 |
| 首屏资源移入分包 | 主包直接瘦身 | 需要设计好加载时序和失败重试 |
这六个动作里，收益最大也最容易被忽略的是最后一条。很多人的首包体积其实不是被大资源撑爆的，而是把整个游戏所有关卡的资源都塞进了主包。主包里只留启动场景真正需要的东西，这条原则能解决一半以上的包体问题。
5.2 分包加载的完整实现
分包的配置写在game.json里，加载逻辑通过 JavaScript 胶水转到 C#：
// subpackage.jslib mergeInto(LibraryManager.library, { WX_LoadSubpackage: function (namePtr, callbackObjPtr, methodPtr) { var name = UTF8ToString(namePtr); var cbObj = UTF8ToString(callbackObjPtr); var method = UTF8ToString(methodPtr); wx.loadSubpackage({ name: name, success: function () { SendMessage(cbObj, method, 'ok'); }, fail: function (err) { SendMessage(cbObj, method, 'fail:' + (err && err.errMsg)); } }); } });C# 侧收到回调后，根据返回值决定是继续进入关卡还是弹出重试按钮。这里有三个必须处理的点：
- 失败重试：弱网环境下分包加载失败是常态，至少要给三次重试机会，并且每次重试前给用户明确提示；
- 并发控制：不要同时发起多个分包加载，容易造成网络竞争反而更慢，串行加载加进度条是更稳妥的选择；
- 加载中不可交互：加载期间必须屏蔽输入，否则用户会重复点击导致状态错乱。
注意：分包数量不是越多越好。每个分包在加载时都有固定的建立连接开销，分得太碎会让总的加载时间变长。我一般的做法是按关卡或按功能模块划分，单个分包控制在几百 KB 到两 MB 之间。
5.3 真机上的性能剖析流程
编辑器里的性能数据只能作参考，真正的结论必须来自真机。我通常按这个顺序走：
- 先在真机上看帧率曲线，判断问题类型。是全程低还是间歇性掉帧？全程低多半是渲染或逻辑本身太重，间歇性掉帧基本是 GC 或资源加载；
- 间歇性掉帧就抓内存曲线。如果内存呈锯齿状上升然后回落，说明有频繁分配；这时候回头查业务代码里有没有每帧 new 对象、字符串拼接、LINQ；
- 全程低就先砍 drawcall。把静态合批打开、材质数量减少、UI 图集合并，这三招往往能立竿见影；
- 最后再考虑动态分辨率和降级。这是最后的手段，不是第一选择，因为画质下降用户是能直接感知的。
我在一个项目里遇到过典型的间歇性卡顿：每隔四五秒卡一次，帧率从 60 掉到 30 再回来。查了两天没找到原因，最后发现是某个飘字组件每次显示都新建一个字符串拼数字，一秒几十次，触发了频繁的分配和回收。改成预生成数字图集之后问题直接消失。这类问题只能靠数据定位，猜是猜不出来的。
6. 上线前那两天：清单和几个反复出现的坑
到了这个阶段，功能基本成型，剩下的时间应该全部投入到稳定性验证上。我整理了一份自己每次都会过一遍的清单：
| 检查项 | 验证方法 | 常见失败表现 |
|---|---|---|
| 冷启动到可交互的耗时 | 真机杀进程后重新进入，掐表 | 超过五秒用户大概率流失 |
| 切后台再回来的状态 | 切出十秒以上再切回 | 音频消失、计时错乱、输入失灵 |
| 弱网下的加载流程 | 开发者工具模拟弱网 | 卡在进度条、无重试入口 |
| 存储容量边界 | 反复写入直到超过上限 | 抛异常导致流程中断 |
| 首次进入的新手引导 | 清除缓存后重新进入 | 引导状态被旧存档覆盖 |
| 低端机降级 | 找一台几年前的低端设备实测 | 帧率低于 30，操作延迟明显 |
最后分享几个反复出现的坑，都是我或者同行真实遇到过的：
第一个是前后台切换后的输入失灵。原因是切回来之后触摸状态没有正确重置，适配层认为还有一个手指按在屏幕上。处理办法是在应用恢复时主动调用一次输入重置，Starter Kit 里的 InputAdapter 一般已经处理了，但如果自己新加了输入通道，记得同步加上。
第二个是分包加载失败后的死循环。表现是用户重试三次之后仍然卡住，且再也无法进入。原因是失败回调里把加载状态标记成了「已完成」，导致后续的重试请求被直接忽略。这类状态机问题建议用显式的枚举加一个超时兜底，而不是用布尔值。
第三个是存储写入的时机。很多人习惯在切后台时保存进度，但切后台时系统给的时间窗口很有限，大对象的序列化可能来不及完成。我的做法是双保险：关键节点立刻同步保存一次，切后台时再异步补一次，宁可多写不能漏写。
我自己在做第一个小游戏时，最大的体会是：真正花时间的不是玩法本身，而是这些边界情况的处理。玩法可能三天就写完了，剩下的两周全在填坑。所以如果你现在正准备动手，我的建议是先把 Starter Kit 的启动流程、音频、存储和分包这四块彻底跑通，哪怕用一个纯色方块当角色，先把链路验证到底。链路稳了，后面加什么都是往上堆，而不是在流沙上盖房子。
