你们项目提审后第三天运营抛过来一个改动需求某个活动入口的显示逻辑要换还附了一句这个版本必须热更。如果走应用市场审核等一圈下来至少两周黄花菜都凉了。这时候你才会真正意识到Unity项目里如果没有一条稳定的代码热更通道只要代码逻辑需要改就要被审核节奏卡住脖子。Unity热更新方案里ILRuntime是近些年C#团队最顺手的那个选择。它的思路很简单你自己写的C#逻辑编译成普通的DLL程序集运行时交给ILRuntime这个解释器去执行。主工程只保留一个极小的加载框架业务逻辑全部放到热更DLL里上线后通过下载新的DLL就能更新代码。对一套全是C#背景、没人愿意为了热更去啃Lua的团队来说ILRuntime几乎是平滑过渡的默认选项。这篇内容是我自己在项目里从选型、跑通、跨域通信踩坑到最终上线稳定运行的全过程记录。适合刚准备接入热更、团队以C#为主的开发者也适合已经跑通Demo但是在CLR绑定、委托、泛型这些地方反复出问题的朋友。我尽量把当时走的弯路和最后验证过的做法都写清楚。1. 为什么选了ILRuntime热更方案背后的现实权衡1.1 那需求来的时候我们重启了整个技术选型上面提到的活动入口改动只是导火索真正的问题是我们连改一行代码要发版这件事都忍不了。当时项目的技术栈是全C#UI、战斗、玩法、服务端协议全部是C#写的。要接热更第一反应一定是团队里有人喊用Lua吧成熟方案多。但是冷静评估之后发现这件事没有表面看起来那么简单。我们团队的特点是业务开发对C#的熟悉已经到了肌肉记忆的程度让他们突然转Lua先不说语法习惯就是整个编辑器支持、断点调试、服务端复用的那一套都得重新磨合。当时我们统计了一下如果全面转Lua团队的学习成本会让至少一个月的迭代速度明显下降。与其让全员为一个热更能力付出这么大的切换成本不如找一个能保留C#开发体验的方案。1.2 Lua和ILRuntime的核心差异不只是语言习惯很多人会把ILRuntime和Lua放在一起比其实核心差异不在哪个性能强而在业务代码由谁写、用哪种语言写。Lua方案里C#负责框架层Lua负责业务层。你仍然需要维护一整套C#和Lua的交互边界lua调用C#的映射、C#回调Lua的委托、两边的类型转换全都要靠一层胶水代码支撑。而ILRuntime方案里业务层还是C#只是这段C#不在主程序集里而是单独编译成热更程序集由ILRuntime解释执行。团队原有的编码规范、工具链、代码生成那套东西基本可以保留。这里有一个很关键的技术事实Unity的C#代码最终会被编译成中间语言ILILRuntime做的事情就是在运行时把IL解释执行。所以热更程序集本身就是一个普通.NET DLL只不过它不在Unity构建的AOT列表里而是由开发者手动加载。对于纯C#团队来说这是所有热更方案里学习路径最短的一条。1.3 我理解ILRuntime原理的比喻剧本、舞台指令和随身翻译如果非要用一个生活化的类比我觉得它像话剧团临时加戏。主工程和热更DLL的关系好比剧本和演员。你的C#代码是剧本内容编译器把它变成一条条舞台指令IL指令。正常发布时Unity会把所有舞台指令提前准备好演员照着演。但热更场景下新剧本是上线之后才递到现场的Unity这个舞台并不知道。ILRuntime就相当于一个随身翻译把临时拿来的舞台指令一条条念给演员听演员依然按指令行动。这样做的代价是解释执行会比AOT原生代码慢但收益是整个业务逻辑可以脱离平台审核更新。这里我自己的经验是别让热更层承担每帧上万的细粒度计算慢的部分都在可接受范围。我们项目上线后热更逻辑和原生逻辑混跑玩家的体感差异基本没有感受到。2. 跑通最小热更工程两个工程、一个AppDomain2.1 主域工程和热更工程的分工ILRuntime的工程结构入门时最容易懵的一点是要建两个工程一个是Unity里的主工程也就是开发时打开的那个Unity项目另一个是普通类库工程专门用来写热更代码。后者不需要是Unity项目它只是一个.NET类库编译生成我们需要的热更DLL。主工程做的事情只有三个包一个加载框架、初始化ILRuntime的AppDomain、把热更DLL读进来执行。业务逻辑全部放在热更工程里。换句话说主工程越瘦越好瘦到不能再瘦这样以后要改的东西就都落在热更DLL里了。热更工程创建的时候有讲究。在Visual Studio里新建一个类库项目目标框架我建议跟着Unity的API兼容级别走。Unity项目里把Player Settings的Api Compatibility Level设为.NET Framework旧版4.x的时候直接这么选热更工程也对应设置否则引用Unity程序集时容易出现一堆类型不兼容的报错。2.2 让热更工程认识Unity的类型热更工程里要写MonoBehaviour、写GameObject操作但这些类型都来自Unity的程序集。所以需要手动把Unity相关DLL引用进来。在Unity安装目录的Editor/Data/Managed/UnityEngine/下能找到这些DLL。我的做法是引用必要的几个核心模块UnityEngine.CoreModule.dllGameObject、Transform、Component这些基础类型。UnityEngine.dll完整封装入口写了它等于把UnityEngine命名空间整体带进热更工程。如果热更代码里用了UI、物理、音频还要按模块引入对应的程序集比如UnityEngine.UIModule.dll、UnityEngine.PhysicsModule.dll。这里有个容易掉进去的坑不要把整个UnityEngine目录下的DLL全引用进来。你会发现自己照着Unity编辑器里的API写代码编译也能过但运行时却报类型找不到或者程序集冲突。我们后来只引用实际用到的模块干净很多。2.3 编译热更DLL第一次看到Hotfix.dll当热更工程里写了一个入口类比如namespace Hotfix { public static class App { public static void Main() { var obj new GameObject(HelloILRuntime); obj.AddComponentHelloView(); } } }编译一下bin目录下会出现Hotfix.dll和Hotfix.pdb。这个DLL就是以后要热更的内容。开发期测试时我把它们放到Unity项目的StreamingAssets目录下这样运行期可以直接从本地路径读到。正式上线时这两个文件会被打成AssetBundle放进CDN。这一步看起来简单但是耐心把这个链路跑通非常重要。我第一次接触ILRuntime时就是犯了直接在Unity主工程里写热更代码的错误结果以为字面意义上的热更就是多加一个DLL引用。还好在别踩坑的教程里看到热更代码必须编译成独立程序集并且主工程不直接静态引用它理清了之后整个模型都顺了。2.4 AppDomain的初始化和加载接下来是主工程侧的初始化。ILRuntime的运行时核心是ILRuntime.Runtime.Enviorment.AppDomain对象所有热更程序集都由它管理而不是由Unity的Mono或IL2CPP直接管理。加载DLL的核心代码如下我加上当时调通后的注释using UnityEngine; using ILRuntime.Runtime.Enviorment; using System.IO; public class HotfixLauncher : MonoBehaviour { private AppDomain domain; void Start() { domain new AppDomain(); byte[] dllBytes; byte[] pdbBytes; #if UNITY_EDITOR string dllPath Path.Combine(Application.streamingAssetsPath, Hotfix.dll); string pdbPath Path.Combine(Application.streamingAssetsPath, Hotfix.pdb); dllBytes File.ReadAllBytes(dllPath); pdbBytes File.Exists(pdbPath) ? File.ReadAllBytes(pdbPath) : null; #else // 正式环境从AssetBundle里读取Hotfix.bytes和Hotfix.pdb.bytes dllBytes LoadBytesFromAB(hotfix.dll); pdbBytes LoadBytesFromAB(hotfix.pdb); #endif using (var dllStream new MemoryStream(dllBytes)) using (var pdbStream pdbBytes null ? null : new MemoryStream(pdbBytes)) { domain.LoadAssembly(dllStream, pdbStream, new Mono.Cecil.Pdb.PdbReaderProvider()); } domain.Initialize(); domain.Invoke(Hotfix.App, Main, null, null); } }解释一下这段里几个关键点LoadAssembly接收的是DLL和PDB两个流。PDB只在调试时有意义Release的包可以只传DLL传null也行。但开发期一定要带上PDB否则后面排查异常堆栈会艰难很多。Initialize()这一步不能省它负责完成运行时环境的初始化包括把CLR绑定、委托注册这些在读取程序集前缓存的东西正式激活。Invoke(Hotfix.App, Main, null, null)等价于调用热更程序集里的Hotfix.App.Main()静态方法。第一个参数是类的完整名字第二个是方法名第三个是实例对象静态方法传null第四个是参数数组。2.5 从主域发起第一次调用后的排查思路跑通这一步之后你会看到场景里出现了一个名为HelloILRuntime的GameObject说明热更代码已经执行成功了。但如果启动时卡在这一步常见的原因有两个一是命名空间写错。热更工程里的namespace是Hotfix类名是App完整名称就是Hotfix.App。如果你在类库项目里随手改成了其他命名空间Invoke时就必须严格对应。二是程序集没有正确加载。ILRuntime加载的是流不是文件路径。如果你直接传了Application.streamingAssetsPath /Hotfix.dll这个字符串给LoadAssemblyMono.Cecil会报模块不存在之类的错误。我第一次就是这么干的折腾了半小时才反应过来它要的是MemoryStream。3. 跨域通信这堵墙CLR绑定、委托注册和继承替代3.1 为什么大家总说跨域调用很贵跑通Hello World之后下一步要面对的就是主域和热更域的关系。主域就是Unity自带程序集跑的环境热更域则是ILRuntime创建的那个AppDomain。两者之间有一个默认的防火墙跨过去的方式只有通过AppDomain提供的能力。每次从主域调用热更代码相当于跨过一次边界ILRuntime要把参数、返回值都做类型兼容处理这个过程肯定比直接函数调用贵。所以第一原则是能一次把一批数据传过去就不要一千次传一个参数。具体到工程上就是尽量减少主域与热更域之间的方法调用频次。比如每个Update帧都去热更域里某个类拿一个状态值这是很浪费的。我们后来把状态汇总做成每帧只调用一次的方法让热更层遍历自己的对象返回汇总结果开销一下就降下来了。3.2 CLR绑定到底解决了什么问题CLR绑定是ILRuntime里绕不开的机制。它的作用是把Unity框架提供的海量类型提前介绍给ILRuntime避免热更代码每次调用Unity原生接口时都走反射。在编辑器菜单里找到ILRuntime → Generate CLR Binding Code一键生成绑定代码。生成的代码会放到一个独立的目录比如Assets/ILRuntime/Generated这些代码必须打在主包里。我见过很多新人问不生成行不行答案是可以运行但性能和兼容性都没有保证。尤其是iOS平台启用IL2CPP后热更代码用到的Unity类型如果没有提前绑定可能直接出现类型缺失。我们当时的做法是把所有热更代码用到的Unity常见类型整理一遍然后生成全套绑定代码。这个操作不会让热更DLL变大但会让运行时更稳。3.3 委托不能直接new注册一把钥匙热更代码里有时需要把回调传给主域比如按钮点击后通知主域的UI管理器。在ILRuntime里跨域的委托不能直接在热更侧new Action(...)然后用普通方式传出去编译器通常不会报错但运行时它会抱怨找不到对应的委托适配器。解决方法是在主域初始化后注册Delegate。domain.DelegateManager.RegisterDelegateConvertorUnityEngine.Events.UnityAction((action) { return new UnityEngine.Events.UnityAction(() action()); });这个做法的本质是告诉ILRuntime当热更域想要把一个方法包装成UnityAction时用我提供的这个转换器你就知道怎么处理了。否则ILRuntime不知道你的委托具体要怎么落地。更大的教训是跨域委托尽量用简单签名。参数多、返回值复杂、还有out/ref的委托容易翻车也不利于性能。我们后来统一规范跨域回调一律int或string类型参数复杂数据单独走一个传输对象。3.4 MonoBehaviour不能直接在热更域里继承这是我刚接入时最大的认知误区。我以为热更DLL里写的类可以直接继承MonoBehaviour然后AddComponent上去让Unity管理生命周期。实际上不行——因为AddComponent要求类型必须存在于当前运行程序集里而热更DLL里的类型对于Unity主域来说是外来的Unity根本识别不了。正确的替代方案是代理组件模式。主域里写一个非常薄的MonoBehaviour脚本它的Update、Start、OnDestroy方法转调热更域里对应的逻辑类。public class HotfixHost : MonoBehaviour { private HotfixApp logic; void Start() { logic new HotfixApp(); logic.OnStart(); } void Update() { if (logic ! null) { logic.OnUpdate(); } } }这样一来Unity的生老病死生命周期由主域的透明组件看着热更域里就是一个普通C#对象自己管理状态。我们团队后来把这种代理模式扩展成了统一的组件基类所有需要挂到场景里的逻辑都这么接开发规范性一下子提高了。4. 从Debug到Release五个最消耗时间的实测坑4.1 打断点没反应先检查你是不是Debug版接入ILRuntime后很多人的第一反应是用Visual Studio给热更代码打断点。如果你下载的是官方Release版本运行库你会发现断点根本不会命中。原因是正式发布版运行库裁剪掉了调试支持只有当使用Debug分支的ILRuntime源码时才允许附加调试器。我当时是把ILRuntime的源码直接放进项目工程里编译这样既能断点也能查看实时变量。如果你用的是NuGet包或者纯DLL建议单独确认一下当前版本是不是Debug构建。开发阶段多花点时间把调试环境搭好后面排查问题的效率完全不一样。有一个实用性很高的技巧开发期让热更DLL从本地文件读打Release时再从AssetBundle读中间用宏做一个分支。这样既能保证开发效率又不影响线上流程。4.2 值类型List 变慢性能检查从Profiler开始性能问题是接入任何热更方案都会遇到的。ILRuntime在解释执行层面的确比原生代码慢但慢不代表不能用。我们当时用一个实际案例测试过热更域里每帧给一个ListVector3里Add数据Profiler显示这一行占用的耗时比原生高了非常多。原因本身不复杂Vector3是值类型解释器处理值类型时要经历装箱、拆箱或按值复制等一系列额外操作远比引用类型费劲。如果这个List里还涉及接口调用情况会更糟。我们最终的优化方式有两个方向改用数组。定长的Vector3[]比List这类动态结构在ILRuntime下友好很多。给Vector3写Adaptor让解释器知道怎么高效处理这个值类型。ILRuntime文档里有现成的Adaptor方案照着注册就行。调完之后性能开销基本回到一个可以接受的范围。只要你记住热更层尽量别做大流量的值类型计算大部分性能问题都不会真的成为问题。4.3 MissingMethod报错泛型方法需要包装运行期你可能会看到这样的报错MissingMethod: GetComponentT in UnityEngine...。明明Unity里早就有这个方法热更代码也写对了但就是找不到。这是ILRuntime的经典坑之一泛型方法在解释执行时的解析逻辑和原生环境不一致。你的GetComponentAnimator()这种泛型调用对ILRuntime来说有时就是解析不到具体的方法实现。我的处理模式是在主域里写一个非泛型的包装方法public static Animator GetAnimator(GameObject obj) { return obj.GetComponentAnimator(); }然后在热更代码里不直接调泛型改成调用这个非泛型接口。这个方法看起来很笨但在ILRuntime下是稳定可靠的。团队后来定了个规范热更层禁止直接调用泛型Unity API需要用到的统一进主域包装。4.4 JsonUtility序列化结果不对绕开热更域的序列化边界热更层要保存玩家数据常规想法是直接调用JsonUtility.SerializeObject。实际跑起来你可能遇到两种表现要么返回空字符串要么抛出不支持该类型的异常。JsonUtility在设计上依赖Unity的底层序列化机制而热更DLL里的类型在Unity看来不是原生可序列化的。解决办法同样是桥接在主域里写一个序列化工具类热更代码把一个普通对象传过去由主域来执行JsonUtility调用然后把结果字符串传回热更域。这一步不解决的话后面每一次存档都会出鬼。特别是当你把存档数据放到热更层之后再去主域做版本兼容时坑会连环爆。我建议在一开始就要把热更层的可序列化类型约束成简单数据类型复杂对象跨域前统一转成字符串或byte[]。4.5 报错里出现not clr bind时的标准处理流程运行时你可能会碰到类似Type XXX is not clr bind的报错。意思很直白这个Unity类型还没有被CLR绑定登记ILRuntime不认识它。这时代码本身没错问题出在绑定遗漏。处理流程基本固定回到编辑器的ILRuntime菜单重新生成绑定代码确认这个类型出现在生成的代码里如果没有需要手动补充绑定文件生成完成后重新打一个主包再把这个主包部署到测试机。这个流程在开发期反复出现是正常的尤其是UI模块改动频繁时。所以我建议别在绑定的关键路径上省事每次新增模块先提前生成好绑定能大幅减少运行期遇到not clr bind的机会。5. 从Demo到线上热更运营DLL版本、API冻结与性能预算5.1 热更DLL的打法AssetBundle、版本号和回滚预案Demo阶段把DLL放StreamingAssets就够了但真要上线热更DLL必须跟着资源走。我们的做法是把Hotfix.dll和Hotfix.pdb打包成AssetBundle命名为hotfix_版本号.unity3d上传到CDN。客户端启动时先检查本地版本号和服务端版本号不一致就下载新的AB包。这里一定要考虑回滚预案。新DLL假如引发兼容性问题服务端要能下发一个旧的版本号让客户端退回到上一个稳定DLL。我们当时在配置中心做了个热更版本白名单服务端可以随时切换允许的版本号。这件事听起来简单但没有预案的话一个更新可能就把整个线上版本卡死。5.2 接口冻结规则只能加、不能改热更新的大坑在于一旦主域已经打进了玩家设备主域代码就固定了不能再动。热更DLL虽然可以随时换但它调用的主域公开接口必须是早已打进包里的。这就是所谓的API冻结。主域暴露给热更域的公共方法、类、常量上线后就不能改动签名了。哪怕你只是给方法增加一个可选参数也可能影响已经下载了旧热更包的玩家的兼容性。我们的规矩是新功能优先新增方法不改旧方法签名。旧方法要淘汰时先保留半年再想办法做版本检测。每次打正式包前导出一份主域热更接口清单跟着版本走。这个规矩很土但特别管用。很多跑着跑着出现昨天还好好的今天热更后全崩了的问题九成是接口兼容性被打破了。5.3 日志和异常堆栈要提前铺好热更代码上线后你没法直接打开用户的编辑器逐行看。所以日志采集是最重要的基础设施之一必须放在主域里让热更域把日志通过一个简单的跨域调用发给主域主域再统一上报到日志平台。同时要给热更域加一个全局异常处理器。ILRuntime允许监听运行时异常把堆栈打出来。Debug版本下堆栈信息非常完整甚至可以定位到热更代码的具体行号。这些信息采集好了之后线上排查问题的效率会高很多。我建议在正式包发布前做一次拔线测试故意在热更代码里抛一个空引用异常看日志平台能不能收到完整的堆栈。如果这一步有问题整个线上排障体系就是空的。5.4 热更层的性能预算表最后聊性能预算。ILRuntime的性能消耗是有上限的不是说你愿意牺牲就能无限压。我们团队定了一张表写进开发规范逻辑类型放置位置原因每帧高频率的物体遍历主域解释执行高频循环开销放大明显战斗中的伤害计算主域数值量级大需要精确可控UI事件响应热更域低频、可热更、迭代频繁系统初始化流程热更域一次性的逻辑性能影响很小复杂物理计算主域需要调用原生物理模块且避免跨域开销策划数值配置读取热更域数据量不大迭代频繁适合热更这张表的意义是让每个开发成员在写代码时有明确的归属感。这段逻辑为什么放在主域比你觉得哪里性能不好放哪里更容易落地。我最后的体会是ILRuntime绝不复杂真正复杂的从来都是什么时候不该跨域和什么时候不该热更。团队只要能想清楚这两件事ILRuntime的接入成本和长期维护成本都不会失控。再多说一个小技巧热更工程里不要急着把Unity所有模块引用进来让IDE的基础提示保持在最小集反而能逼着你养成主域清瘦、热更纯业务的好习惯。