Unity 资源热更新尤其是当你的项目里有几万个文件、体量动辄几个G的时候“只下载真正变动的那几个文件”就不只是一句宣传口号而是直接决定玩家是“进游戏2分钟搞定”还是“看着进度条转圈半小时”的关键。我在做某款中大型手游项目时资源目录最终膨胀到接近4万个小文件首包加补丁包加起来的版本迭代里团队对增量更新的方案做过好几轮推翻重建踩过的坑比代码行数还多。这篇就专门拆解这个事到底怎么设计版本清单、怎么算哈希、怎么做差异比对才能在大规模资源下做到“几万个文件只拉取真正变动的几个”。1. 先把问题看明白热更新要解决的不是“下载”而是“判断该下载什么”很多人一听“资源热更新”第一反应是“给AssetBundle写个下载器”。真上手做了才发现下载器反而是最简单的一层真正的难点在于你手里的这些资源哪些变了哪些没变哪些是新增的哪些已经被废弃这些判断要在玩家设备上几毫秒内完成而且绝对不能出错。1.1 一个能让玩家“原地等3分钟”的功能我见过不少项目上线初期功能很简单热更新也就是把整包几十个AssetBundle拉下来完事。但随着版本迭代美术资源越堆越多一个版本全量资源能到3GB以上。如果没有增量更新每次版本更新玩家都要重新下载整个资源包这在一二线城市5G网络下还算“能忍”到弱网环境或者海外部分地区3GB的下载量基本等于劝退。所以只下载“真正变动的那几个文件”这个需求不是性能优化是产品能不能活下去的问题。它背后要解决的核心环节叫“增量更新”而增量更新的技术核心又拆成两块一是怎么精准地算出差异二是怎么把差异安全地同步到所有玩家设备上。1.2 为什么一定要有热更新从“审核困局”说起先说个背景为什么Unity项目几乎都躲不开热更新。原因很多最直接的是版本迭代速度和平台审核机制的冲突。移动端的App审核是有周期的尤其是大版本更新从提审到过审往往要好几天甚至更久。玩家都等着玩新活动了你总不能说“各位稍等我们审核还没过”。这种情况下游戏逻辑如果允许会优先用脚本热更新来解决玩法层迭代但资源层面——美术、UI、场景、特效、音效——这些不走代码逻辑的部分必须走资源热更新。因为资源和代码不同它不需要重新编译整个游戏只需要把新资源文件传到服务器客户端下载后替换本地缓存即可。1.3 增量更新的起点从整包下载到差异下载增量更新这个概念本身不新鲜数据库同步、云存储同步都在用。但在Unity资源管理这个场景里它有几个特殊约束资源文件数量极大可能有数万个小文件每次版本变动的资源占比通常很小可能只有1%-5%客户端设备差异巨大从低端安卓到最新iPhone性能和网络环境天差地别资源加载方式多样可能是AssetBundle、Addressables、Resources文件夹也可能是原文件打包这些约束决定了我们不能简单复制通用的差量同步工具而要根据项目自身的资源形态做定制化方案。后面所有设计都围绕这四个约束展开。2. 增量更新的方案选型整包对比、文件粒度、块粒度怎么选确认要做增量更新之后下一步是选技术路线。这块我在项目里实际比较过三种主流方案也帮团队踩过不少坑逐个说清楚利弊。2.1 三种方案对比谁会真的只下载变动文件先看一张对比表这是我在项目选型时整理的核心差异方案下载粒度服务端计算量客户端计算量实现复杂度典型场景整包下载整个资源包文件无无极低首包、小体量Demo文件级增量单个文件低低低中小型项目、资源文件粒度合理块级增量bsdiff等文件内的数据块高高高大型项目、单个文件极大且频繁变动整包下载就不多说了只有资源总量很小或网络条件极端可控时才成立。文件级增量是大多数项目的首选——按“文件”这个粒度来判断变动每个文件算一个哈希值比对哈希就知道哪个变了然后只下载变了的文件。块级增量更牛逼能进一步做到“同一个文件里只下载变了的字节块”但计算开销和复杂度都高不少。我当时做选型时目标项目资源文件基本是每张UI图、每个模型、每段音效各自打成一个AssetBundle单个文件通常在几十KB到几MB之间文件级增量已经能覆盖绝大部分场景。选文件级增量的另一个好处是部署简单客户端逻辑清晰服务端只需要一个版本清单文件不像块级方案还需要额外的补丁合成服务。2.2 文件级增量里的隐藏成本清单比对文件级增量的核心是把“我要下载哪些文件”这个问题转换成“对比两个文件清单的差异”。这里有个隐藏成本如果你的资源目录有几万个文件每个文件都记录哈希值那版本清单本身就有几万条记录。这个清单文件会有多大我算过一笔账每条记录包含文件路径按80字节算文件哈希MD532字节文件大小8字节一条记录大约120字节4万个文件就是120 × 40000 4.8MB。4.8MB的清单文件在更新时先下载这份清单然后做本地对比这个下载量本身其实可以接受。但如果清单格式没优化好比如用JSON每行一条那体积可能翻倍如果用二进制加压缩能压缩到1MB以内。这块后面实操节点细说。2.3 我的选型结论文件级增量 二进制清单格式综合团队人力、项目体量和迭代节奏我最后选了文件级增量更新清单格式用自定义二进制。选文件级而不是块级的原因很直白项目里的AssetBundle单个文件都不算大块级方案带来的下载量节省很有限但引入的复杂度和出错概率却高得多。而选二进制清单则完全是为了性能——4万个文件的清单用二进制格式加载解析只要几十毫秒用JSON解析则要几百毫秒别小看这几百毫秒在弱机型的加载流程里它就是卡顿的来源。3. 核心拆解版本清单、Hash计算与差异比对逻辑这一节是整个热更新方案的技术核心。先把概念拆清楚再讲代码怎么落。3.1 版本清单长什么样记录哪些字段才有用在Unity资源增量更新里版本清单一般包含以下几个关键字段文件路径相对路径作为唯一标识文件哈希值用于判断内容是否变化文件大小用于显示进度和校验完整性文件版本号或修改时间可选辅助判断文件类型或所属模块可选用于分批下载、按优先级下载。我实测的经验是文件路径和哈希值是必选的文件大小强烈建议加因为下载进度条要用修改时间不建议作为判断依据因为不同平台的文件时间戳经常被修改但内容根本没变会带来大量无意义的“伪变更”。3.2 Hash计算为什么用MD5就够不必上SHA256关于哈希算法我直接说结论Unity资源热更新用MD5完全够用没必要上SHA256。原因有三第一MD5的计算速度比SHA256快不少尤其在低端安卓机上几万个小文件算哈希每一毫秒都能感知到第二MD5的128位长度在“判断文件内容是否变化”这个场景下碰撞概率可以忽略不计——你不需要防恶意攻击只需要防意外修改MD5完全覆盖这个需求第三Unity的C#侧有原生的MD5实现不需要额外引入加密库。当然从理论上说MD5确实有碰撞攻击的可能但那是针对刻意构造文件的场景。你的热更新服务器是自己控制的文件也是自己构建的不涉及恶意第三方用MD5是绝对安全且性能最优的选择。3.3 差异比对流程三张表搞定几万个文件比对的逻辑其实不复杂但要处理好几个边界情况。我把流程拆成三步第一步构建“服务器版本清单”。打包机在每次构建资源后遍历所有产出文件计算每个文件的MD5和大小生成一份当前版本的清单上传到资源服务器。第二步客户端保存“本地清单”。玩家设备上的每次下载完成后本地会持久化一份上一次成功更新的清单这个清单就是客户端判断“我有哪些文件”的依据。第三步比对两份清单。下载服务器清单与本地清单逐条比对得出三类结果新增文件服务器有本地没有要下载变动文件服务器和本地都有但MD5不一致要下载删除文件本地有服务器没有要清理。这三类结果合并成一份“待更新文件列表”就是这个版本真正需要下载的文件。3.4 边界情况新增、删除、回滚分别怎么处理上面的基础流程看着简单但真正写代码时有几个边界情况特别容易出错。新增文件有个坑如果新增资源引用了旧资源而旧资源又没在新增列表里客户端可能在下载中途出现“引用缺失”的加载错误。所以工程上要强调“资源打包的依赖完整性”——要么把被依赖的资源也放进同一次更新要么用运行时动态加载来兼容缺失场景。我们项目用的办法是每次构建时除了生成文件清单还会生成一份依赖关系表更新时把依赖项一起拉下来避免半路吊链。删除文件有个坑如果你不做清理玩家的设备空间会被大量无用文件慢慢填满。尤其当美术迭代频繁时旧资源不清理设备的存储占用会越来越高。但清理又得小心不能只靠“本地清单里有、服务器清单里没有”就删还要确认当前安装的客户端版本确实不再需要这个文件。我们用的策略是删除文件的清理动作延迟一个版本执行即这个版本标记为删除下个版本更新时再物理清理给线上运行留足缓冲。回滚的坑更大一旦线上发现新资源有严重问题需要回滚你把服务器上的资源切回旧版本但客户端本地已经存了新版本的哈希和清单。如果客户端不做特殊处理它会认为“本地和服务器一致”不会重新下载旧文件结果就是回滚失败、玩家依然用着有问题的资源。解决方法是服务器上保存多份版本清单客户端更新时先确认“当前本地版本号 目标版本号”之间的差异而不是只看最新版本或者干脆在回滚时让服务器端生成一份“回滚清单”强制把所有相关文件标记为变动哪怕哈希一样也要重新拉取。4. 实操落地从构建到下载的完整增量链路原理说清楚了接下来直接上实操。我会把整个增量更新管线拆成三个环节构建产出管理、版本清单生成、客户端下载更新。4.1 构建产出目录规范一件事坚持三周后会有回报资源热更新的第一步是让Unity构建产出的文件有一个可预期的目录结构。我踩过最深的坑就是构建脚本里对文件路径的处理太随意导致清单生成和资源加载经常对不上。我现在的做法是这样的AssetBundles/ ├── 10001/ // 版本号每次构建唯一 │ ├── manifest.json // 版本清单二进制 │ ├── manifest.md5 // 清单的MD5文件用于校验 │ └── files/ // 资源文件目录 │ ├── ui/ │ ├── model/ │ ├── audio/ │ └── scene/每次构建都生成一个独立版本号的目录服务器上存储时就按版本号区分客户端始终只关心“从当前版本如何更新到最新版本”。这个结构看起来简单但好处是版本回滚不需要动文件只把目标版本号指回去就行灰度测试也直观指定一部分用户先更新到某版本即可。4.2 构建后自动生成版本清单写进构建管线的一次性工作清单生成要尽量自动化不能每次发布都手工跑一遍。我是在Unity构建脚本里挂了一个PostProcess步骤代码如下public static void BuildAssetBundles(string outputPath, int versionCode) { // 1. 生成所有AssetBundle BuildPipeline.BuildAssetBundles(outputPath, BuildAssetBundleOptions.ChunkBasedCompression, EditorUserBuildSettings.activeBuildTarget); // 2. 遍历产出目录计算每个文件的MD5和大小 var manifestEntries new ListManifestEntry(); var allFiles Directory.GetFiles(outputPath, *, SearchOption.AllDirectories); foreach (var file in allFiles) { // 跳过Manifest自身 if (file.EndsWith(.manifest) || file.EndsWith(.md5)) continue; var hash MD5Util.GetFileMD5(file); var size new FileInfo(file).Length; var relativePath GetRelativePath(outputPath, file); manifestEntries.Add(new ManifestEntry(relativePath, hash, size)); } // 3. 序列化为二进制清单并写入版本目录 var manifestBinary SerializeManifest(manifestEntries); File.WriteAllBytes(Path.Combine(outputPath, manifest.json), manifestBinary); // 4. 生成清单MD5供客户端校验下载完整性 File.WriteAllText(Path.Combine(outputPath, manifest.md5), MD5Util.GetBytesMD5(manifestBinary)); }这段逻辑里有几个细节值得注意计算MD5时要跳过Unity自动生成的.manifest文件否则每次构建这些文件都会有变动造成无意义的更新计算哈希的文件流必须以二进制方式读取别用文本模式不同平台下文本模式会换行符转换导致同样的内容在Windows构建和Mac构建下算出不同的哈希版本号的生成要和管理后台联动不要靠手工指定否则很容易出现“换了一个manifest但版本号没变”的问题。4.3 客户端增量下载流程版本请求、差异比对、断点续传客户端侧的逻辑我用一个流程串起来说第一步启动时请求服务器版本信息拿到最新版本号和最新清单的下载地址。这个请求要轻量10KB以内搞定别把整个清单塞进去。第二步下载最新清单。服务器返回的清单如果是二进制压缩格式一般只有几百KB在普通网络环境下1秒内能完成。下载后先校验清单的MD5避免传输损坏。第三步读取本地清单文件。本地清单在每次更新成功后持久化不存在的话就认为当前是首包走全量下载。第四步比对两份清单生成待更新文件列表。这一步可以用并行计算但注意不要让比对过程阻塞主线程放在一个后台Task里执行否则老机型上会有明显卡顿。第五步按待更新列表逐一下载资源文件。这里有两个优化点一是下载队列要支持断点续传下载一半失败后不需要重新开始二是多个小文件要合并请求避免几万个小文件逐一建立HTTP连接那会让请求开销比内容下载还大。我实际使用的下载优化办法是“分组打包请求”把待更新的文件按大小分桶每个桶打包成一个批量请求但服务器端仍然按文件返回客户端再分别校验哈希。这样既能减少请求次数又保留了文件粒度的校验能力。public async Task DownloadUpdateList(ListManifestEntry updateList, string baseUrl, string localRoot, IProgressfloat progress) { // 按大小分桶小文件优先合并打包请求 var groups updateList .OrderBy(e e.Size) .GroupBy(e e.Size 1024 * 1024 ? e.Path : small_pack) .ToList(); foreach (var group in groups) { if (group.Key small_pack) { // 小文件打包成一个批量下载请求 var packed await DownloadPackedFiles(baseUrl, group.ToList()); foreach (var (entry, content) in packed) { var verifyHash MD5Util.GetBytesMD5(content); if (verifyHash ! entry.Hash) throw new Exception($MD5 mismatch: {entry.Path}); await File.WriteAllBytesAsync( Path.Combine(localRoot, entry.Path), content); } } else { // 大文件走独立下载支持断点续传 foreach (var entry in group) { await DownloadFileWithResume(baseUrl, entry, localRoot); } } progress?.Report(groups.IndexOf(group) / (float)groups.Count); } // 全部下载完成后更新本地清单 await SaveLocalManifest(updateList); }这里有三个工程要点小文件打包请求能显著减少HTTP握手时间。我做过一次实测4万个小文件逐个请求和分批打包请求总耗时可差10倍以上尤其在弱网环境下差异更大每个文件下载后要立刻做MD5校验不能信任传输过程。网络层自己开的校验不算数必须用资源哈希作为最终标准断点续传的实现不能只靠HTTP的Range头还要在文件末尾记录已完成的块信息。我的做法是下载时先用.temp后缀保存临时文件完成后原子性改名成正式文件名避免下载过程中的崩溃导致文件损坏或半截资源被错误加载。5. 那些不跑一遍根本不会知道的坑最后这部分全是项目实战里用真实事故换来的经验每一个都值得你拿笔记下来。5.1 不要用文件名当版本依据最典型的错误代码里比对两个文件的文件名一致就认为文件没变。这在早期项目里很常见结果就是“美术替换了UI贴图但文件名没变更新永远不生效”。文件名只能作为唯一标识绝不能作为内容变动的判断依据。所有“文件是否变动”的判断必须以哈希值为准。5.2 Hash计算要放在构建机上做别放到运行时有些项目为了省事让客户端在首次启动时把本地所有资源算一遍MD5生成初始清单。这个方案在小体量项目里勉强能用但一旦有几万个文件运行时全量计算MD5会导致首启时间暴涨而且低端机型的内存峰值也会很感人。正确做法是构建时服务端生成完整清单首包安装时直接把这份清单带进本地客户端不需要重复计算。5.3 压缩策略影响增量效果AssetBundle的压缩格式会影响文件变动的粒度。举个例子如果两个版本的资源内容差别极小但整个AssetBundle被重新压缩得到的二进制可能很大范围都发生变动导致哈希整体变化你不得不下载整个文件。我试过用LZ4压缩代替LZMA后单文件的重写范围变小增量更新的有效率更高——但代价是包体变大这个权衡要根据项目情况来定。5.4 注意WebGL平台的本地存储限制如果你的Unity项目发布到WebGL尤其用IndexedDB存储热更新缓存那坑比原生平台多很多。WebGL的IndexedDB写入失败、存储配额限制、浏览器隐私模式下存储被禁用都是真实存在的线上问题。我见过一个项目在WebGL上做热更新玩家第一次能更新成功第二次就报写入失败因为IndexedDB的持久化空间满了。解决方案是WebGL平台的更新要做容量预检并且在启动时异常捕获后做降级处理——直接提示玩家使用最新版本的完整包。5.5 灰度发布与强制更新增量更新上线后还有一个运营向的坑新旧版本共存期间如果新版本资源有Bug老版本用户不受影响但已经更新的用户会一直出问题。这里有个经验做法在客户端启动时发一个版本接口返回“当前强制更新版本号”和“当前推荐更新版本号”。强制更新版本号以上的客户端必须补更新到最新否则不允许进入游戏推荐更新版本号可以提示但允许跳过。这样在一波大规模版本迭代时可以快速收敛版本避免多版本资源不兼容的维护地狱。5.6 别忘了资源清理策略增量更新带来一个“副作用”玩家设备上的本地资源会越积越多。旧版本下载的资源如果不清理光靠增量更新几个月后玩家的设备里能塞进几十个版本的历史资源白白浪费存储空间。清理策略我前文提过“延迟一个版本”这里再补充一个技巧在清单里加一个minVersion字段记录该文件从哪个版本开始不再被引用客户端的清理逻辑只需判断minVersion 当前版本就允许删除该文件。写在最后的实操体会增量更新这套方案很多细节都是拿线上事故换出来的。我自己最深刻的体会是方案本身并不复杂复杂的是对“文件状态变化”的理解是否足够严谨——文件名会重复、哈希会算错、压缩会带来假变动、平台会限制存储每一个细节都可能让你的增量变成“全量”。所以别嫌清单比对逻辑麻烦也别嫌每个文件都算MD5开销大这恰恰是整个方案可靠性最高的部分。如果你正在做Unity资源热更新我建议从一个小规模的Demo开始先跑通“构建生成清单、客户端比对下载、本地校验替换”这一条链路再逐步加断点续传、批量请求、灰度发布这些进阶能力。等这条链路跑稳了几万个文件的增量更新只是数据量变大复杂度并不会跟着翻倍。