把游戏包控制在 10 MB 以内

2026年8月28日 · 阅读约 3 分钟

大多数有人工审核的网页游戏门户，会把上传大小限制在 5 MB 到 20 MB 之间，其中好几家对超线的包直接拒绝，看都不多看一眼。原因不在存储。门户要把游戏送到一台用移动数据的手机上，首次加载慢，就意味着玩家在游戏开始之前就走了。体积上限其实是「这个游戏打不打得开」的替代指标。

我们九款原创游戏的大小从 63 KB 到 2.49 MB 不等。下面按重要程度排序，说说体积到底在哪儿。

1. 未压缩的美术资源

问题几乎总是出在这里。一个直接从绘图软件导出的 PNG 文件夹，是游戏包里最大的一项，比别的高出一个数量级。

我们的同步脚本把源美术资源重新编码成 WebP 之后，其中一款游戏的美术文件夹从大约 25 MB 的 PNG 变成了 1.4 MB。像素没变，游戏画面肉眼看不出任何区别。如今所有重要的平台都支持 WebP，而对游戏美术（纯色、硬边、渐变少）来说，它几乎是免费的。

如果你只做一件事，就做这件。

通用引擎会附带物理求解器、粒子系统、Spine 动画运行时、瓦片地图加载器，以及十几个别的子系统，不管你的游戏用不用得到。Tree-shaking 的帮助比你期望的要小，因为很多部分在内部是连在一起的。

我们三款 Phaser 游戏分别是 1.33、2.09 和 2.49 MB。六款不用引擎的游戏是 63 KB 到 390 KB。这个差距几乎全部来自引擎。这笔交易可能是划算的（见那篇关于不用引擎开发的文章），但你应该清楚自己在付这笔钱。

未压缩的 WAV 循环很重。把音乐转成低码率格式，音效尽量短。一分钟的环境音循环，没有理由比游戏其余部分加起来还大。

代码几乎从来不是问题。一整个游戏的逻辑压缩后也就几十 KB。如果你在靠压缩 JavaScript 来达到体积要求，那你优化错文件了。

把四十张小图打包进一张图集，四十个 HTTP 请求就变成了一个，引擎也只需要往 GPU 上传一张纹理，而不是几十张。代价是多一个构建步骤和一点工具链。只要精灵图超过寥寥几张，就值得做；少于这个数，就只是走形式。

不要为了凑一个数字去砍功能。体积上限约束的是交付，不是内容范围。如果游戏有 12 MB 而上限是 10，答案就在上面的第 1 到第 3 条里，永远不会是「把第三个世界砍掉」。玩家没有要求更小的游戏，要求更快的是门户。

构建游戏，打开输出目录，按大小排序。只要你真的去看，罪魁祸首总是一目了然，而且几乎从来不在你以为的地方。我们把每款游戏的数据都公开在授权页面上，正是出于这个原因：一个能核对的数字，胜过一个随手敲上去的数字。