前阵子项目被硬生生推到热更新方案选型的路口团队讨论了好几轮。我们是一个正在线上运营的Unity项目已经发过PC包和Android包WebGL跑的是预览版后面还要给微信小游戏那边出包。问题很现实线上Bug改不动发版流程太长每次都要走渠道审核运营天天催。所以热更新不是“要不要上”的问题而是“必须上且三端都得稳”的问题。最后我选了HybridCLR。跑了一圈下来PC、Android、WebGL三端都成功跑通了热更流程整体稳。但过程里踩的坑是真不少尤其WebGL那一堆破事网上资料零散得不行很多坑只能自己一点点试。这篇就把我的接入体验、踩坑记录和排查链路完整写出来给正在搞同款方案的兄弟们一个参考。Unity版本是2021.3.16f1HybridCLR版本是2022年中的正式版YooAsset是1.5.x这个组合比较经典照着用基本能复现。1. 为什么我把项目押在HybridCLR上选型背后的真实考量1.1 不是所有游戏都需要热更但你的项目需要很多人一说到热更新就默认是Lua系方案什么xLua、tolua、SLuaCallLua绷着一堆C#到Lua的跨语言调用性能损耗放在那里调试体验也谈不上好。如果你的项目是纯C#开发的或者团队里全是C#程序员强行上Lua栈意味着全团队都得熟悉Lua的写法、C#和Lua的类型转换、脏数据检查这个学习成本和工作习惯切换很痛苦。但问题是国内大环境就是这样——发出去的包一旦有Crash、闪现、提示错别字这种小问题走商店审核再更新一轮得一周以上玩家的评论早就被冲烂了。所以热更不是要不要做而是什么时候做、怎么做得优雅的问题。我当时列过一张需求表必须是C#原生热更、必须能覆盖iOS和Android、必须兼容WebGL、不能影响现有项目架构、不能让团队重写逻辑层。最后发现能满足这些条件的方案真的不多HybridCLR是为数不多能同时照顾到这些要求的选项。1.2 C#热更方案的取舍Lua栈、ILRuntime、HybridCLR我知道提到热更方案一定绕不开xLua和ILRuntime。这里我直接把对比结果摆出来大家心里有个底对比项xLua/toluaILRuntimeHybridCLR热更语言LuaC#ILC#原生IL跨语言调用开销高C#和Lua之间要marshal中解释执行反射低直接AOT兼容调试体验一般断点链较折腾好一些但仍不是原生调试接近原生Debug体验包体影响额外带Lua interpreter额外带ILRuntime VM主要靠元数据补充包体影响较小学习成本需要团队学Lua需要理解ILRuntime限制仍是C#不需要学新语言WebGL支持需要折腾有方案但不是特别好原生就支持跑wasm也稳说实话ILRuntime也算是个凑合方案但它在WebGL方向的问题比较多因为Interpret模式的实现本身和AOT环境的兼容性就比较尴尬。HybridCLR的优势在于它走的是“补充元数据”的路线不是虚拟机解释执行而是把热更代码当成原生C# IL指令去跑性能损耗极小且天然兼容IL2CPP产物。1.3 HybridCLR为什么能跑AOT与元数据的关系一句话讲清楚HybridCLR的原理你用IL2CPP打包时C#代码会被转换成C再转成目标平台的机器码Android上是ARM指令WebGL上是wasm指令。IL2CPP默认只编译项目打包时已引用的程序集热更代码不在AOT名单里运行时找不到对应的类型和方法。HybridCLR做的就是打包时候把热更程序集和AOT程序集所需的元数据采集出来运行时加载热更DLL同时补充AOT泛型实例化所需的元数据。这样热更代码虽然没进IL2CPP的AOT编译但运行时可以通过补充的元数据直接映射到已有的AOT代码上调用AOT泛型、调用Unity引擎API都没问题不需要解释执行所以性能损耗很小。打比方的话IL2CPP就像一栋已经浇筑好承重墙的房子HybridCLR做的事就是把一开始没画进去的房间隔断图纸补齐。承重结构本身就是现成的你要做的只是把新的隔断砌到已经留好的梁柱位置上。这样你不需要把整栋楼拆了重建还自然能受益于原本的承重设计。我之所以花这么多篇幅讲原理是因为后面所有的问题排障都基于这个认知弄懂了你才不至于出问题时一头雾水。2. 接入前的程序集划分这一层没设计好后面全是放大坑2.1 热更程序集必须放Assets目录外否则纯属给自己挖坑在动手之前先看官方文档文档要求热更代码程序集必须是独立程序集不能放在Assets下被Unity自动编译。很多第一次接入的新手都会犯这个错把HotUpdate.cs放在Assets/Scripts下面然后打包的时候发现热更代码被Unity打进了主程序集热更完全不生效。标准做法是在Unity工程根目录建一个HotUpdate_Code文件夹里面放一份独立的csc.rsp或asmdef配置让这个文件夹的代码不被Unity自动编译。路径一般长这样项目根目录/HotUpdate_Code/。通过csc.rsp使用-target:library的方式手动编译出HotUpdate.dll再拷贝到Assets/Plugins或加载路径下。# 在 HotUpdate_Code 目录下放的 csc.rsp 示例 -target:library -optimize -unsafe我个人建议用官方示例里的HybridCLR.Editor.BuildProcess那套壳直接在Unity菜单栏点一下“CompileDll”就自动编译出热更DLL省得自己每次手动调csc命令。我在实际项目里是把编译好的HotUpdate.dll放到AssetBundles目录下由YooAsset打成AB包首包时随包带到本地线上发布时上传CDN由客户端动态下载。2.2 代码分层与依赖方向热更程序集里不能乱引用程序集划分不是简单地“把要热更的代码丢到独立程序集”就完事了还得考虑依赖方向。我在项目里是按三层来切的Main程序集AOT侧Main程序集指的是入口、启动逻辑、框架层、SDK封装、以及所有编写时已经被IL2CPP编译进包的代码。它不依赖HotUpdate程序集。HotUpdate程序集热更侧包含游戏逻辑、UI、战斗、副本、数据处理等频繁需要修改的代码。它可以引用Main程序集但Main程序集不能反向引用HotUpdate程序集。公共代码程序集比如网络协议、工具类、定义枚举、静态常量这种不太变动的代码放一个Common程序集供Main和HotUpdate两边引用。为什么要这么严因为AOT代码不能直接引用热更程序集的类型。如果Main程序集里直接写了new HotUpdate_Class()打包时IL2CPP找不到HotUpdate程序集编译直接失败。就算你用反射绕过也会面临类型加载顺序的问题——热更程序集还没加载你就去创建对象必然报空引用。如果项目启动时必须要进入热更入口标准套路是把入口方法做成委托类似这样public static class GameApp { private static System.Action _enterGameAction; public static void SetEnterGameAction(System.Action action) { _enterGameAction action; } public static void EnterGame() { _enterGameAction?.Invoke(); } }在启动流程里先加载热更DLL再通过反射或直接通过接口调用GameApp.SetEnterGameAction(HotUpdateMain.Enter)把热更入口注册进来避免Main程序集直接引用热更程序集。2.3 link.xml不是可有可无的东西第一天就写好它接HybridCLR绕不开的问题是代码裁剪。IL2CPP在打包时默认开启Managed Stripping Level很多你运行时才通过反射访问的类型和方法会被当成“没被引用”直接裁剪掉。热更代码在打包时是存在于独立DLL里的IL2CPP根本不知道它需要哪些AOT类型所以你必须在Assets/link.xml里显式保留热更代码会用到的AOT类型。link.xml的使用经验是不要只留HybridCLR相关的AOT泛型列表还要把热更代码里用到的System.Reflection、System.Xml、System.Linq等容易误裁的命名空间一起保留。我的做法是先把HybridCLR.Editor.Settings里的“Global Settings”第一次GenerateAll之后生成的AOTGenericReferences.cs脚本放进工程然后单独维护一个自己的link.xml把公共库的类型加进去。反正宁可多留不要少留裁剪掉了只能用一遍遍重新打包来试错非常耗时间。linker assembly fullnamemscorlib type fullnameSystem.Reflection.MethodInfo preserveall / type fullnameSystem.Reflection.PropertyInfo preserveall / /assembly assembly fullnameUnityEngine.CoreModule /assembly assembly fullnameDOTween namespace fullnameDG.Tweening preserveall / /assembly /linker这里我特别想提醒一句link.xml要在接入第一天就写好别等项目庞大之后再来补。项目一大热更代码里用到的AOT类型成千上万到时候你根本找不到是哪个类型被裁了。我有一次因为System.DateTime.ToString(string format)被裁剪线上玩家某一端直接崩排查了好几天最后发现是link.xml没保留DateTime格式化的重载。3. PC平台跑通只是开始Editor验证里的那些盲区3.1 Editor能跑通不代表IL2CPP打包后能跑很多教程第一步都是让你在Editor里跑Demo然后告诉你“跑通了”。这确实是最快的验证方式但我想说的是Editor里跑通只证明你的热更DLL加载逻辑没有大问题完全不能证明IL2CPP发布后能跑。Unity Editor环境下用的是Mono运行时不会走IL2CPP裁剪也不存在AOT泛型缺失的问题。我见过好几个团队下载了官方Demo在Editor里跑通就以为完事了结果打包到PC端运行时报一大堆ExecutionEngineException: Attempting to call method XXX for which no ahead of time (AOT) code was generated。这种报错信息怎么排查方法是看抛异常的堆栈你会发现它指向某个泛型类型。比如ListMyHotUpdateClass的Add方法在热更程序集里调用但AOT侧没有准备对应泛型实例化的元数据。HybridCLR提供了AOTGenericReferences.cs来收集所有AOT泛型但前提是用HybridCLR.Editor/CompileDll/ActiveBuildTarget编译热更DLL时工具链会把当前热更DLL里引用的泛型实例化全部记录下来。如果编译热更DLL的Target和最终打包Target不一致这个记录就有偏差。3.2 首包和热更包的分离验证PC平台的一个好处是调试方便但如果你把它当成“只是跑通而已”后面的Android和WebGL会加倍还你。我的建议是PC上就要把“首包逻辑”和“热更包逻辑”完整跑一遍最好模拟真实线上环境首包不带热更DLL启动时发现本地没有热更文件走“下载首包资源下载最新热更DLL”的流程。首包带一份热更DLL启动时比较版本号决定是否下载新DLL。热更DLL下载后会做版本号校验、MD5校验再交给HybridCLR加载。这一步主要排除的是热更资源加载路径的问题。比如AB包路径写错、版本号没对上、压缩格式不对这些在单独验证HybridCLR时不会被触发但合在一起就炸了。我PC上调试时就发现如果先加载了带旧DLL的AssetBundle再去加载新DLL会因为AB包缓存没清理而出现“DLL版本对不上但字节一致”的假象后来加了一个强制轮询AB包缓存和MD5校验的接口才解决。3.3 日志和数据持久化在PC上的特殊性PC平台跑通后最好顺带验证一下日志输出。因为线上PC包你不可能开着Unity Editor看控制台所以日志得落到本地文件。HybridCLR加载DLL时的任何异常都会通过Unity的Debug.Log输出如果没接日志落盘问题根本看不出来。我这里用的是ZLogger配合FileLogTarget把Application.persistentDataPath下的Log目录写入当前日期带序号的日志文件。这只花了半天时间但后来排查WebGL的IDBFS问题和Android真机问题全靠它。4. Android平台的实战从打包到真机的问题清单4.1 GameAssembly.dll与IL2CPP的映射关系Android端IL2CPP打包后核心代码全部编译到libil2cpp.so里而Windows PC端打包后是GameAssembly.dll。很多第一次在Android踩坑的同学第一次看到“GameAssembly.dll”字样其实是在PC平台的崩溃日志里因为它是Windows下Unity IL2CPP产物。Android下IL2CPP代码在libil2cpp.so如果你被错误信息误导去查GameAssembly.dll方向就偏了。HybridCLR在Android上的原理和在PC上是一样的它通过补充元数据让libil2cpp.so里已有的AOT代码能够运行热更DLL中的方法。但因为Android的包体结构更复杂加上权限、SDK、多ABI的问题调试成本明显高不少。一个非常典型的坑ABI Filter设置。如果你的Android打包只勾选了ARM64而HybridCLR在Editor生成补充元数据时默认会同时生成ARMv7和ARM64两份实际上会导致打包时AOT泛型引用列表不一致。我建议直接从Android 10开始就只出ARM64的包别在兼容32位上投入精力了2023年之后没几个真机跑在ARMv7上。4.2 AOT泛型元数据补充的两种触发方式Android上最灵异的一个问题是同一个热更包在PC上跑得好好的一发到Android真机就疯狂报AOT code was generated for XXX错误。排除掉ab包路径问题后最常见的原因是App启动时没有正确触发AOT泛型元数据加载。HybridCLR有一个AOT泛型补充机制可以选两种方式第一种代码主动触发加载Liststring aotDllList new Liststring() { mscorlib.dll, System.dll, System.Core.dll }; foreach (var aotDllName in aotDllList) { byte[] dllBytes LoadAotDllBytes(aotDllName); // 从AB包或Raw资源中读取 LoadImageErrorCode err RuntimeApi.LoadMetadataForAOTAssembly(dllBytes, HomologousImageMode.SuperSet); Debug.Log($LoadMetadataForAOTAssembly:{aotDllName}, ret:{err}); }第二种通过启动参数自动加载HybridCLR提供了--hybridclr-...形式的命令行参数在启动时自动补充元数据。但这种方式的缺点是对加载路径的灵活性要求较高而且不好调试。我实际用的是代码主动触发而且加载时机非常讲究必须在热更DLL加载之前完成AOT元数据补充。如果你先加载了热更程序集、再补充元数据可能会因为类型查找表还没建立而抛出莫名其妙的异常。4.3 Android真机日志怎么拿Android调试点很多但最痛苦的是日志。如果热更DLL在Android上启动就崩你根本看不到异常信息因为Unity的Debug.Log输出到Logcat里了你得接Logcat抓。这里分享一个我一直在用的方式adb logcat -s Unity -v time unity_log.txt启动App后所有Unity层的Debug.Log、Debug.LogError都会带时间戳写进unity_log.txt。HybridCLR的异常一般会伴随FATAL EXCEPTION一起出现在日志里搜HybridCLR、AOT、LoadImageErrorCode这些关键字就能快速定位。还有个更省事的做法在工程里挂一个LogCallback监听把Application.logMessageReceived收到的日志同时写入Application.persistentDataPath下的本地文件真机上跑完把log文件拉出来看。两种方式配合使用基本能覆盖90%的问题。4.4 Android真机最容易忽略的三个细节IDBFS那类文件写入问题其实主要出在WebGL但Android上有一个相似的坑是persistentDataPath的权限和路径问题。Android 11API 30开始有分区存储Application.persistentDataPath指向/storage/emulated/0/Android/data/package/files写的文件在别的App下看不见这是正常的不要在那边纠结。包名和key签名的稳定性。HybridCLR加载热更DLL是纯代码层面的东西不涉及证书但YooAsset的资源热更涉及版本校验如果开发包和正式包的签名不一致可能会有被系统拒绝读取AB包的情况。打包测试时一定要保证签名key和正式包一致。多DEX的问题。如果你的Android项目使用了Multidex而某些AOT程序集被打到了Dex 2里面可能导致HybridCLR在启动早期加载元数据时出现ClassNotFoundException。规避办法是在gradle.properties里把android.enableDexingTransform调成false或者增大com.android.dex.DexFormat.MAX_MEMBER_COUNT。这个坑比较少人提但一旦碰到就是启动即崩很凶险。4.5 补充元数据丢失的场景混淆和裁剪一起上Android打包还有个常见流程是开ProGuard或R8混淆。HybridCLR官方的建议是不要混淆AOT程序集对应的元数据DLL。具体操作是在proguard-rules.pro里把热更程序集相关的类keep住或者直接把混淆关掉反正热更DLL本来就是要动态加载的混淆意义不大还容易误伤。我实测过如果开着R8的裁剪和混淆LoadMetadataForAOTAssembly极大概率返回HomologousImageMode异常的返回值。后来我在混淆配置里明确keep了com.hybridclr.*以及System.*的大多数类才恢复到正常状态。5. WebGL最麻烦的平台坑全是平台机制造成的5.1 为什么HybridCLR在WebGL上要另眼相看WebGL是我这次接入三平台里花时间最多的方向原因主要是WebGL平台本身的特殊机制和HybridCLR叠加后产生了很多连锁反应。先说结论HybridCLR在WebGL上是完全可以运行的但你需要重点处理的是文件系统和wasm内存这两个衍生问题而不是HybridCLR本身。WebGL上的Unity运行时其实就是把C#代码编进wasm跑在浏览器沙箱里。浏览器权限受到严格限制你不能直接读写本地文件Unity封装了一层IDBFSIndexedDB File System来模拟文件系统把持久化数据放在IndexedDB里。HybridCLR要加载热更DLL就必然要经过IDBFS或内存加载。这里有一个很关键的点在WebGL上Application.persistentDataPath对应的是IDBFS挂载的路径但这个路径并不总是可写而且浏览器隐私模式、存储配额不足都会导致写入失败。5.2 一个典型报错idbfs写入失败完整的排查链路我在WebGL端遇到最典型的一个报错日志里不长不短地出现一行idbfs write failed。第一次看到时我只知道它跟IndexedDB有关但具体哪个环节炸了完全没头绪。这里把排查链路完整记录下来。前置操作我通过UnityWebRequest从CDN下载热更AB包在内存里解压出热更DLL然后直接通过Assembly.Load加载绕过IDBFS。但崩溃日志还是提到了idbfs。后来我发现YooAsset默认会把下载的Bundle写入Application.persistentDataPath而WebGL下这个路径就是IDBFS挂载的目录。YooAsset先写了缓存然后才返回字节数组给业务层所以IDBFS一旦写入失败整个下载流程会中断。解决思路是这样的优先采用“内存加载、不落盘”的方式。对于热更DLL这个关键文件不要让YooAsset写入缓存。写一个独立的下载接口把AB包数据拉下来后直接bytes处理不进YooAsset的Cache路径。如果必须落盘则先检测浏览器是否可用IndexedDB。可以尝试在启动时写入一个小测试文件读取回来校验若失败则降级到内存模式。给IDBFS挂载操作加一个超时保护。浏览器在首次访问IndexedDB时可能需要用户授权或建立连接这个初始化过程偶尔会阻塞。等初始化完成再让YooAsset的缓存逻辑挂上去。IEnumerator CheckIdbfsWritable() { string testFilePath Path.Combine(Application.persistentDataPath, idbfs_test.txt); File.WriteAllText(testFilePath, test); yield return null; string content File.ReadAllText(testFilePath); if (content test) { Debug.Log(IDBFS writable); // 继续走缓存流程 } else { Debug.LogWarning(IDBFS not writable, use memory mode); // 走纯内存加载流程 } }注意WebGL平台上大部分文件操作都是同步仿真配合异步协程时偶尔会有虚假的“写入成功”但实际上没写进去。后来我在检测逻辑里加了一句if (File.Exists(testFilePath))以及长度校验才算稳下来。5.3 内存限制和大DLL导致的崩溃WebGL的另一个大坑是内存。Unity的WebGL打包默认情况下限制在2GB内存wasm32寻址上限而且这个内存是在启动时一次性申请的。你的热更DLL如果比较大或者AB包加载后解压到内存再Load峰值内存一下飙上去浏览器直接掉标签页运气好的话弹出Out Of Memory崩溃日志运气不好就是白屏。这里有个优化经验热更DLL强烈建议用压缩格式存放。HybridCLR的Assembly.Load(byte[])是支持从压缩字节数组加载的你可以在打包阶段给DLL加一层LZ4压缩或者GZip压缩加载时解压。缺点是解压本身也要占内存所以更推荐的做法是让AB包本身的压缩格式选LZ4而不是LZMA因为LZMA解压时会把整个Bundle解到内存LZ4是按块解压内存峰值更低。# AssetBundle压缩格式选择 # BuildAssetBundleOptions.LZ4Compressed 推荐用于WebGLYooAsset在打包时如果你选择使用可写区缓存那么下载到本地的文件其实已经是解压过的Bundle了加载时不需要再解压。但如果你选择只在内存中缓存那就得考虑压缩格式带来的内存开销。我实际操作下来的配置是WebGL端不用可写区缓存改用纯内存模式AB包用LZ4压缩热更DLL在打AB包前先单独压缩一层这样整体内存峰值能降低20%左右换来的是稳定的运行体验。5.4 微信小游戏和WebGL模板那些事做到了微信小游戏这一步如果你还在用Unity的默认WebGL模板大概率会碰上一堆问题。微信小游戏的运行环境并不是标准浏览器它有自己的JS桥、文件系统和分包机制。HybridCLR跑在微信小游戏上时DLL的加载路径、AB包的资源下载方式和标准WebGL完全不同。这里特别提一个热词“团结引擎打包微信小游戏时如何正确配置webgl模板”——这个坑我也是踩过。Unity官方WebGL模板默认生成的loader.js在微信里跑不起来因为微信不允许跨域访问不支持直接在浏览器地址栏访问CDN文件你必须把资源包同步到微信小游戏的分包目录里。我的做法是使用微信官方提供的minigame-websocket模板或wechat-minigame模板确保UnityWebRequest在微信小游戏环境下能正确发请求。把AB包和热更DLL的远程地址改为微信wx.env.USER_DATA_PATH下同步好的本地文件而不是HTTP远程下载。在微信开发者工具的“本地设置”中打开“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”否则调试阶段根本起不来。不过“本地设置”里的这个选项只影响开发者工具真正上线还得在微信公众平台配置合法域名且域名必须是HTTPS且已经备案。这些属于微信侧配置的范围这里不展开。还有一个内存相关的点微信小游戏的包体积限制很严格主包不能超过4M分包不能超过20M。而HybridCLR的热更DLL和AOT元数据加起来可能就有几十MB这就需要合理拆分AB包把必要内容放在首包其它全部放CDN或远程。Unity的WebGL模板本身也有体积优化配置建议把Compression Format设为Brotli能显著减小首包体积但需要服务器端支持Brotli压缩响应。我踩过的一个比较深的坑是WebGL在浏览器里跑的时候如果开了开发者工具的Development Build内存占用会翻好几倍而且在微信里基本必崩。发布到微信小游戏时务必使用Release Build不然你会在各种莫名其妙的白屏里耗掉一整天。6. 三平台共用的几个坑序列化、反射、加密混淆和资源热更6.1 反射调用在热更程序集里的意外行为HybridCLR虽然让C#热更成为可能但反射这条路并没有完全敞通。热更程序集里定义的类型用反射获取、调用是没问题的。可如果你反射的是AOT程序集里的类型快速找到GetMethod或者GetProperty在打包后可能返回null因为AOT裁剪和泛型实例化根本就没把这些Method的元数据元算进去。比如有一段代码Type t typeof(GameManager); // GameManager在AOT程序集里 MethodInfo method t.GetMethod(Init); method?.Invoke(instance, null);在Editor环境里跑得好好的但IL2CPP打包后GetMethod(Init)返回null的概率极高因为GameManager是纯AOT代码IL2CPP在裁剪时如果没有保留MethodInfo的反射元数据那你就拿不到。解决办法是给link.xml加上对应类型的保留规则或者干脆把这些反射调用改成接口调用避免运行时反射。我建议项目里从第一天就约定热更代码访问AOT类型的成员一律通过公开接口或虚方法调用不直接用反射只有极少数场景比如依赖注入框架才允许用反射并且用link.xml把所有用到的类型和成员手动显式保留。6.2 序列化在热更程序集里的表现序列化是另一个容易踩雷的点。Unity自带的JsonUtility基于UnityEngine.Serialization命名空间对热更程序集里定义的类型处理是有一定局限的。尤其当你用JsonUtility.ToJson序列化热更类时如果这个类的字段没被标记[Serializable]或者字段类型是字典、泛型在AOT下很可能出现序列化结果异常或直接抛异常。[Serializable] public class MyHotUpdateData { public string name; public int level; public Listint items; }经验是热更侧如果需要序列化优先使用带AOT支持的序列化库比如Newtonsoft.Json配合HybridCLR会有一些冲突但按官方建议开启SerializationBinder还是能用的。不过为了省事我自己的项目直接改用纯字节数组自定义打包放弃通用Json序列化尤其是热更代码和AOT代码之间传数据时自定义二进制方案最可控性能和兼容性都最好。如果确实要用Json记住一点热更DLL里序列化的类型必须保证字段在AOT侧也被link.xml保留否则反序列化回填字段时会发现字段不存在出现“数据全空但没报错”的诡异问题排查起来特别费劲。6.3 YooAsset的加密与HybridCLR的整体兼容顺序和HybridCLR搭配使用的资源热更方案很多我这边用的是YooAsset。YooAsset支持资源加密本身和HybridCLR不是同一个体系但如果资源热更里有加密的DLL加载顺序就极其重要了。正常流程是YooAsset下载AB包 - 解密AB包 - 得到原始字节数组 - 里面有一个热更DLL文件 - 把这段字节交给HybridCLR加载。YooAsset的加解密流程是在IEncryptionServices接口里实现的你可以在解密时直接返回明文字节数组不需要落盘。然后业务层拿到这个字节数组后再用Assembly.Load(dllBytes)交给HybridCLR。这里有个细节不要在解密时再压缩一层除非你能确保加载HybridCLR前解压回来否则DLL字节数组必须保持PE/ELF格式。我见过一个团队把YooAsset的加密配置文件写错把BsonSerialization当成加密方式启用了导致AB包里的DLL被Bson处理HybridCLR自然加载失败。排查了很久最后才定位到是资源加密配置多开了一层序列化而不是HybridCLR本身的问题。所以无论加密方案是什么最终拿到DLL字节时先写文件到本地用十六进制看文件头是否为4D 5AWindows PE或7F 45 4C 46ELF一眼就能判断格式对不对。6.4 三平台切换时最容易忽略的缓存和版本问题如果项目像我们一样同时面向PC、Android、WebGL三个平台发布还有一个特别容易被忽略的事切换平台后必须重新生成HybridCLR相关数据和YooAsset的Build Bundle。我在之前一次发布中先在Windows平台下Generate了HybridCLR的LinkXml和相关数据然后直接切到Android打包结果打出来的包没有包含Windows下生成的全部AOT泛型元数据导致运行时部分热更功能缺失。后来每次切平台之前都养成一个习惯先执行一次HybridCLR/Generate/All再切Target执行Build。YooAsset也一样不同平台打出的AB包是隔离的切换Target后要重新执行Build Bundle否则加载时会出现AB包版本号对不上的提示。另外记得不同平台下的StreamingAssets目录内容不能直接复用。我在Android端打了测试包切到WebGL时忘了重新把AB包放到StreamingAssets导致WebGL首包里的资源和Android格式不匹配DLL加载直接报错全部白切一次。后来在构建流水线里强制加了平台判断切换Target后自动触发一次资源Build彻底避免了这类低级失误。6.5 Debug和Release还要注意的MetaData大小写问题最后提一个比较隐蔽的坑热更DLL的文件名大小写。HybridCLR加载程序集时会用它内部读取到的程序集名来关联元数据。如果你在Windows下跑文件名大小写不敏感hotupdate.dll和HotUpdate.dll都能加载但你切到Android或WebGL环境时Linux内核和浏览器环境对大小写敏感一旦你AB包里的路径是hotupdate.dll而代码里Load的是HotUpdate.dll就会报找不到程序集。这个问题的排查很简单打开AB包确认DLL文件名严格匹配Assembly.Load时的名称且扩展名统一小写。顺便把热更DLL的AssemblyName属性也统一保证Debug.Log(assembly.FullName)和加载路径完全一致避免运行时大小写不一致导致IDBFS写入和读取时定位不到文件。7. 把三平台的经验落进团队流程里项目做完这个阶段有个很深刻的体会HybridCLR接入本身并不难难的是让整个工程结构、资源加载、平台化构建都适应“热更”这件事的存在。如果项目是在开发中期才接入HybridCLR成本会比从零开始接入高很多因为所有代码分层的假设都要推倒重来。我建议如果团队决定长期走HybridCLR路线下面几个点值得在流程层面固化下来强制代码评审规则Main程序集禁止反向引用HotUpdate程序集新代码默认进热更侧除非是纯工具代码或者跟平台SDK强绑定的封装。构建流水线里加平台切换自检切平台后自动运行HybridCLR Generate和YooAsset Build Bundle失败则构建失败。真机日志统一走文件落盘不管哪个平台日志必须能拉出来复盘不然线上排障等于盲人摸象。link.xml和AOTGenericReferences.cs作为代码文件入库任何新增AOT类型引用都要在Code Review时检查是否漏了link.xml。这里再提一个团队协作中很容易出现的操作盲区如果多人同时开发热更代码HotUpdate.dll的生成必须用构建机统一生成而不是每个开发本地生成后提交。每人电脑上的C#编译器版本、环境变量可能有细微区别生成的DLL虽然功能一样但一旦有人提交了本地生成的DLL另一个人合代码后运行又一切正常——这种“代码一样但DLL不一致”的环境差异会在发版时坑死你。我们的做法是CI机上始终用固定Unity版本执行CompileDll编译产物通过内部文件服务器分发。对于Sequence化那种历史包袱这里也多说一句。如果项目里已经有一批用JsonUtility写得非常重的旧代码我建议分阶段迁移先保证热更业务里的新代码不用JsonUtility老代码在改到的时候顺手替换成自定义二进制或Newtonsoft.Json的AOT兼容版本。不要指望一天全改完但要持续控制走向不然热更方案切换后序列化会成为最薄弱的环节。工具链的稳定性也是被低估的一件事。我见过有人直接在项目里修改HybridCLR源码做二次开发结果升级Unity小版本时源码冲突整个热更链路直接停摆。如果你不是特别需要改HybridCLR内部逻辑建议保持官方版本原样最多做配置层面的定制别去改源码不然后续维护成本会让你崩溃。接入HybridCLR这段时间踩过的坑确实不少从最初的程序集划分到最后的WebGL的IDBFS再到微信小游戏的内存限制每一步都是血泪换出来的经验。不过综合来看这个方案在PC、Android、WebGL三端的表现都称得上合格热更DLL的加载性能和稳定性都达到了我的预期。如果你正打算用HybridCLR或者打包遇到了类似的问题希望这篇能帮你少走几步弯路。我自己的项目现在已经稳定跑在测试环境上了接下来要做的就是把微信小游戏端的构建流程再打磨一遍把自动化出包和线上日志监控补齐毕竟上线之后能折腾我们的只会是更多没见过的未知数。