游戏上线后用户反馈了一个偶发闪退主程在地铁上掏出手机改了两行代码热更一发玩家半小时后重启客户端就自动更新了——这套体验听着很爽但落到工程上就是两件事资源怎么热更代码怎么热更。我这几年的处理方案一直是YooAsset管资源、HybridCLR管代码两个开源方案搭一套完整的热更新流水线。这篇内容就把这套组合从原理到实操完整走一遍包括分组策略、打包参数、版本管理、模拟更新环境和踩过的坑适合已经把Unity基础过了一遍、打算给项目上热更新的开发者参考。1. 整体设计思路先把YooAsset和HybridCLR的分工想明白1.1 热更新的本质与拆解热更新说白了就是让客户端在用户不知情的情况下替换掉一部分内容。Unity项目的内容无非两大类资源模型、贴图、UI、场景、配置表和代码C#逻辑。资源热更靠AssetBundle代码热更则需要一套能加载并执行外部DLL的机制。很多团队最开始会把两者混在一起做结果就是配置、加载、版本管理一团乱麻。我的做法是始终用两条独立的管线资源管线YooAsset负责AssetBundle的分组、打包、加密、版本下发和加载代码管线HybridCLR负责把热更程序集编译成DLL随资源一起发出去客户端运行时再加载执行。这样设计的核心逻辑是让两条链路互相解耦。资源更新不涉及代码逻辑可以做到静默更新代码更新则影响运行逻辑需要考虑重启生效的问题。分开管后面排查问题、发版本、做权限控制都会清晰很多。1.2 YooAsset和Addressable怎么选选用YooAsset而不是Unity官方的Addressable我当时的判断依据有三条首先是可维护性。YooAsset的源码结构简单构建管线清晰出问题时可以直接下断点调试Addressable内部封装了复杂的依赖分析和异步加载体系初期好用踩到深层问题就非常难排查。其次是资源分组和加密控制。YooAsset在收集器层面就支持正则过滤、标签分组、按目录打包构建时可以一键开启偏移加密。Addressable虽然也支持加密但需要自己写ResourceProvider成本明显更高。最后是更新流程的可控程度。YooAsset的更新流程拆得非常明确检查版本、更新清单、创建下载器、下载资源每一步都有对应的Operation你可以轻松把进度条、断点续传、失败重试都嵌入进去。Addressable则更强调“自动”很多细节被框架吃掉了真要做强控制反而麻烦。当然Addressable在AAA级项目的资产管理能力更强生态也更完善。但如果你是一个中小团队、要快速搭建一套自己能看懂、能改动的热更新体系YooAsset的性价比明显更高。它的中文文档和社区讨论也比较充分出问题能找到参考。1.3 HybridCLR和其他代码热更方案对比代码热更的方案无非几条路Lua系xlua、tolua、ILRuntime、HybridCLR。我最终选HybridCLR核心原因是它不需要把业务代码迁出C#体系。用Lua意味着团队要维护两套代码C#写服务端逻辑、Lua写客户端逻辑开发效率损失很大ILRuntime的特点是纯C#实现兼容性好但存在跨语言调用性能损耗复杂的泛型、值类型场景容易踩坑。HybridCLR的思路则是基于Unity IL2CPP的底层机制做文章。它让热更DLL里的IL代码在运行时由内置的解释器执行同时通过补充元数据AOT元数据补充解决泛型、反射等IL2CPP特性受限的问题。对开发者来说大部分C#语法都能直接使用不需要额外学一门语言也不需要重写业务逻辑。代价是这套机制对Unity版本、IL2CPP版本比较敏感升级引擎要跟着升级HybridCLR版本。但相比于它省下的维护成本这个代价完全值得。所以最终方案就是YooAsset出资源出热更DLLHybridCLR出代码执行能力版本管理、更新策略、UI流程自己控制。2. YooAsset资源热更新实操从配置到加载2.1 安装与初始化资源包YooAsset目前推荐通过UPM方式安装。在Packages/manifest.json中添加依赖或者直接使用Package Manager窗口添加git地址。安装完成后工程里会出现YooAsset菜单和对应源码目录。初始化代码是整个热更新链路的第一步以YooAsset 2.x为例典型的初始化流程如下using YooAsset; using UnityEngine; public class Bootstrap : MonoBehaviour { private IEnumerator Start() { // 1. 初始化YooAsset根节点 YooAssets.Initialize(); // 2. 创建并获取默认包 var package YooAssets.CreatePackage(MainPackage); YooAssets.SetDefaultPackage(package); // 3. 初始化资源包 var initParams new InitializeParameters { // 生产环境用这个会自动读取本地沙盒清单 // 编辑器调试时可以设为EditorSimulateMode }; var initOperation package.InitializeAsync(initParams); yield return initOperation; if (initOperation.Status ! EOperationStatus.Succeed) { // 初始化失败这里需要处理 yield break; } } }这段代码有几个容易忽略的细节。CreatePackage的包名要与构建时的包名完全一致否则会匹配不到资源。每个包代表一套独立的资源体系如果你的项目需要多个包比如主包DLC包需要分别创建和初始化。初始化模式也很重要EditorSimulateMode适合编辑器内快速调试不会真的加载AssetBundleOfflinePlayMode适合纯单机HostPlayMode才是热更新场景要用的模式。我一般在编辑器下用SimulateMode打包机上用HostPlayMode通过宏定义切换。2.2 资源收集器配置与分组策略YooAsset的资源分组通过AssetBundleCollector实现。在菜单YooAsset/AssetBundle Collector打开配置界面需要理解几个核心概念Collector收集某个目录下符合条件的资源Group一组资源的集合会构建成一个或多个AssetBundleRule规则决定每个资源如何分配到Bundle中。我常用的分组策略是按业务模块划分Group而不是按资源类型划分。比如UI模块所有UI预制体、UI图集角色模块角色模型、动画、特效场景模块各关卡场景、Lightmap这么分的好处是更新的粒度可控。修改了某个角色的贴图重建时只会重新生成对应模块的Bundle玩家下载的增量资源也小很多。如果所有资源打成一个巨型Bundle改一行配置表都要下载几百MB那体验就废了。每个Group下我会再按目录设置PackAsset规则让每个子目录独立出一个Bundle避免粒度过粗。同时开启Addressable命名给资源起一个稳定路径这样代码里按路径加载资源移动位置后只需要重新收集不需要改代码。分组时还需要特别关注依赖资源的处理。举个例子很多美术资源会引用一个公共Shader或公共贴图如果这个依赖被打到了多个Bundle里就会出现资源冗余包体白白膨胀。YooAsset的构建日志里能查看到依赖分析结果构建后建议用YooAsset/AssetBundle Debugger检查多余依赖。2.3 构建参数压缩格式、加密与增量构建构建在菜单YooAsset/AssetBundle Builder中执行构建参数是这里的关键。我的建议配置如下压缩格式LZ4。LZMA虽然压缩率更高但加载时整体解压首包太大时启动明显变慢LZ4是分块压缩加载快还支持随机读取适合游戏包体加密方式偏移加密。YooAsset内置了Offset加密方案可以防止资源被直接扒包。密钥是构建时传入的运行时初始化需要传同一个密钥这个配置一定要和客户端约定好构建选项开启Build with Encryption和强制重建。强制重建会全量打一次包适合每次发版平时开发建议用增量构建能大幅缩短打包时间。需要注意加密不是万能的。它只防君子不防小人偏移加密的强度主要让普通玩家和初级破解者无从下手真要防逆向还是得靠服务端校验和自定义加密方案。构建产物里会生成YooAssets文件夹里面有各个平台的Bundle文件、清单文件和版本文件。上传到CDN时我习惯按平台/版本号的目录结构存放例如Android/v1.0.0/后面做版本管理和多平台发布会省很多事。2.4 运行时更新流程与加载API资源更新流程我封装成一个专门的模块启动时依次执行// 1. 请求远端最新版本号 var versionOp package.RequestPackageVersionAsync(); yield return versionOp; // 2. 更新资源清单 var manifestOp package.UpdatePackageManifestAsync(versionOp.PackageVersion); yield return manifestOp; // 3. 创建下载器下载所有变更的资源 var downloader package.CreateResourceDownloader(); if (downloader.TotalDownloadCount 0) { downloader.OnDownloadProgressCallback OnDownloadProgress; downloader.BeginDownload(); yield return downloader; }这里有个很关键的细节RequestPackageVersionAsync获取的是服务端的最新版本号而UpdatePackageManifestAsync会根据这个版本号对比本地清单生成差异下载。所以版本号必须真实反映资源内容的变化每次构建后都要递增。加载资源时YooAsset提供了同步和异步两套API。推荐使用异步API避免主线程卡顿var handle package.LoadAssetAsyncGameObject(Assets/Game/Prefabs/Player.prefab); yield return handle; var playerPrefab handle.AssetObject as GameObject;加载完成后一定要记得释放handle。YooAsset采用的是引用计数机制不释放会导致AssetBundle无法卸载最终内存泄漏。热词里提到的“粒子特效内存泄露unity”很多时候就是特效预制体加载后没有正确释放资源句柄。场景加载用的是package.LoadSceneAsync配合SceneManager.LoadSceneAsync使用原始文件比如配置表、热更DLL用LoadRawFileAsync这个后面加载HybridCLR程序集会用到。3. HybridCLR代码热更新实操从程序集划分到DLL加载3.1 工作原理简述为什么需要补充元数据HybridCLR的原理我尽量说得通俗一点。Unity使用IL2CPP打包后C#代码会被转换成C再编译成原生指令因此打包后代码逻辑是固定的不能运行时替换。HybridCLR在IL2CPP的运行时里注入了一套解释器能够直接执行IL指令。也就是说热更DLL里的代码不是被预先编译成原生指令而是在运行时逐条解释执行。它还实现了标准CLR的元数据注册逻辑让解释器能识别热更DLL里定义的类型、方法、字段。但这里有个问题IL2CPP打包时AOT侧原生侧已经固定了很多元数据和泛型实例。如果热更代码想调用AOT侧的泛型方法比如ListMyHotUpdateClass这种泛型实例化而AOT侧没有对应的实例IL2CPP本来就会直接报错。HybridCLR的解决办法是“补充元数据”把AOT侧程序集打包进安装包运行时再加载一份它们的元数据让解释器能判断泛型实例化是否需要走解释模式。这个过程理解起来复杂但使用上只需要做两件事一是把AOT程序集列表配置好二是运行时调用LoadMetadataForAOTAssembly加载这些元数据。3.2 工程改造拆分热更程序集要让HybridCLR跑起来第一步是把工程代码拆成AOT程序和热更程序集。具体做法是新建一个Assembly Definitionasmdef命名为HotUpdate。所有需要热更新的业务逻辑都放进这个程序集比如战斗系统、UI逻辑、主流程控制器。不需要热更新的框架代码、第三方SDK封装则留在Assembly-CSharp或单独的AOT asmdef里。这个拆分为什么重要因为AOT程序集一旦打包就固定了只有热更程序集的DLL才能动态替换。你在Assembly-CSharp里改一句代码即便重新发DLL也不会生效只有热更程序集才会起作用。拆分时有一个经验尽量不要让热更程序集直接引用Assembly-CSharp里的类型。如果引用了AOT侧的元数据和类型绑定会让热更DLL运行时报错排查起来非常痛苦。我通常的做法是在热更程序集里自己定义一套接口AOT侧实现或者直接把公共类型也放到热更程序集里。3.3 编译与补充元数据配置HybridCLR通过Package Manager安装后菜单栏会出现HybridCLR选项。首次使用需要执行HybridCLR/Installer/Install安装工具链这个步骤会下载il2cpp等相关工具国内网络下可能需要一点时间。编译热更DLL的入口是HybridCLR/CompileDll/ActiveBuildTarget它会为当前目标平台编译出热更程序集的DLL。产物在HybridCLRData/HotUpdateDlls/{platform}/目录下。注意这个DLL是编译给运行时解释器用的不是普通的.NET DLL不要直接拖到工程里作为引用。补充元数据的配置在HybridCLR Settings里。你需要添加所有AOT程序集的名字常见的有mscorlib、System、UnityEngine.CoreModule等。我的经验是先把所有AOT程序集都加入补充列表性能上影响很小但能避免泛型实例化报错在线上爆发。HybridCLR也提供了自动收集运行时可能用到的泛型实例的方法但手动查漏补缺最稳妥。3.4 运行时初始化与入口逻辑客户端的更新流程和YooAsset接在一起。核心代码如下using HybridCLR; using System.Reflection; // 先执行YooAsset的资源更新拿到HotUpdate.dll的原始字节 var dllHandle package.LoadRawFileAsync(Assets/HotUpdate/HotUpdate.dll); yield return dllHandle; byte[] hotUpdateDllBytes dllHandle.GetRawFileData(); // 补充元数据从包内Resources或AB里加载AOT程序集 foreach (var aotDllName in aotAssemblies) { var aotBytes LoadAotDllBytes(aotDllName); // 你封装的方法 var err RuntimeApi.LoadMetadataForAOTAssembly(aotBytes, HomologousImageMode.SuperSet); if (err ! 0) { // 加载失败需要处理 } } // 加载热更程序集 var ass Assembly.Load(hotUpdateDllBytes); var entryType ass.GetType(HotUpdate.GameEntry); var entryMethod entryType.GetMethod(Start); entryMethod.Invoke(null, null);注意几个细节LoadMetadataForAOTAssembly必须在Assembly.Load之前执行HomologousImageMode.SuperSet是常用模式含义是AOT元数据补充时允许比原始AOT集更新版本热更DLL的字节可以来自YooAsset的RawFile也可以打包进Resources做首包。热更入口的GameEntry.Start方法负责初始化UI、加载主场景、进入业务逻辑。这里有个约定热更程序集的入口方法签名要保持稳定否则前后版本不兼容时客户端代码调用不了新的入口整个更新就会断链。4. 全流程联调版本管理、模拟更新与发布4.1 版本号管理与更新策略热更新系统里最乱的就是版本。我用了三层版本号体系客户端版本号对应PlayerSettings.bundleVersion只有发安装包才变资源版本号对应YooAsset的PackageVersion每次构建Bundle递增代码版本号可以打一个版本文件放到Bundle里或者跟随资源版本。更新策略上有强制更新和弱更新之分。纯资源更新换了贴图、改配置完全静默玩家无感代码更新因为DLL卸载比较麻烦我通常不追求运行时热替换而是下载完成后提示玩家重启客户端生效。强更场景一般在用户版本落后太多时触发比如客户端版本号比服务端要求的最低版本还低就必须提示跳转应用商店。这个判断逻辑在启动时调用服务端接口完成YooAsset和HybridCLR不参与。4.2 本地模拟热更新服务器开发阶段测试热更新不推荐每次都部署到真的CDN。我用一个最简单的HTTP静态服务器就能模拟整条链路。把YooAsset构建产物放到一个本地目录例如Builds/Android/v1.0.1然后启动一个静态文件服务。我这里用Python自带的模块cd /path/to/your/builds python -m http.server 8080此时http://localhost:8080/Android/v1.0.1/就是资源服务的根路径。客户端初始化时把HostPlayMode的服务器地址配置成这个URL就能完整走一遍版本检查、清单下载、资源下载的逻辑。生产环境换成CDN或OSS后逻辑完全不变只是把地址串从localhost换成线上域名。这里需要提醒一点生产环境一定要用HTTPS否则资源请求容易被篡改或劫持尤其是涉及热更DLL这类可执行代码身份被冒充的后果很严重。SSL证书在云厂商控制台申请并配置到CDN即可流程不复杂但别拖到上线前才做。4.3 一套完整的打包与更新流程打包顺序很关键搞反了就会让客户端拿到新DLL但旧资源或者反过来。我的标准流程是更新代码工程到发布分支执行HybridCLR编译热更DLL将新DLL放入Unity工程的RawFile目录比如Assets/RawAssets/HotUpdate/HotUpdate.dll.bytes执行YooAsset构建生成AssetBundle把构建产物上传到CDN对应版本目录在服务端更新资源版本号验证客户端更新流程本地模拟一遍发版或发布热更。步骤2和步骤3的顺序不能反。如果先构建了Bundle再重新编译DLLDLL字节不会进入Bundle玩家更新资源后拿到的还是旧DLL。我踩过一次这个坑排查了半天最后发现是构建顺序问题。另一点是YooAsset构建时要确保当前Unity工程的代码本身就是最新版否则打出来的Bundle里可能带着旧逻辑引用推出新DLL后会有版本不匹配。这里我建议在打包机上搞一套干净的自动化脚本每次从版本控制拉最新代码再顺序执行上述步骤。4.4 强更与弱更哪些场景必须重启客户端更新流程跑通之后还要思考一个问题更新完什么时候生效。资源更新方面YooAsset的加载都是通过句柄只要资源包更新完成下一次加载就会用到新资源。所以纯资源热更可以做到即时生效适合活动UI、新皮肤、数值表这类改动。代码更新方面Assembly.Load加载的新DLL虽然可以立即调用但已经加载的旧程序集里的静态状态、已实例化对象依然是旧的。强行在运行时替换会引发状态不一致我从来没有在生产环境这样做过。所以代码更新我用的是“下载完成后提示重启”的方案启动时检查到有代码更新下载完毕后弹窗提示“游戏需要重启以完成更新”玩家点击重启后应用重启走一遍正常的初始化流程自然会加载最新DLL。在iOS上这个约束更严。苹果对热更新代码管控很严HybridCLR这种解释执行方案在审查时风险很高。我的建议是iOS版本尽量只做资源热更不做代码热更要做代码更新就老老实实发TestFlight或App Store新版本避免被拒绝。5. 踩坑实录常见问题与排查技巧5.1 YooAsset侧的高频问题问题一更新后加载资源还是旧资源。最常见原因是Bundle的版本号没变。YooAsset的清单更新依赖于版本号差异如果你构建了新Bundle但忘了递增PackageVersion客户端会认为没有需要更新的内容。我处理这类问题时第一件事就是对比CDN上的版本文件和本地沙盒里的版本号。问题二下载进度一直卡在某个百分比。这种情况大多是CDN不支持Range请求或者网络问题。YooAsset的下载器默认支持断点续传依赖服务端返回206 Partial Content。如果用的是本地静态服务器测试就没事换到某些云存储就要确认是否开启了Range支持。问题三加载句柄报错资源路径找不到。要检查两处一是LoadAssetAsync里用的路径必须和收集器配置的Addressable路径一致二是资源是否被正确打进了当前Group。我建议所有资源路径都通过常量类维护不要手写字符串不然重构时很容易漏改。5.2 HybridCLR侧的高频问题问题一加载DLL报FileNotFoundException或方法找不到。这类报错九成是补充元数据缺失。热更代码里用了AOT侧的泛型类型但AOT侧没有对应实例化。解决办法是打开补充元数据列表把相关程序集加进去重新打包测试。排查时可以开HybridCLR的日志输出它会打印出具体缺少哪个类型或方法。问题二运行期出现ExecutionEngineException。这个一般是热更DLL和AOT程序之间版本不匹配。比如你改了AOT代码Assembly-CSharp但不像热更DLL那样重新编译IL2CPP侧的代码已经变了解释器却还拿着旧的IL两边对不上。规则是只要改了AOT代码就必须重新打安装包。问题三iOS包体编译失败或启动崩溃。HybridCLR对Unity和IL2CPP版本敏感升级引擎后必须同步升级HybridCLR版本。另外iOS的AOT编译器对部分C#特性支持本身就有坑比如反射、动态代码生成这些在热更代码里尽量少用。我一般把反射集中在极少数地方并做好缓存。5.3 热更新后的性能、安全与包体优化性能优化解释执行的代码和原生编译相比有一定性能差距。凡是真正的高频调用链比如每帧执行的战斗计算建议留在AOT侧热更程序集里只放业务逻辑和低频逻辑。我做过一轮性能压测HybridCLR解释执行的性能损耗在可接受范围但高频调用还是要避开。资源卸载YooAsset的引用计数机制要求每条加载路径都配Release或AutoRelease。建议在加载工具类里做统一封装避免团队成员手写handle忘记释放。这个不解决长时间运行后内存会一直涨。包体控制LZ4压缩下Bundle体积一般比原资源小但冗余依赖会明显增加包体。构建后用YooAsset的Debugger查看资源依赖把被多个模块重复引用的公用资源抽到单独的公共Group。5.4 一条实用的排查路径线上出问题团队不要慌着去猜按顺序排查能省不少时间先查CDN上文件是否完整版本目录是否正确再查客户端版本号、资源版本号是否和服务端一致看日志里YooAsset初始化状态是清单更新失败还是下载失败再看HybridCLR初始化状态补充元数据是否加载成功、DLL是否load成功最后才是业务逻辑问题。Remote日志一定要在启动早期就挂上真机日志采集也建议做成开关发布会开上线后出现事故才有现场可查。我个人在实际操作中的体会是热更新方案更考验的是工程规范而不是单一技术。YooAsset和HybridCLR都是成熟好用的工具但它们只解决了“能不能热更”的问题而“更新稳不稳定”“出问题能不能快速排查”“打包流程靠不靠谱”完全取决于你怎么组织构建流程和版本管理。如果你刚准备给项目上这套方案建议先花一周时间把打包脚本、版本号递增和本地模拟环境跑顺再动业务代码后面会少踩很多暗坑。