378 lines
16 KiB
Markdown
378 lines
16 KiB
Markdown
---
|
||
title: Unity 热更新的隐形命门：一篇讲透"确定性构建管线" - 知乎
|
||
source: https://zhuanlan.zhihu.com/p/2028488903561163102
|
||
created: 2026-05-09 15:35
|
||
tags: [zhihu, article, unity, assetbundle, deterministic-build]
|
||
---
|
||
|
||
# Unity 热更新的隐形命门：一篇讲透"确定性构建管线" - 知乎
|
||
|
||
**来源:** [https://zhuanlan.zhihu.com/p/2028488903561163102](https://zhuanlan.zhihu.com/p/2028488903561163102)
|
||
|
||
---
|
||
|
||
写在前面
|
||
|
||
文章是由AI生成的，最开始是为了当个人笔记，让AI补全一下相关内容
|
||
|
||
核心观点是确定性构建管线，这个在6000.x的官方文档里已经有明确说明
|
||
|
||
Deterministic builds
|
||
|
||
如发现错误，以官方文档为准
|
||
|
||
起因：看到 Unity Partner Engineer 发的一篇帖子 Understanding Old Dependency Reuse in Unity AssetBundles，通篇在反复强调一个短语——deterministic pipeline。这个概念在中文社区里几乎没人讲透，但它恰恰是 AssetBundle 热更新体系的根基。本文尝试把它讲清楚。
|
||
一、一个看似简单的问题，藏着一个深坑
|
||
|
||
先抛一个场景给你，你试着回答一下：
|
||
|
||
线上已经下发了 Bundle A 给玩家。现在你新打了一个 Bundle B，B 依赖 A。你想让玩家继续用本地那个旧的 A，不要重新下载，可以吗？
|
||
|
||
凭直觉回答，多数人会说”当然可以，A 没改嘛”。
|
||
|
||
但真相是：在”确定性构建管线”下可以，在”非确定性构建管线”下不行。
|
||
|
||
Unity 官方的说法原话是：
|
||
|
||
It might work, but do not rely on it. （可能能用，但别指望它。）
|
||
|
||
这个”能不能依赖”的分界线，就是Deterministic Build Pipeline。
|
||
|
||
二、到底什么是”确定性构建”？
|
||
|
||
一句话定义：
|
||
|
||
给定完全相同的输入（资源 + 代码 + 配置 + 工具链 + 环境），无论构建多少次、在哪台机器、谁来构建，输出的二进制文件字节级完全一致。
|
||
|
||
写成公式：
|
||
|
||
same input + same pipeline = same output (byte-identical)
|
||
|
||
初学者常常会有这样一种错觉：
|
||
|
||
“我重新打了一次包，文件哈希没变，那我的管线肯定是确定性的。”
|
||
|
||
这个理解方向对，但不够精准。我们需要区分两个概念：
|
||
|
||
概念 性质 描述
|
||
“输出未变” 结果现象 两次构建 AB 的 MD5/SHA 相同
|
||
“确定性管线” 管线属性 只要输入不变，就必然输出不变的能力
|
||
|
||
换句话说——“输出未变”只是一次幸运的观测；“确定性”是一种架构保证。后者才是工程意义上的可依赖性。
|
||
|
||
三、为什么它是热更新的命门？
|
||
|
||
让我们把场景画出来：
|
||
|
||
上线日: Bundle A (已推送给 1000 万玩家)
|
||
次月更新: Bundle B (依赖 A)，本次不想动 A
|
||
|
||
你希望玩家的流量账单是这样：
|
||
|
||
下载 B + 复用本地 A = 省下一整个 A 的流量
|
||
|
||
要做到这点，你必须回答一个问题：B 里记录的那个”指向 A 的引用”，今天还指得到吗？
|
||
|
||
这就要讲 AB 的内部机制了。
|
||
|
||
AB 是怎么记录跨包引用的
|
||
|
||
每个 AssetBundle 内部是一个 SerializedFile，开头有一张 External References 表：
|
||
|
||
External References
|
||
path(1): "Library/unity default resources"
|
||
path(2): "Resources/unity_builtin_extra"
|
||
path(3): "archive:/CAB-35fce856128a6714740898681ea54bbe/CAB-35fce856128a6714740898681ea54bbe"
|
||
|
||
然后对象内部的引用长这样：
|
||
|
||
m_Material PPtr<Material>
|
||
m_FileID : 3 ← 指向上面 path(3)
|
||
m_PathID : 6 ← 目标文件里的第 6 号对象
|
||
|
||
所以 B 里的一个引用本质是一个二元组：
|
||
|
||
(file, object) = (CAB 路径, PathID)
|
||
|
||
关键点：CAB 路径里那个 hash，是由”构建出的 SerializedFile“决定的，不是抽象的”Bundle A”。
|
||
|
||
现在你就能看懂这个”坑”了
|
||
|
||
如果管线是确定性的：
|
||
|
||
A 没改 → 重新打也一定得到字节完全一致的 A → CAB 路径不变 → PathID 不变
|
||
B 里的 (CAB-xxx, PathID=6) 仍然能 100% 命中旧 A
|
||
玩家本地的旧 A 可以安全复用，不用重新下载
|
||
|
||
如果管线是非确定性的：
|
||
|
||
A 没改，但重新打出来的 A’ 可能CAB 哈希变了、或者对象顺序变了、或者PathID 漂移了
|
||
B 里记的引用指的是”新 A’“的结构
|
||
你让玩家复用旧 A → 可能看起来正常，也可能随机 crash
|
||
|
||
这就是为什么 Unity 官方只敢说 “might work, but do not rely on it”。
|
||
|
||
构建管线的确定性，决定了你整个热更体系的可靠上限。
|
||
|
||
四、哪些行为会破坏确定性？踩雷清单
|
||
|
||
下面我把最容易踩的坑按四个层级整理出来。每个坑都用 “现象 → 原因 → 怎么修” 的格式来讲，方便直接对照排查。
|
||
|
||
A. 构建管线层 —— 你选错了工具或用错了姿势
|
||
1. 🔥 搞混了几种 hash，把”输入 hash”当成了”内容指纹”
|
||
|
||
现象：明明包内容变了，你的版本对比系统却说没变；或者反过来，内容没变，hash 却变了。
|
||
|
||
原因：Unity 内置 BuildPipeline.BuildAssetBundles 生成的 hash 是基于输入估算的，不是基于最终产物的内容。里面其实混着好几种 hash：
|
||
|
||
hash 类型 它代表什么
|
||
IncrementalBuildHash 用来判断”要不要重新打这个包”的输入指纹
|
||
TypeTreeHash 用来判断”类型结构有没有变”
|
||
缓存 version hash 给 Caching 系统用的版本标识符
|
||
最终二进制内容 包文件实际的字节
|
||
|
||
这四个东西完全不是一回事。如果你把前面某个 hash 直接当成 CDN 版本号，或者当成”两个包一不一样”的判断依据，就会出错。
|
||
|
||
Unity 6.6 手册也明确提醒了：
|
||
|
||
The AssetBundle input hash isn’t an ideal value for tracking file versions.
|
||
|
||
怎么修：
|
||
|
||
如果你的发布系统需要精确判断”包内容到底变没变”，优先考虑 SBP 或 Addressables — 它们的 hash 是基于构建输出算的，更准确
|
||
如果继续用内置 API，就别拿它的 hash 直接当内容校验，自己对产物算一遍 SHA256 更靠谱
|
||
2. 以为开了 DeterministicAssetBundle 就万事大吉
|
||
|
||
现象：明明开了这个 flag，不同机器打出来的包还是不一样。
|
||
|
||
原因：BuildAssetBundleOptions.DeterministicAssetBundle 是老时代的知识。它只解决 PathID 分配的确定性问题。但在现代 Unity（6.x）里，破坏确定性的主要原因早已不是这个 flag，而是：
|
||
|
||
收集资源时没排序
|
||
构建脚本里塞了时间戳、随机数
|
||
不同机器的导入缓存不一致
|
||
构建环境（OS、Unity 版本）不一样
|
||
|
||
怎么修：不要只盯这一个开关。真正要盯的是整个构建流程的输入稳定性。
|
||
|
||
3. 打包前忘了切 Build Target
|
||
|
||
现象：CI 上打 Android 包，但编辑器的 Active Target 还停留在 iOS。打出来的包和手动打的不一致。
|
||
|
||
原因：如果你调用 BuildPipeline.BuildAssetBundles 时指定的平台和当前 Active Target 不一样，Unity 会悄悄触发资源重导入和脚本重编译。更坑的是，正在跑的编辑器脚本（比如你的打包工具、构建回调）是按旧 Target 编译的，可能出现平台条件判断错乱。
|
||
|
||
怎么修：CI 脚本里，打包之前先显式切换 Active Target：
|
||
|
||
EditorUserBuildSettings.SwitchActiveBuildTarget(BuildTargetGroup.Android, BuildTarget.Android);
|
||
B. 资源数据层 —— 你的资源本身就不稳定
|
||
4. AB 名字里带了日期或构建编号
|
||
|
||
现象：每天打包，即使资源没变，包名都在变，hash 自然跟着变。
|
||
|
||
坏例子 vs 好例子：
|
||
|
||
❌ ui_mainmenu_20260417.bundle ← 每天都变
|
||
❌ ui_mainmenu_build_2841.bundle ← CI 编号会变
|
||
✅ ui_mainmenu ← 稳定标识
|
||
✅ ui_mainmenu_v1.2.3 ← 语义化版本
|
||
|
||
Unity 6.3⁄6.6 文档的原话：
|
||
|
||
Avoid timestamps or build-date suffixes in AssetBundle names and use static identifiers or semantic versions.
|
||
5. ⭐ 收集资源时没排序（最常见的坑！）
|
||
|
||
现象：同一台机器连续打两次，包的 hash 居然不一样。更常见的场景是 A 电脑打出来的包和 B 电脑的不一样。
|
||
|
||
原因：AssetDatabase.FindAssets() 和 Directory.GetFiles() 返回的顺序不保证一致。不同机器、不同文件系统、甚至同一台机器在不同时间调用，顺序都可能飘。一旦资源添加顺序飘了，序列化数据的排列就飘了，hash 自然就变了。
|
||
|
||
坏写法：
|
||
|
||
// ❌ 直接遍历，顺序不可控
|
||
var guids = AssetDatabase.FindAssets("t:Prefab", new[] { "Assets/UI" });
|
||
foreach (var guid in guids)
|
||
{
|
||
group.AddAsset(guid);
|
||
}
|
||
|
||
好写法：
|
||
|
||
// ✅ 加一行排序，问题消失
|
||
var guids = AssetDatabase.FindAssets("t:Prefab", new[] { "Assets/UI" })
|
||
.OrderBy(x => x, StringComparer.Ordinal)
|
||
.ToArray();
|
||
|
||
记住这条规则：凡是涉及 FindAssets、GetFiles、EnumerateFiles 的地方，必须手动排序。
|
||
|
||
6. 往 ScriptableObject 里塞数据时，塞入顺序不稳定
|
||
|
||
现象：和上面一样，不同机器或不同时间构建出的包不一致。
|
||
|
||
原因：如果你在构建前用 IPreprocessBuildWithReport 之类的回调，动态往 SO 的 List<Object> 字段里塞东西，塞的顺序不稳定，序列化出来的字节就不稳定。
|
||
|
||
Unity 6.6 文档说得很明白：
|
||
|
||
If the order of objects in that array isn’t explicitly sorted, the serialized data might differ between machines or consecutive builds.
|
||
|
||
怎么修：喂给 SO 的数据，在写入之前先排好序。
|
||
|
||
7. 资源里写入了随机值、时间戳、机器名
|
||
|
||
现象：每次构建，某些 SO 文件的内容必定不同。
|
||
|
||
坏写法：
|
||
|
||
// ❌ 每次构建都不一样
|
||
so.buildGuid = Guid.NewGuid().ToString();
|
||
so.buildTime = DateTime.UtcNow.Ticks;
|
||
so.machine = Environment.MachineName;
|
||
|
||
这类字段一旦进了序列化数据，确定性就直接被你自己亲手打穿了。
|
||
|
||
C. 环境与工具链层 —— 你以为机器都一样，其实不一样
|
||
8. Unity 版本不一致
|
||
|
||
一句话：哪怕只差一个小版本号，序列化格式、导入器行为、Shader 编译都可能有细微差异。
|
||
|
||
怎么修：CI 锁死 Unity 版本，精确到补丁号（比如 6000.0.32f1），团队所有人用同一个版本。
|
||
|
||
9. 操作系统或 CPU 架构不一致
|
||
|
||
现象：Windows 的 CI 和 Mac 的 CI 打出来的包不一样，尤其是包含动画、粒子的包。
|
||
|
||
原因：浮点数运算在不同 CPU 架构上的舍入行为不同。Unity 6.6 文档原话：
|
||
|
||
Floating-point rounding behavior differs between architectures, which can change serialized float values especially in AnimationClips or imported Mesh data.
|
||
|
||
怎么修：所有 CI 构建机用同一种 OS + 同一种 CPU 架构。
|
||
|
||
10. Git 自动换行没关掉
|
||
|
||
现象：Windows 开发者提交的文本文件是 CRLF，Mac 开发者的是 LF。文本资源的 hash 莫名其妙对不上。
|
||
|
||
怎么修：
|
||
|
||
git config --global core.autocrlf false
|
||
|
||
再在 .gitattributes 里统一声明所有文本文件用 LF。
|
||
|
||
11. 不同机器的 Library 缓存状态不同
|
||
|
||
现象：同样的项目，A 机器是全新 clone（Library 是新生成的），B 机器已经用了很久（Library 有大量缓存）。两台机器打出来的包不一样。
|
||
|
||
原因：Unity 的资源导入结果会受 Library 缓存状态影响。Unity 曾修过一个著名 bug（UUM-114616）：Shader AB 在”干净 Library”和”有缓存 Library”下产出不同。
|
||
|
||
怎么修：用 Unity Accelerator 让所有构建机共享同一份导入结果。但注意：Accelerator 只缓存导入产物（imported assets），不缓存打出来的 AB 包本身。它帮你统一了导入阶段，但不是万能保险。
|
||
|
||
D. 脚本与代码层 —— 改了代码，资源也跟着动
|
||
12. 脚本改动的涟漪效应
|
||
|
||
现象：明明没动资源，一堆 AB 的 hash 都变了。
|
||
|
||
原因：脚本的某些改动会导致 MonoScript 身份信息变化，进而影响引用了这些脚本的 AB。但具体是哪些改动有影响，需要搞清楚：
|
||
|
||
会影响 AB 的脚本改动 不会影响 AB 的脚本改动
|
||
脚本移到另一个 asmdef 下 只改注释
|
||
asmdef 改名 只改方法内部实现（不涉及序列化字段）
|
||
改类名或命名空间 只改 private 字段（非序列化的）
|
||
改 [SerializeField] 字段的类型/名称
|
||
丢失 .meta 文件后重新生成
|
||
13. 构建回调里偷偷写入了变化数据
|
||
|
||
现象：每次构建的 Scene AB 都不一样，但场景文件明明没动。
|
||
|
||
原因：你（或某个插件）在 IProcessSceneWithReport 之类的回调里写了类似这样的代码：
|
||
|
||
// ❌ 每天构建出来的 name 都不一样
|
||
public void OnProcessScene(Scene scene, BuildReport report)
|
||
{
|
||
foreach (var go in scene.GetRootGameObjects())
|
||
{
|
||
go.name = $"Built_{DateTime.Now:yyyyMMdd}";
|
||
}
|
||
}
|
||
|
||
怎么修：构建回调里严禁使用 DateTime.Now、Guid.NewGuid()、Environment.MachineName 等非确定性 API。
|
||
|
||
14. Shader 变体集合不稳定
|
||
|
||
现象：不同机器或不同时间打的包里，Shader 变体数量不一样。
|
||
|
||
原因：如果你的 Shader Variant Collection (SVC) 是通过运行时录制收集的，那它完全取决于”测试的人跑了哪些路径”。不同人、不同时间跑出来的变体集合自然不同。
|
||
|
||
怎么修：大型项目应该用离线枚举 + 手动维护的方式管理 SVC，而不是依赖”录制式收集”。
|
||
|
||
五、如何保障确定性：一份能落地的清单
|
||
工程约定
|
||
[ ] 所有自动化脚本收集到的资源集合，统一做稳定排序
|
||
[ ] 禁止把时间戳、构建编号、机器名写进 AB 名称或序列化资源
|
||
[ ] 明确区分输入 hash、缓存 version hash、内容校验 hash，避免混用
|
||
[ ] Git 关闭自动换行转换，并用 .gitattributes 固定文本换行策略
|
||
[ ] 构建回调中禁止使用 DateTime.Now、Guid.NewGuid 等非确定性来源
|
||
[ ] 若项目强依赖内容级哈希语义，优先评估 SBP 或 Addressables
|
||
[ ] Addressables 项目里，catalog 是依赖身份的权威来源，不要手工替换 bundle
|
||
CI/CD 约定
|
||
[ ] 锁定 Unity Editor 版本，精确到补丁号
|
||
[ ] 固定构建机的 OS 与 CPU 架构
|
||
[ ] 构建前对齐 active target 或 build profile
|
||
[ ] 使用 Unity Accelerator 统一 imported assets
|
||
[ ] 发布构建尽量采用 clean build
|
||
[ ] ProjectSettings、构建配置全部纳入版本控制
|
||
Code Review Checklist
|
||
所有 FindAssets、GetFiles、EnumerateFiles 的结果是否稳定排序
|
||
所有写入 SO 的数组、列表、映射是否有稳定顺序
|
||
是否写入了时间、随机数、机器相关元数据
|
||
是否有 build callback 在构建时改写资源
|
||
是否把某种 hash 误当成了内容校验或发布版本号
|
||
六、最后的防线：双跑比对
|
||
|
||
在 CI 里做双跑比对：
|
||
|
||
不修改任何资源
|
||
在相同参数下连续构建两次
|
||
对每个 AB 文件计算 SHA256
|
||
任何哈希不一致，立刻告警并定位差异
|
||
|
||
定位阶段，用 UnityDataTools 的 textdumper 把两个版本的 SerializedFile 导出成可读文本后直接 diff。
|
||
|
||
七、一些延伸思考
|
||
|
||
写到这里，回头看 Unity 那篇原帖里一段意味深长的话：
|
||
|
||
The reason I initially missed the point is that this question is only interesting when that assumption breaks. （我一开始没 get 到这个问题的点，因为这个问题只有在”确定性假设被打破时”才有意义。）
|
||
|
||
这句话其实在说一个很工程哲学的事情：
|
||
|
||
构建的确定性是一种”隐形的契约”。它平时不存在、不被感知，但一旦破裂，会带着你整个热更体系一起塌方。
|
||
|
||
很多商业项目上线多年都没踩过这个坑，不是因为管线真的确定性，而是因为：
|
||
|
||
每次版本更新都全量重推所有依赖包（成本掩盖了问题）
|
||
或者依赖关系极简（运气好到没引用跨包的老资源）
|
||
|
||
但一旦你想要做差分热更、按需下载、跨版本依赖复用这些更精细的运营动作，确定性就是你绕不开的地基。
|
||
|
||
八、结语
|
||
|
||
一篇帖子引出的概念，最后会延展成一整套工程规范。回到最初的问题：
|
||
|
||
打包出来的 AB 完全没变，就是确定性管线吗？
|
||
|
||
答案是：
|
||
|
||
“输出没变”是确定性管线的一种观测现象；”确定性管线”是只要输入不变就保证输出不变的架构能力。在热更场景下，后者才是你能信赖的东西。
|
||
|
||
如果你负责的是一个需要长期运营的 Unity 项目，强烈建议今天就做两件事：
|
||
|
||
在 CI 上加一次”双跑比对”，看看你们的管线现在到底是什么状态
|
||
把本文的”踩雷清单”打印出来，贴在构建平台的 PR 模板里
|
||
|
||
地基打牢之前，所有的热更优化都是在流沙上盖楼。
|
||
|
||
参考资料
|
||
Unity 官方讨论：Understanding Old Dependency Reuse in Unity AssetBundles
|
||
Unity 6.3 LTS 手册：AssetBundle and Addressables determinism
|
||
Unity 6.6 手册：Deterministic builds introduction
|
||
工具：UnityDataTools
|
||
包：Scriptable Build Pipeline
|
||
|
||
如果这篇内容对你有帮助，欢迎点赞/收藏。
|