一个小游戏多大才算太大？
没有魔法数字，谁给你一个，谁就是把经验法则当成了定律。但大小确实有可度量的代价，而且对小游戏来说，它比原生应用咬得更狠——因为玩家常常是在别人的运行时里、用中端手机、在摇摇晃晃的网络上按需拉取你的包。下面讲怎么思考这个预算，而不是瞎猜。
Q：为什么包体大小对小游戏的惩罚比原生应用更狠？
原生应用只下载一次，被系统缓存，还被平台预热。小游戏往往跑在宿主应用的 WebView 或运行时里，而那个运行时自己就有内存和启动预算，你的包是玩家点击时才拉取的——不是几天前装好的。所以你的冷启动是下载 + 解析 + 首帧绘制，每一兆都是玩家盯着转圈圈的时间。在新兴市场的一台中端安卓机上，3MB 和 10MB 的初始包，就是"等得住的玩家"和"首帧前就跳走"的玩家之间的差距。原生应用把这笔成本摊薄了；你每次会话都在吃它。
Q：到底预算是多少，又该怎么量？
别争兆数，去量玩家真正感受到的：可交互时间，在节流后的真实档位上量，不是你连着 wifi 的开发机。一个有用的目标是首玩可交互包体压在 4MB 以内，其余的流式加载。然后按玩家真实的体验去测——4G 节流、中端设备、清掉缓存——用 Lighthouse、WebPageTest 或平台自带的 trace 工具。坑在于：你优化了下载体积，却让一个巨大的 JS 文件在主线程解析上卡住——小一点但画得慢的文件，比大一点但画得快的文件更糟。体积只是代理，可交互才是真相。
Q：重量到底从哪来？
三个嫌疑，第三个最容易被漏掉。第一，引擎和运行时开销——你选的框架有个地板，有些比别的重。第二，资源膨胀：没压缩的音频、给 2D 拼图用的 4K 贴图、没人裁过的精灵表。第三，也是最沉默的杀手：第三方 SDK。分析、广告、登录、崩溃上报——每一个都悄悄加 0.5–2MB，还在启动时多一次网络往返。团队纠结自己那 200KB 的代码，却无视六个 SDK 拉走的 4MB。审计依赖树，给每个 SDK 贴上"承重"或"装饰"的标签；大多数是装饰，而它们全都在抽首帧的税。
Q：不重写游戏怎么瘦下来？
你很少需要重写。流式加载资源、懒加载：别在第一天就发出第 50 关的贴图，等玩家到了再取。音频压成现代编码，贴图做图集，把 SDK 的初始化挪到首帧之后而不是之前。一开始就选体积小巧的运行时或引擎——这是个做一次、项目全程都得背的决定。要大声说出的权衡是：激进的代码分割能减小初始体积，却会在后续加载上加一点延迟，所以你是在拿"立即首帧"换"总体积小"。两者都量，别想当然地以为分割就有用。
| 杠杆 | 对冷启动的影响 | 工作量 | 忽视的风险 |
|---|---|---|---|
| 初始包 < 4MB | 高 | 中 | 首帧前跳走 |
| 资源流式 / 懒加载 | 高 | 中 | 发出当下用不到的重量 |
| SDK 审计 + 首帧后初始化 | 极高 | 低 | 沉默的 4MB 税 |
| 引擎 / 运行时选型 | 高 | 高（早期） | 锁死的地板 |
