一个让人抓狂的日常你改了一行 C# 代码点下 Build然后……去泡了杯咖啡。回来发现还在转。或者更糟你只是想出个测试包给策划看看结果构建跑了二十分钟中间还卡在一个叫 “IL2CPP” 的阶段一动不动。Unity 慢几乎是每个用过它的人的共识。但慢是个太笼统的词。它到底慢在哪一步是编译代码慢还是处理美术资源慢还是最后打包慢搞不清这个你就只能干等着或者盲目地去网上抄一堆优化设置碰运气。这篇我们把 Unity 的构建流程拆开一段一段看清楚——每一段在干什么、为什么慢、慢的是首次还是每次。看完你至少能判断我这次卡住的进度条到底卡在哪个环节。先建立一张地图Unity 构建的完整流水线跟 Gradle 一样Unity 的出包也不是一个动作而是一整条流水线。先把全貌摆出来后面逐段讲① 资源导入Asset Import 把 png/fbx/wav 等源文件 → 转成 Unity 内部格式 ↓ ② 脚本编译Script Compilation 把你的 C# 代码 → 编译成 .NET 程序集DLL ↓ ③ 资源处理与序列化 收集场景、预制体、依赖序列化成运行时格式 ↓ ④ IL2CPP 转换仅当使用 IL2CPP 后端 把 .NET 的 IL 中间码 → 转成 C 源码 ↓ ⑤ 原生编译与链接Native Compile Link 把生成的 C → 用平台编译器编译成机器码 ↓ ⑥ 着色器编译Shader Compilation 编译所有用到的 shader 变体 ↓ ⑦ 打包Packaging 资源 代码 引擎 → 打成 APK/IPA/exe 等慢就分布在这七段里。而且每一段慢的性质不一样——有的只慢第一次有的每次都慢有的只在出正式包时才拖你后腿。这个区分是你诊断问题的关键。第一大慢点资源导入——只慢第一次但第一次能要命先说 ① 资源导入。Unity 里你放进项目的 png、fbx、wav、psd 这些源文件引擎其实不认。它需要把每个源文件转换成自己的内部格式压缩纹理、网格数据等这个过程叫Import导入。转换的结果全部缓存在项目的Library/文件夹里。这里的关键规律是资源导入是首次很慢之后基本免费。第一次打开项目 / 删了 Library / 换了台机器 → 所有资源从零导入几千张贴图、几百个模型一个个转 → 可能要等十几分钟甚至几小时大项目 ↓ 之后 → 导入结果都在 Library 缓存里 → 只有你改动过的资源才重新导入 → 日常几乎感觉不到所以那些新人 clone 完项目打开 Unity 卡了半小时的经典场景慢的就是这一步。它不是构建本身慢是首次资源导入慢。几个和它相关的实战点千万别把Library/提交到 Git。它是缓存能重新生成而且巨大。但——可以用 Unity Accelerator 或 Cache Server 共享导入缓存。团队里一个人导入过其他人直接下载结果不用各自重导。这是大团队治首次导入慢的标准方案。贴图压缩格式选错会加剧这步的慢。尤其是移动端的 ASTC 压缩本身就耗时几千张图叠起来很可观。第二大慢点脚本编译与域重载——日常最烦人的那个卡顿② 脚本编译是你日常开发中感受最频繁的慢。你改一行 C#Unity 就得重新编译。但真正让你难受的往往不是编译本身而是编译后紧跟着的一个动作——域重载Domain Reload。简单说Unity 编译完代码后需要把整个脚本运行环境卸载再重新加载一遍好让新代码生效。这个卸了重装的过程项目越大越慢因为要重新初始化的东西越多。你改一行代码按 CtrlS ↓ Unity 重新编译改动涉及的程序集 ↓ 域重载卸载旧的脚本域 → 重新加载 → 重新初始化所有静态状态 ↓ ← 你就卡在这里编辑器转圈几秒到几十秒 终于可以继续操作 / 进入 Play 模式这一步的性质是每次改代码都慢是最消磨心力的那种慢。治它的方向把代码拆成多个程序集Assembly Definitionasmdef。Unity 只重编改动所在的那个程序集而不是把你所有代码全编一遍。这是缩短编译时间最有效的手段。别把几千个脚本堆在一个默认程序集里。开启 “Enter Play Mode Options”关掉 Domain Reload。新版 Unity 允许进入 Play 模式时跳过域重载能极大加快改代码→测试的循环。代价是你得自己处理静态变量的重置但收益巨大。第三大慢点IL2CPP 原生编译——出包慢的头号元凶现在到了重头戏。你出正式包尤其移动端时那漫长的等待绝大部分是它俩造成的——④ IL2CPP 转换 和 ⑤ 原生编译。先解释 IL2CPP 是什么。Unity 的 C# 代码平时是编译成IL中间语言由虚拟机运行的。但为了性能和平台限制比如 iOS 根本不允许 JITUnity 提供了一个后端叫IL2CPP它会你的 C# 代码 → 先编成 IL 中间码 ↓ IL2CPP 登场 IL 中间码 → 翻译成等价的 C 源代码 ④生成海量 .cpp 文件 ↓ C 源代码 → 用平台原生编译器编译成机器码 ⑤ ↓ 链接成最终的原生库问题就在这它相当于把你的整个游戏、加上 Unity 引擎的一大堆代码全部翻译成 C然后从头编译一遍 C。C 编译本来就慢而这里的 C 是机器生成的、量极其庞大。这就是为什么 Release 包比 Debug/Editor 慢一个数量级——Editor 下用的是快速的 Mono 后端不走 IL2CPP 这条重路。Mono 后端Editor / 开发包 C# → IL → 直接跑 ← 快改完马上能测 IL2CPP 后端正式 Release 包 C# → IL → C → 编译 → 链接 ← 慢每次出包都要走一遍这一步的性质是出正式包时必慢且往往是全流程最慢的一段。能做的优化有限但有方向开发阶段尽量用 Mono 后端 快速测试别动不动出 IL2CPP 包。只在真正需要真机验证性能或发布时才走 IL2CPP。开启增量 IL2CPP 构建。新版 Unity 支持只重新处理改动的部分而不是每次全量翻译编译。这能显著缩短第二次之后的 IL2CPP 构建时间。代码裁剪Managed Stripping是把双刃剑。它删掉没用到的代码减少 C 生成量、加快编译但设太激进会误删反射用到的代码导致运行时崩溃。需要配合 link.xml 权衡。减少代码体量、少用泛型爆炸。大量泛型实例化会让 IL2CPP 生成成倍的 C 代码直接拖慢编译。第四大慢点着色器编译——一个容易被忽视的隐形杀手⑥ 着色器Shader编译是很多人没意识到、却真实存在的一大慢点。问题的根源是着色器变体Shader Variants。一个 shader 不是只编译一次——它会根据不同的关键字组合有没有雾、几盏灯、什么光照模式……编译出大量的变体。变体数量是各个开关的乘法组合很容易爆炸到成千上万个。一个 shader 有 5 个开关每个开关 2 种状态 2 × 2 × 2 × 2 × 2 32 个变体每个都要单独编译 开关更多、再叠加多平台 变体数轻松破万 → 编译时间以分钟计这一步的性质是出包时慢且随项目 shader 复杂度增长而急剧恶化。而且它经常藏在 IL2CPP 之后让你以为是别的环节慢。治它的方向裁剪无用的着色器变体。用 Shader Variant Collection 只保留实际用到的组合别让引擎把所有理论组合都编译出来。利用着色器缓存。编译过的变体会缓存同样受益于 Cache Server / Accelerator 共享。把七段的慢的性质汇总成一张表这张表是这篇的精华——它帮你在等进度条时快速定位环节 慢在何时 主要诱因 首要优化手段 ───────────────────────────────────────────────────────────────────── ① 资源导入 只慢首次 资源多/压缩重 Cache Server 共享 ② 脚本编译域重载 每次改代码 代码堆一个程序集 拆 asmdef、关域重载 ③ 资源序列化 出包时 场景/依赖庞大 减少冗余引用 ④ IL2CPP 转换 出正式包 代码量大/泛型爆炸 增量构建、代码裁剪 ⑤ 原生编译链接 出正式包 C 量巨大 增量构建、开发用Mono ⑥ 着色器编译 出包时 变体组合爆炸 裁剪变体、缓存 ⑦ 打包 出包时 资源体积大 资源压缩、分包读这张表的方法先问自己我这次是日常改代码卡还是出包卡日常改代码卡→ 几乎一定是 ②脚本编译域重载去拆程序集、关域重载出正式包卡了很久→ 大概率是 ④⑤IL2CPP 原生编译或 ⑥着色器开增量构建、裁变体新机器/新 clone 第一次巨慢→ 是 ①资源导入上 Cache Server。一个统一的认知Unity 慢本质是全量 vs 增量的问题拆到这里你会发现一条贯穿所有环节的主线和上一篇讲 Gradle 增量构建时其实是同一个道理Unity 每一个慢环节慢的根源几乎都是该增量的时候做了全量。资源导入首次是全量没缓存之后是增量只导改动的脚本编译不拆程序集就是全量重编拆了就是增量IL2CPP不开增量就每次全量翻译编译开了就只处理改动着色器不裁变体就全量编译所有组合裁了就只编用到的。所以优化 Unity 构建速度方法论其实高度统一想尽办法让每一步只处理变化的部分别每次都从零来过。缓存Library、Cache Server、着色器缓存解决跨次复用增量构建asmdef、增量 IL2CPP解决单次少做两者配合就是治慢的总纲。结语回到最初的问题——Unity 构建到底慢在哪答案不是某一个点而是分布在七段流水线里且各有各的脾气首次打开慢慢在资源导入缓存能救日常改代码卡卡在脚本编译和域重载拆程序集、关域重载能救出正式包漫长等待主要是IL2CPP 原生 C 编译这条重路外加着色器变体爆炸增量构建和变体裁剪能救。下次再对着转圈的进度条别再笼统地骂Unity 真慢了。先看一眼它卡在哪个阶段的提示文字对照上面那张表——你就能知道这次拖住你的到底是哪一环以及该往哪个方向下手。看懂流水线的每一段慢就从一团模糊的怨气变成了一个可以定位、可以拆解、可以逐个击破的具体问题。这才是从等构建到治构建的分水岭。