为什么 Unity WebGL 的 Wasm 化是第一块基石

我先说个可能让部分同行不爱听的话：大多数人学 WebAssembly 游戏开发，路径是反的。他们先抱着 Rust 教程，加上 wasm-pack，跑一个“Hello, Canvas”出来，然后就觉得懂了。结果一进真实项目——客户要一个能在浏览器里跑、能上 itch.io 的完整版本——现场两眼一抹黑。因为真实世界里跑在浏览器上的商业游戏，八九成是 Unity WebGL 出品，而不是某个手搓的 Rust demo。

这就是为什么这一篇是整座塔的基石。Unity 是目前把“一个现代通用游戏引擎”整块搬进浏览器的最大规模实践，没有之一。你要理解 WebAssembly 在真实游戏里到底能干什么、不能干什么、卡在哪里，最有效的方法不是读规范，是拆开 Unity 的构建产物看一眼。

这一篇要回答四个问题，一个扣一个：

Unity 从 asm.js 时代切换到 Wasm 之后到底改了什么？
一次 WebGL 构建出来那堆 .wasm、.data、.framework.js 到底是什么？
玩家从点击到首帧，时间是被谁吃掉的？
为什么有些 Unity 游戏“能跑 3 分钟然后原地崩溃”？

这四个问题串起来，就是 WebAssembly 游戏化落地最典型的一条线。后面讲包体优化、多线程、调试、性能极限，所有语汇都从这里挂上去。你先把这一层摸熟了，后面写别的语言的路子会踏实很多。

第 1 层：asm.js 到 Wasm——Unity 引擎里的真实换血

先讲个很多人不知道的冷知识：Unity 其实是 asm.js 时代最猛烈的推手之一。2014 年 Mozilla 拿《虚幻 3》跑在浏览器里做演示，一时间科技媒体炸锅。但真正让开发者能在浏览器里跑完整游戏的，是 Unity 5.3 在 2015 年放出来的 WebGL 导出实验版。当时的宣传语非常生猛：你现有的 Unity 项目，配上 WebGL 后端，能在浏览器里跑。后面一地鸡毛就不提了。

关键时间点要分清：

Unity 5.3（2015 年末）到 Unity 5.5 是 asm.js 时代。Unity 5.6（2017 年）开始切换 WebAssembly，Unity 2018.x 之后 Wasm 成为主路径，到 Unity 2021 LTS 之后 asm.js 基本退出舞台。所以“Unity 迁移到 Wasm”不是一次发布会，是横跨两三年、伴随大量兼容补丁的一场阵痛。

asm.js 的毛病，到底是什么毛病

asm.js 不是新语言，是一段“看起来像 JavaScript 但只用了能被预编译的语法子集”的代码。它靠大量整数标注（例如某个值后面挂个 按位或 0 的写法，告诉引擎“这玩意儿是 32 位整数”）让浏览器跳过普通 JS 的动态优化，直接编成高效机器码。听起来很聪明，但有两个致命的物理限制。

第一，它还是 JS。浏览器得先把这一整坨文本解析成语法树，这一步的开销省不掉。一个 20MB 的 asm.js 文件，光是 parse 就能吃掉好几秒——还没轮到编译。你去看当年 Unity WebGL 的加载体验，进度条卡在“Compiling”那一格要等半天的，多半就拜这坨文本解析所赐。

第二，它是个作弊式的方言。所有 asm.js 的“优化承诺”都建立在不破坏 JS 语义的前提下，所以引擎对它有特殊优化、也有特殊限制。一旦某个地方标注错了，性能就断崖式跌——而且极难定位。

换成 Wasm 之后，Unity 拿到了什么

Wasm 是字节码，天生为编译成机器码设计。对 Unity 来说最大的好处有三个：

体积掉了一大截。同一个游戏，asm.js 版本和 Wasm 版本经常差 30%-50% 的传输体积。对“游戏能不能在 3 秒内加载完”这种生死线来说，这是决定性的。

解析时间几乎清零。Wasm 是二进制，浏览器只需要按索引验证一下结构就能进编译，不需要文本解析那套流水线。加载时间立刻少掉一截——Unity 官方当年宣传 WebGL 加载提速，Wasm 是头号功臣。

编译可以分两步走。Wasm 支持“基线编译快速启动”和“优化编译后台进行”并存。这意味着 Unity 可以让玩家在低优化版本上先玩起来，性能在后面几分钟里渐渐追上去。这是 asm.js 做不到的体验。

但 Unity 的腾挪空间有限，它拿到的好处和一个小型 Emscripten 项目拿到的好处完全不是一回事。因为 Unity 的整个引擎——渲染、物理、音频、动画、Asset 系统、il2cpp 生成的 C++ 脚本——全都得打包进一个 wasm 里。它不是往 wasm 里塞了一个 demo，它塞了一个引擎。

第 2 层：构建产物解剖——你的游戏被打包成了什么

先看现场。一次 Unity WebGL 构建出来的目录，长这样：

这里有个细节特别值得掰开讲：Unity 的 wasm 里同时装着引擎和你的游戏逻辑。

这件事听上去平淡，但它决定了很多后续体验。你写的一份敌人 AI 脚本，编译时会被 il2cpp 转成 C++，然后和引擎的渲染管线、物理求解器混在一起，编进同一个 wasm 模块里。这跟“纯 Emscripten 项目”完全是两种基因——后者通常只有一个薄薄的游戏层，wasm 可能 500KB 就搞定。Unity 的 wasm 天生就重，因为它里面躺着一个完整的通用引擎。不是你的游戏写得臃肿，是引擎跟着你一起过年。

这个分离还有一个非常现实的后果：.data 的体积和 .wasm 的体积，是两条寿命不同的曲线。wasm 是代码，版本更新必换；.data 是资产，很多时候改得不多。你如果理解了这一点，就知道“能不能只更新 .data？”这类问题该怎么回答——理论上能，实践上 Unity 官方并不给这种增量方案，你需要自己搓一套资源 CDN 分发的流程。这是很多独立开发者在做“Web 上长线运营”时才踩到的一颗地雷。

我见过一个真实场景：某三消类 Unity 项目上 Web 之后，前半年 .wasm 是 28MB、.data 是 12MB，加载体验勉强撑住；到了第二年玩法扩展后 wasm 涨到了 41MB，加载时间开始被用户骂。团队想了个“聪明”的主意：把玩法单独切割成一个可热更需要的小 wasm 模块。结果工程量炸了，因为 Unity 的 il2cpp 不支持这种细粒度拆分，最后只能回滚。Unity 的构建产物是一个整体打包体，这句话你越早接受越好。

第 3 层：加载分阶段——从点击到首帧，时间被谁吃掉了

这是最容易被低估、也最直接影响玩家留存的一层。很多人以为 Unity WebGL 慢在“跑起来之后”，其实真正把玩家赶走的是开头那 20 秒。加载阶段是 Unity WebGL 玩家流失的最大悬崖。

把它拆成六个阶段，每一段都有独立病因：

看到问题没有？第 2 阶段的耗时直接决定生死。业内有一个粗估的经验线：首帧到达时间超过 15 秒，你就要开始跟玩家流失抢人；超过 30 秒，你可以当它没上过线。在 10Mbps 这种“国内勉强”“欧美中等”的网速下，20MB 包要 16 秒，40MB 包要 32 秒，80MB 包就直接 64 秒了。

这解释了为什么 Unity WebGL 上的游戏有一个奇特的规律：能跑在 Web 上、又活得还不错的 Unity 游戏，往往包体被压到非常激进。不是因为开发者爱折腾，是活下来的那一批都被这个悬崖教育过。

有一个真实的翻车：我见过某团队用一套美术资源很重的 Unity 项目做 Web 版，测试环境里跑得很开心——服务器本地、千兆内网。上线之后第一周平均只玩 40 秒就跑。后来查日志才发现，高比例用户是在加载阶段掉的，其中将近一半卡在“wasm 编译”这一步。他们之前的测试从没有区分过下载耗时和编译耗时，误把“编译慢”认成了“下载慢”，优化方向整个错位。加载阶段的计时必须分段打点，笼统说一句“加载慢”等于没有诊断。

第 6 阶段，是个被忽略的大坑

首帧渲染慢这件事，Unity 用户抱怨了快十年。原因挺复杂：Unity 进了主循环之后，会一次性把初始场景的贴图、材质、shader 全部上传 GPU，还要初始化各种管线。WebGL 层的 GPU 上传比原生慢不少，因为它受浏览器沙箱和上下文创建的限制。进入主循环之后，第一帧通常是个“黑屏或者一个僵硬的贴图”，玩家体验被割裂。

缓解办法有，但都不彻底：把初始场景拆得更小（把登录场景、初始关卡、其他关卡分开加载）、在加载条里展示封面待机动画、把主菜单做成一个独立的极轻量场景预加载。这些都是“Unity 开发者对付首帧”的传统艺能，你在 itch.io 上玩到体验还算顺的 Unity 网页游戏，多半吃过这几颗药。

第 4 层：内存与运行时——为什么“能跑 5 分钟然后崩”是常态

前面讲的是“进不去”，这一层讲的是“进去了活不久”。这是 Unity WebGL 最富盛名的疑难杂症，也是让一批开发者放弃 Web 端的原因。

把机制讲清楚：Unity 的 wasm 模块会预先申请一大块线性内存。默认 256MB，这个值你在构建设置里能看到（叫 Initial Memory Size）。大多数商用 Unity 项目在原生端随便吃 1-2GB 内存，到 Web 上被卡在 256MB，就好比让一个 300 斤的汉子去做体操——日常动作他能做，一到腾空翻就出事。

这套内存模型的坑分三层：

第一层，浏览器本身的内存限制。桌面 Chrome 一般给你 1-2GB 的 wasm 空间，基本够用。iOS Safari 才是真正的老虎口——老设备给 256MB，新设备最多 1GB，且受系统压力随时可能回收你的标签页。你没看错，是回收标签页。玩家切出去看一眼微信，回来你的游戏就白屏了。这不是你的代码写错了，是 iOS 就是这么干的。我第一次遇到的时候还排查了半天自己的内存泄漏，最后翻出 Safari 官方的文档，才发现这是设计层面的事。

第二层，托管堆的膨胀。Unity 用的是托管内存模型，垃圾回收器会周期性冻结主线程做 GC。原生端 5 毫秒的 GC 你可能感知不到，Web 上因为运行时环境本身也吃 CPU，GC 会放大到 20 甚至 50 毫秒。每 30 秒一次莫名卡顿，玩家感受就是“这游戏不太流畅”——一个很难用语言形容你没做好的问题。

第三层，Unity 自己那套“内存池”吃亏。好多 Unity 游戏在原生端依赖大量的实例化操作，几万个物体同屏出现。这在原生端都还好，到 Web 上，分分钟突破 wasm 内存上限。而且 Unity 在 Web 端的分配策略比原生保守很多，结果是同一个项目在桌面端跑得很欢，Web 端跑 5 分钟直接 crash。

要判断问题在哪一层，一个实用的小办法：让游戏跑起来，用浏览器开发者工具看那根内存曲线。如果曲线是一条“慢慢爬坡然后断崖”，典型是托管堆膨胀；如果是“起步就贴近天花板”，那你初始内存设太大了，得先砍预分配；如果是“横盘然后在某个操作后突然断崖”，那是分配器问题，多半要查你的对象池策略。

配置参数表：Unity WebGL 的七个关键旋钮

知道机制容易，能调对参数不容易。这一张表是我自己累积出来的调参经验，供你参考。注意：没有一套“万能参数”，不同项目侧重的方向不同。下面列的“建议区间”是主流区段，不保证适合你的具体项目，具体还要拿自己的构建试。

再说两句这张表里被误解最多的两项。

Code Optimization 这个开关，是个典型的“反向陷阱”。好多人以为选 Speed 就一定更好。其实 Speed 会让 wasm 变大约 20%-40%，如果你加载时间本来就卡在 20 秒边缘，这一选直接把你送进悬崖。真正该选 Speed 的项目是“加载很快但跑起来帧率低”的——反过来说，你觉得跑得慢，先别急着开 Speed，先排查是哪段代码在慢。渲染慢加 CPU 优化没用。

Managed Stripping Level 是这块土地上最容易翻车的地方。这个参数做的是“把 Unity 引擎运行时用不到的类剪掉”。选 Medium 通常安全，选 High 经常把反射起来的类把刀削掉——你本地测试跑得好好的，某个功能一触发就崩，日志还显示不出来。我个人的原则是：宁可包体大 1MB，也不碰 High。有实际收益，但风险收益比太差。

案例拆解：三个项目，三种姿势

案例一：《Vampire Survivors》——Web 版的性能天花板撞在哪

这个例子最值得细讲，因为它的起家路径和这个主题高度贴合。

《Vampire Survivors》最早由 poncle（Luca Galante）以个人项目在 itch.io 上发布，构建方式就是 Unity WebGL。它恰好是 Unity WebGL 能力边界的一份活教材。玩法核心看起来简单：1 像素风、自动射击、清屏几千个敌人。真实开销惊人——同屏实体数量动不动上几百，每个实体都有移动、碰撞检测、伤害结算、掉落判定。这层逻辑在桌面原生端还能扛，跑到浏览器里就完了。

当年的真实问题不是 wasm 执行慢了。Wasm 这一层的计算性能其实相当可以。问题出在内存和 GC 的组合：几千个 entity 的托管对象频繁分配/释放，GC 压力陡增。玩家玩到第 8 分钟（同屏单位开始爆炸的时候），开始明显掉帧，再往后直接标签页崩溃。这不是 Unity WebGL 不成熟，而是这套架构对“大量短命对象”的天然不适配——浏览器的内存回收机制没给这么高频的 GC 留空间。

开发者后来的选择很有参考价值：它 Web 版的地位从“主战场”降级成了“试玩 demo”，正式版回到原生分发。这个决策对后来的独立开发者非常有启发——Web 是获客漏斗而不是终点。你可以在 Web 上放进一个游戏能玩的版本，让玩家先上手，然后再引导到原生平台。这不是“Web 做不了”，这是“Web 适合做哪一段”。

对于正在看这篇的技术策划，我强烈建议从这个案例里学一个策略：上线前先做“同屏实体爆炸测试”。跑到你游戏最极端的场景，让它连续跑 15 分钟，观察浏览器内存曲线和帧率。这个测试只要 1 小时，能救你上线后三个月的口碑。

案例二：《Superhot》浏览器版——加载体验的极端样本

再举一个和第一款截然相反的例子。《Superhot》的浏览器版本在官网开放过一段时间，它的玩法是“时间静止+射击”，画面是低多边形、低材质，看起来应该很轻。

但你实际玩起来会发现加载极慢。为什么？因为《Superhot》的引擎工程量不小——枪械物理、敌人 AI、关卡加载、动画混合——全部被 il2cpp 塞进 wasm 里，wasm 体积光是代码就大得吓人。它的美术资产被压到极致（大面积白墙、纯色红人），但代码层消化不了压缩。

这个案例给了一个反直觉的结论：Unity WebGL 的加载时间，由“代码体积”主导，不全由“美术体积”主导。很多开发者给美术资产做两轮压缩，结果不理想，因为真正拖时间的是引擎+il2cpp 代码那坨 wasm。对轻资产、重逻辑的游戏类型，这几乎是宿命。

顺便说一句 —— 《Superhot》后来的商业策略和《Vampire Survivors》一样，Web 版是钩子而不是主菜。俩不同品类、不同美术量的游戏，走了同一条路，这不是巧合，是 Unity WebGL 现状的真实剪影。

跨类对照：DOOM 3 WebAssembly 移植——纯 Emscripten 的对照镜像

最后补一个跨类的对照案例，目的不是讲它本身，而是帮你看清 Unity 那条路的特殊性。

社区把 id Software 的《DOOM 3》源码用 Emscripten 编到 WebAssembly，跑得流畅，加载也有声有色。它跟 Unity 路线的本质差异在于：DOOM 3 的移植是“把源代码按最小必要编译成 wasm”，而不是“把一整个通用引擎装进 wasm”。所以它的 wasm 更轻、加载更短、启动时那一堆“引擎初始化”步骤被砍得只剩骨头。

对比下来，Unity WebGL 的先天成本就清楚了：你不是在编译你的游戏，你是在编译“一个能加载你游戏的引擎”。理解这一点，对后面看包体优化、多线程、调试这几篇会非常有帮助——Unity 路线的每一步优化，本质上都是想抵消这个先天成本。

初级用户速览 vs 进阶深入

初级用户速览（如果你正准备把一个 Unity 项目搬上 Web）

四件事按顺序做，能避开 80% 的坑。

一、先在 Unity 官方或者社区里找一个你觉得差不多的 WebGL 项目作参照，确认你的包体在“同行可接受”的量级，再去优化。别凭感觉。

二、把 Brotli 和 Strip Engine Code 这两个开关打开。前者能砍掉 30-50% 传输体积，后者能砍掉 20% 左右的 wasm。这是投入产出比最高的一步。

三、把内存 Size 调到“你的游戏实际峰值 + 30%”。别迷信“越大越好”，也别为了省事沿用 256MB。

四、兼容性测试一定要覆盖 iOS Safari。如果你只在 Chrome 上测，会得到完全错误的结论——Safari 的内存限制和 wasm 实现差异之大，值得单独占一份测试清单。

进阶深入（如果你已经在项目中踩过一轮坑，想真正搞懂）

往这三个方向钻：

一是学 il2cpp 的产物机制。知道你的脚本是怎么一步步变成 wasm 里的指令序列，你才能理解为什么有些语法写法会显著变慢、为什么反射和泛型会拉高包体。这是理解 Unity Web 性能的根目录。

二是摸清托管堆的生命周期。Unity 的 GC 什么时候撞、撞了多久、能不能手动触发、能不能调分配策略——这些问题没有文档能直接给你答案，需要你读社区文章加自己日志实测。但对“能不能稳 60 帧”是决定性的。

三是学 Chrome/Safari DevTools 里针对 wasm 的调试方法。你会看到 wasm 的加载阶段、编译阶段、运行时内存曲线分段显示。这一层学会了，Unity WebGL 从此从黑盒变成灰盒——就像第一次看到自己写的游戏跑在第一人称视角调试工具里那种感觉。

常见坑：五个用血换来的忠告

FAQ：几个被问得最多的问题

Q1：我的 Unity 项目能直接上 Web 吗？

技术上能，实际上要看条件。判断标准有几条：同屏实体数量不要太高（几十到一两百还行，上千就危险）；贴图和音效总量要能压缩到 30MB 以内（否则加载时间过不去）；不能依赖大量反射和动态代码生成（Managed Stripping 会踩到底）。三条都过，可以试；有一条踩线，先做优化再上。

Q2：WebGL 构建 20MB 算正常吗？

在当前生态下，20MB 算“还不错的水平”。30-40MB 开始紧张，50MB 以上要有非常强的用户来源才扛得住。itch.io 上很多成功案例的构建产物都在 10-20MB 区间——看这个数字你能大概体会行业现状。

Q3：为什么 iOS Safari 特别容易崩？

两层原因。一是 iOS 对每个标签页的内存上限放得很紧（跟设备型号相关），超过就被杀；二是 iOS 上 wasm 存在一些原生没完全对齐的行为，某些复杂 wasm 模块在 Safari 上运行时会触发更激进的 GC 或者内存管理。给 iOS 单独准备一个“更保守”的构建（更小内存、更低画质选项）是很常见的操作。

Q4：Unity 2022 LTS 比 2020 到底强在哪？

主要有三块：wasm 编译优化更成熟、构建体积有下降、内存增长策略有改善。但别指望“换个版本就全好了”——项目层面的架构问题（内存、包体、首帧）不会因为升版本自动消失。升级版本是加分项，不是救命稻草。

Q5：什么时候该放弃 Unity，转别的技术栈？

三个信号同时出现就该考虑了：你的游戏类型对同屏实体数量有天然需求（子弹地狱、RTS），并且你已经试过两轮优化都打不进可接受的体验区间，同时这个 Web 版本对你来说是战略级而不是试玩级。满足这三条，考虑用 Rust 或手写 Emscripten 路线重建——成本高，但天花板也高。如果只是想做试玩 demo 获客，别费这劲儿，Unity 够用。

留一个问题给你

写到这里，我特别想抛一个我自己都没完全想通透的问题给你——

如果 WebAssembly 的游戏生态最终成熟到“原生的体验、浏览器的分发”这个程度，那 Unity 这种“把整个引擎塞进 wasm”的路线，到底是正确的铺路，还是一种过渡性的历史产物？

支持者会说：引擎即资产，开发者生态即护城河，Unity 路线让千万独立开发者能用最低成本上 Web。反对者会说：每个游戏都背着一个几十 MB 的通用引擎跑在浏览器里，这本身就是一种资源浪费——未来应该有更“薄”的引擎范式专门为 Wasm 设计。

我没有答案。但我知道，无论哪边赢了，能读懂一个 Unity WebGL 构建产物里到底装了什么的开发者，都会有饭吃。因为下一步无论走向哪里，你摸过的每一层机制都不会背叛你。

下一篇，咱们从 Unity 这条“引擎路线”跳到“手搓路线”，去看看 Emscripten 是怎么把 C/C++ 游戏引擎一步步搬进浏览器的——那是另一条完全不同的路，但殊途同归。See you there。