1. 项目概述为什么Unity开发者绕不开热更新如果你是一个Unity开发者尤其是做移动端游戏的那么“热更新”这个词对你来说绝对不陌生。它几乎是项目上线后应对线上Bug、调整游戏平衡、甚至推出新内容的唯一高效手段。想象一下你的游戏刚上线玩家反馈了一个致命的闪退Bug如果走传统的应用商店更新流程从打包、提交审核到玩家下载安装短则一两天长则一周这段时间的差评和用户流失足以让一个项目伤筋动骨。而热更新就像给游戏装上了“在线手术刀”无需玩家重新下载安装包就能在运行时动态修复问题、更新逻辑和资源把损失降到最低。在Unity的热更新方案中ILRuntime是一个极具分量的选择。它不是一个简单的脚本解释器而是一个纯C#实现的、高性能的运行时环境。它的核心魅力在于能让你的热更代码通常打包成DLL与Unity主工程的原生C#代码进行几乎无缝的交互。这意味着你不需要像使用Lua那样为每一个需要暴露给热更层的C#类或方法都写一层繁琐的绑定代码。你可以直接引用、继承、甚至重写主工程里的类当然需要遵循一定的规则开发体验非常接近原生C#开发这对于习惯了强类型和IDE智能提示的C#程序员来说简直是福音。我经历过从早期自己折腾Lua绑定到后来尝试各种热更方案的阶段最终在几个中型项目里落地了ILRuntime。选择它不仅仅是看中了“无缝访问C#工程”的宣传语更是因为在实战中它在开发效率、执行性能和团队协作成本之间找到了一个很好的平衡点。当然这条路也不是铺满鲜花从环境搭建、代码分割到真机调试、性能优化每一步都有需要特别注意的“坑”。这篇教程我就以一个完整的、可运行的C#项目实战为例带你从零开始把ILRuntime热更新的核心流程走通并分享那些官方文档里不会写的实操心得和避坑指南。2. 环境准备与项目初始化2.1 核心工具与版本选择工欲善其事必先利其器。在开始之前我们得先把“兵器”准备好。这里的选择至关重要版本不匹配是新手踩坑的重灾区。首先是Unity版本。ILRuntime对Unity版本有一定要求建议使用Unity 2018.4 LTS或更新版本我个人更推荐2020.3 LTS或2021.3 LTS这些长期支持版它们在稳定性和对.NET Standard 2.0/2.1的支持上做得更好。我们这次实战以Unity 2021.3 LTS为例。确保你的Unity安装时包含了“Windows Build Support (IL2CPP)”或对应的平台模块因为ILRuntime热更的最终产出需要IL2CPP后端支持。其次是Visual Studio。你需要一个完整的C#开发环境推荐使用Visual Studio 2019或2022并确保安装了“.NET桌面开发”和“使用Unity的游戏开发”工作负载。ILRuntime的热更代码本质上是标准的C#类库.NET Standard 2.0需要用VS来编译成DLL。最后是ILRuntime本体。不要从Asset Store下载那个可能过时的版本。最稳妥的方式是访问ILRuntime的GitHub仓库https://github.com/Ourpalm/ILRuntime直接下载最新的Release包或者Clone源码。将下载的ILRuntime文件夹里面包含ILRuntime.dll,ILRuntime.Mono.Cecil.dll等复制到你的Unity项目的Assets/Plugins目录下。如果项目没有Plugins文件夹就创建一个。注意千万不要把ILRuntime的源码放在Assets/Scripts这样的脚本目录下一定要放在Plugins里。因为Unity对Plugins目录下的DLL处理方式不同能确保其在所有脚本编译之前就被加载这是ILRuntime正常工作的前提。我见过好几个团队因为放错了位置导致各种诡异的“类型找不到”错误。2.2 创建双工程结构ILRuntime热更新的核心思想是“代码分割”。我们需要将代码明确分为两部分主工程代码不可热更和热更工程代码可热更。最清晰的做法就是建立两个独立的Visual Studio项目。在你的项目目录下比如D:\MyUnityGame创建如下结构MyUnityGame/ ├── UnityProject/ (你的Unity工程文件夹) │ ├── Assets/ │ │ ├── Plugins/ (存放ILRuntime运行时库) │ │ └── ... │ └── ... └── HotfixProject/ (热更代码工程文件夹) ├── Hotfix.csproj └── ...创建热更工程打开Visual Studio新建一个“类库(.NET Standard)”项目命名为Hotfix目标框架选择.NET Standard 2.0这是关键不要选.NET Framework或.NET Core。将这个项目的物理位置创建在上述的HotfixProject文件夹内。配置主工程引用可选但推荐为了让主工程能方便地调用热更工程里定义的一些接口或基类后面会讲到你可以在Unity工程中右键Assets-Create-Assembly Definition创建一个名为GameMain的程序集。然后在这个程序集定义的Inspector面板中在Assembly Definition References里添加对Hotfix工程输出的DLL的引用需要先编译一次Hotfix工程生成DLL。但这步不是必须的初期可以跳过专注于热更工程本身的编译。这个双工程结构的好处是职责分离清晰。主工程负责引擎初始化、不可热更的核心框架和资源管理热更工程则专注于游戏逻辑随时可以独立编译、打包、更新。3. 热更新核心原理与代码分割策略3.1 ILRuntime是如何工作的在深入写代码前我们花点时间理解一下ILRuntime在背后做了什么。这能帮你更好地理解后续的那些“规则”和“限制”。Unity的常规编译流程是你的C#脚本被编译成.NET的中间语言IL在编辑器下由Mono虚拟机执行打包时尤其是移动平台则由IL2CPP转换成C代码再编译成原生二进制文件。一旦打包完成这些代码就“焊死”在应用里了。ILRuntime引入了一个额外的运行时它自己实现了一个轻量级的、兼容.NET的虚拟机解释器。你的热更代码Hotfix工程被编译成一个独立的DLL比如Hotfix.dll。游戏启动时ILRuntime会加载这个DLL文件可以从服务器下载也可以放在StreamingAssets里然后用自己的解释器来逐条执行这个DLL中的IL指令。关键在于“交互”。当热更DLL中的代码需要调用Unity的API比如GameObject.Find,Debug.Log或者主工程里定义的类时ILRuntime并不是直接去调用而是通过一个“适配器”层AppDomain来进行转接。它内部维护了一套映射关系把热更DLL中的类型引用对应到主工程的实际类型上。这就是为什么它能做到“无缝访问”因为所有访问都经过了一层代理和封装。但是这种“无缝”是有条件的。因为两个世界主工程原生世界和热更解释世界是隔离的数据的传递、尤其是跨世界的委托delegate调用和继承需要遵循特定的规则否则就会导致崩溃或者行为异常。理解这个“两个世界”的模型是避免后续很多坑的基础。3.2 代码分割什么能热更什么不能这是设计阶段最重要的决策直接决定了项目的可维护性和热更能力。原则其实很简单所有需要跟随热更DLL一起更新和替换的代码都应该放在热更工程里所有希望保持稳定、作为热更基石的部分则放在主工程。必须放在主工程不可热更的引擎和第三方插件入口所有直接继承自MonoBehaviour、ScriptableObject的类如果它的挂载对象存在于初始包内的场景或资源中那么它本身必须不可热更。因为Unity在反序列化场景和预制体时需要根据序列化信息找到确切的类定义。框架核心与基础服务如网络管理器、资源加载器Addressables/AssetBundle管理、配置表读取器、声音管理器等。这些是游戏的“基础设施”我们希望它们稳定。热更新管理器本身负责加载、初始化ILRuntime、下载和加载热更DLL的代码必须放在主工程。你不能指望用一个还没加载的热更系统来加载它自己。通用的、稳定的数据结构与接口定义一些抽象类或接口作为主工程和热更工程之间的“契约”。例如定义一个IHotfixWindow接口在主工程热更工程里的具体UI窗口去实现它。可以且应该放在热更工程可热更的具体的游戏逻辑角色的技能计算、任务系统、剧情对话、商店购买逻辑等。UI控件的表现层逻辑虽然UI预制体本身可能作为资源热更但绑定在预制体上的、继承自MonoBehaviour的脚本不能直接热更。这里的通用做法是在主工程有一个通用的UIBehaviour脚本它持有一个热更工程里定义的逻辑类对象。UIBehaviour只负责转发消息如Start,OnClick给热更逻辑对象去处理。配置数据解析与运行时对象从服务器下载的配置表在热更工程里解析成运行时使用的类对象。临时性的算法和数值平衡所有需要频繁调整的部分。一个常见的架构是主工程提供“舞台”和“工具箱”框架、组件、接口热更工程提供“演员”和“剧本”具体逻辑。演员按照剧本在舞台上表演剧本可以随时更换。4. 实战构建第一个可热更的Hello World4.1 步骤一编写热更工程代码让我们从最简单的开始。在Hotfix工程中我们创建一个新的C#类文件命名为HelloWorld.cs。// Hotfix工程中的 HelloWorld.cs using System; using UnityEngine; // 注意这里可以引用UnityEngine namespace MyGame.Hotfix { public class HelloWorld { public static void SayHello() { Debug.Log([Hotfix] Hello, World! This message is from HOTFIX DLL!); } public int Add(int a, int b) { return a b; } } }编译这个Hotfix工程你会在它的输出目录通常是bin/Debug/netstandard2.0/下得到Hotfix.dll文件。把它复制到Unity工程的Assets/StreamingAssets文件夹下如果没有就创建一个。StreamingAssets里的文件在打包后会原封不动地包含在应用里方便我们首次测试。4.2 步骤二在主工程中初始化ILRuntime并调用回到Unity主工程。我们需要一个脚本来启动ILRuntime。在主工程的Assets/Scripts下创建ILRuntimeManager.cs。// 主工程中的 ILRuntimeManager.cs using System.IO; using UnityEngine; using ILRuntime.Runtime.Enviorment; using ILRuntime.Runtime.Generated; public class ILRuntimeManager : MonoBehaviour { private AppDomain _appDomain; private MemoryStream _dllStream; private MemoryStream _pdbStream; // 用于调试的符号文件流 void Start() { StartCoroutine(LoadHotfixAssembly()); } System.Collections.IEnumerator LoadHotfixAssembly() { // 1. 从StreamingAssets加载热更DLL string dllPath Path.Combine(Application.streamingAssetsPath, Hotfix.dll); string pdbPath Path.Combine(Application.streamingAssetsPath, Hotfix.pdb); // 如果有pdb文件 // 注意在Android/iOS上Application.streamingAssetsPath是只读的需要用UnityWebRequest加载 // 这里为了简化假设在Editor或PC平台 byte[] dllBytes File.ReadAllBytes(dllPath); _dllStream new MemoryStream(dllBytes); if (File.Exists(pdbPath)) { byte[] pdbBytes File.ReadAllBytes(pdbPath); _pdbStream new MemoryStream(pdbBytes); } // 2. 初始化ILRuntime AppDomain _appDomain new AppDomain(); try { // 3. 加载程序集 if (_pdbStream ! null) { // 加载DLL和PDB允许调试 _appDomain.LoadAssembly(_dllStream, _pdbStream, new ILRuntime.Mono.Cecil.Pdb.PdbReaderProvider()); } else { // 仅加载DLL _appDomain.LoadAssembly(_dllStream); } Debug.Log(Hotfix Assembly Loaded Successfully!); // 4. 这里非常重要注册跨域适配器。 // 为了简化我们先不注册但实际项目必须注册。下文会详述。 // ILRuntime.Runtime.Generated.CLRBindings.Initialize(_appDomain); // 5. 调用热更DLL中的方法 InvokeHotfixMethod(); } catch (System.Exception e) { Debug.LogError($Load Hotfix Assembly Failed: {e}); } finally { // 6. 清理流加载后AppDomain内部会持有数据流可以关闭 _dllStream?.Close(); _pdbStream?.Close(); } } void InvokeHotfixMethod() { // 通过AppDomain调用热更DLL中的静态方法 // 第一个参数是类型全名命名空间类名第二个参数是方法名第三个是对象实例静态方法为null第四个是参数数组 _appDomain.Invoke(MyGame.Hotfix.HelloWorld, SayHello, null, null); // 调用实例方法 object instance _appDomain.Instantiate(MyGame.Hotfix.HelloWorld); int result (int)_appDomain.Invoke(MyGame.Hotfix.HelloWorld, Add, instance, new object[] { 5, 3 }); Debug.Log($Hotfix Add Result: {result}); } }将这个脚本挂载到场景中的一个GameObject上比如Main Camera。运行Unity你应该能在Console中看到来自热更DLL的日志输出和计算结果。实操心得第一次成功调用热更代码的感觉很奇妙但这只是万里长征第一步。上面的代码为了演示省略了最关键的一步——CLR绑定跨域适配器注册。在我们这个简单例子中热更代码调用了Debug.Log这是一个UnityEngine的API属于“主工程世界”。ILRuntime需要知道如何正确地在两个世界间传递这个调用。如果没有注册适配器在真机IL2CPP环境下这种调用很可能会失败或导致崩溃。我们接下来就解决这个问题。5. 跨越世界的桥梁CLR绑定与适配器生成5.1 为什么需要CLR绑定如前所述主工程和热更工程是两个隔离的运行时环境。当热更代码尝试做以下事情时就需要特别的处理绑定继承热更类继承自主工程类或接口。委托将热更方法作为委托传递给主工程或者反过来。值类型传递跨域传递结构体struct如Vector3、Quaternion。调用基类/接口方法热更类调用其继承自主工程基类的方法。如果没有绑定ILRuntime会使用反射来尝试处理这些交互这在开发阶段Mono后端可能工作但在发布版IL2CPP下由于代码被静态编译和裁剪反射信息可能丢失从而导致运行时错误。CLR绑定就是预先为这些交互生成高效的“胶水代码”避免运行时反射保证性能和稳定性。5.2 自动生成绑定代码ILRuntime提供了一个强大的工具来帮我们生成这些绑定代码。在Unity编辑器中找到菜单栏Window - ILRuntime - Generate CLR Binding Code。点击后会弹出一个窗口。你需要指定Generated Code Path生成的绑定代码存放路径。通常放在Assets/ILRuntime/Generated下。Additional DLL Paths除了当前项目程序集还需要为哪些外部DLL生成绑定。通常需要添加UnityEngine.dll、UnityEngine.CoreModule.dll等。你可以点击“”号在Unity安装目录和项目Library中寻找。然后点击“Generate”按钮。这个过程会分析你指定的程序集为其中所有公共的类型、方法、字段等生成适配器代码。生成的文件可能很多主要是大量的*_Adapter.cs和*_Binder.cs文件以及一个关键的CLRBindings.cs文件。5.3 注册绑定生成完毕后我们需要在初始化ILRuntime时注册这些绑定。修改之前的ILRuntimeManager.cs// 在 _appDomain.LoadAssembly(...) 之后调用热更方法之前添加 ILRuntime.Runtime.Generated.CLRBindings.Initialize(_appDomain); // 此外对于常用的Unity委托如UnityAction、UnityEvent也需要手动注册一次 _appDomain.RegisterCrossBindingAdaptor(new MonoBehaviourAdapter()); // 如果你的热更代码里用到了Coroutine还需要注册协程适配器 _appDomain.RegisterCrossBindingAdaptor(new CoroutineAdapter());现在再运行程序热更代码对Debug.Log的调用就有了正式的“通行证”在IL2CPP环境下也能安全执行了。注意事项CLR绑定生成并不是一劳永逸的。每当你的主工程中有新的类型、方法需要被热更代码跨域调用或继承时你都需要重新生成CLR绑定代码。一个良好的实践是在每次发布版本前或者主工程框架有较大更新后重新生成一次绑定。同时生成的绑定代码文件数量很多建议使用版本控制工具如Git的.gitignore文件忽略Assets/ILRuntime/Generated目录只将生成脚本如CLRBindings.cs纳入版本管理因为生成的文件在不同机器上可能略有差异。6. 热更工程与主工程的深度协作模式6.1 通过接口与抽象类定义契约单纯的静态方法调用实用性有限。更常见的模式是主工程定义好框架和接口热更工程提供具体实现。例如主工程定义一个UI窗口的接口// 主工程IUIWindow.cs public interface IUIWindow { string WindowName { get; } void OnCreate(GameObject root); // root是UI预制体的根节点 void OnShow(); void OnHide(); void OnUpdate(float deltaTime); }然后在主工程中有一个UIManager它负责加载UI预制体作为AssetBundle资源并挂载一个通用的UIWindowBridge脚本。这个脚本的职责是从热更DLL中实例化一个实现了IUIWindow接口的对象并转发所有生命周期调用。在热更工程中我们实现具体的窗口逻辑// 热更工程LoginWindow.cs public class LoginWindow : IUIWindow // 实现主工程定义的接口 { public string WindowName Login; private GameObject _uiRoot; private Text _txtTitle; // 假设这是UI上的一个Text组件 public void OnCreate(GameObject root) { _uiRoot root; _txtTitle _uiRoot.transform.Find(TitleText).GetComponentText(); // 为按钮绑定事件这里需要用到委托跨域适配 var btn _uiRoot.transform.Find(LoginButton).GetComponentButton(); btn.onClick.AddListener(OnLoginButtonClicked); } private void OnLoginButtonClicked() { Debug.Log(Hotfix: Login button clicked!); // 调用热更里的网络请求逻辑... } public void OnShow() { _txtTitle.text 欢迎登录 (Hotfix); } public void OnHide() { } public void OnUpdate(float deltaTime) { } }这样UI的资源Prefab和表现逻辑脚本就完全分离了。我们可以单独更新热更DLL来改变登录窗口的行为甚至替换整个窗口的逻辑而无需动主工程和UI资源除非UI布局大变。6.2 处理委托与事件委托和事件的跨域调用是另一个需要小心处理的地方。假设主工程有一个事件中心热更模块需要订阅事件。在主工程定义事件// 主工程EventCenter.cs public class EventCenter { // 定义一个接受string参数的事件 public static event Actionstring OnMessageReceived; public static void TriggerMessage(string msg) OnMessageReceived?.Invoke(msg); }在热更工程中不能直接使用来订阅因为这是一个跨域的委托。我们需要使用ILRuntime提供的appDomain的委托转换方法。首先确保为System.Actionstring生成了CLR绑定。然后在热更代码中// 热更工程SomeHotfixClass.cs public void SetupEventListeners(AppDomain appDomain) { // 将热更世界的方法转换为可供主世界调用的委托 Actionstring hotfixAction new Actionstring(OnMessageFromMain); // 通过AppDomain进行委托转换 System.Delegate convertedDelegate appDomain.DelegateManager.ConvertDelegate(hotfixAction); // 订阅事件 EventCenter.OnMessageReceived (Actionstring)convertedDelegate; } private void OnMessageFromMain(string message) { Debug.Log($Hotfix received: {message}); }这个过程确保了委托调用在跨越两个世界时的类型安全和正确性。对于系统自带的常用委托如UnityAction,UnityEventILRuntime已经提供了适配器注册后可以像在普通C#中一样使用和-但为了绝对可靠了解其底层机制是必要的。7. 打包、部署与动态更新流程7.1 编译与打包热更DLL开发完成后你需要将热更工程编译成DLL并准备好更新。编译Release版本在Visual Studio中将Hotfix工程的配置从Debug切换到Release然后重新生成。Release版本去除了调试符号体积更小且可能经过编译器优化。处理依赖检查Hotfix工程是否引用了其他第三方DLL比如Json.NET用于解析配置。如果有这些DLL也需要一并打包进热更包。一个简单的做法是将这些依赖DLL的“复制本地”属性设为True它们就会出现在输出目录和Hotfix.dll在一起。制作热更包通常你不会只更新一个DLL。你会将本次热更需要的所有文件Hotfix.dll、依赖的DLL、可能更新的配置表、AB包清单等打包成一个压缩文件如ZIP并计算一个版本号或MD5哈希值。7.2 设计更新流程一个健壮的热更新流程通常如下版本检查游戏启动后主工程代码向服务器请求一个版本配置文件version.json里面包含了当前最新热更包的版本号和下载地址。对比版本与本地存储的已下载热更包版本进行对比。如果服务器版本更新则进入更新流程。下载热更包从服务器下载ZIP包到设备的持久化数据路径Application.persistentDataPath。务必使用断点续传和校验机制比对MD5。解压与替换下载完成后解压ZIP包将文件主要是新的Hotfix.dll覆盖到热更代码的加载目录通常是Application.persistentDataPath下的某个子目录。重新加载游戏重启或触发一个重新加载的入口主工程的ILRuntimeManager从新的路径加载热更DLL完成更新。实操心得永远要有回滚机制。在覆盖旧DLL之前先备份。如果加载新的热更DLL失败比如出现异常要能自动回退到上一个稳定版本。可以在本地存储两个版本的热更DLL用一个标志位记录当前生效的是哪个。此外第一次打包时可以将一个基础的、稳定的热更DLL放在StreamingAssets作为默认版本确保游戏在没有网络的情况下也能运行。7.3 真机调试技巧调试热更代码是开发中的难点。ILRuntime支持通过Visual Studio进行真机远程调试但配置稍显繁琐。生成调试符号编译Hotfix工程时使用Debug配置并确保生成PDB文件。启用ILRuntime调试在初始化AppDomain时使用加载PDB文件的代码路径如前面示例所示。启动调试服务器在Unity编辑器中点击Window - ILRuntime - Attach to ILRuntime Debugger。这会在本地启动一个调试服务器。连接真机将真机与PC置于同一局域网。在真机运行的游戏初始化ILRuntime后需要以某种方式比如通过一个调试UI按钮触发连接PC的调试服务器。这通常需要你在热更代码里调用appDomain.DebugService.StartDebugService(56000)56000是默认端口。附加进程在Visual Studio中使用“附加到进程”功能选择Unity进程进行调试。如果一切顺利你可以在热更代码中设置断点并命中。这个过程网络因素影响大不稳定。因此更常见的做法是将关键逻辑在Unity Editor下充分测试ILRuntime在Editor下以Mono模式运行可以直接调试然后通过详尽的日志系统来排查真机问题。在热更代码中植入一个灵活的日志开关根据不同环境输出不同级别的日志是更实用的调试手段。8. 性能优化与常见问题排查8.1 性能优化要点ILRuntime虽然性能优于很多纯解释型方案但相比原生C#仍有损耗。在性能敏感处需注意减少跨域调用每一次从热更代码调用主工程方法或反之都有一定的开销。避免在循环内进行高频的跨域调用。例如如果需要获取多个物体的位置尽量一次传递一个数组或列表而不是在循环中多次调用Transform.position。值类型struct的装箱跨域传递值类型如int,float,Vector3可能引起装箱拆箱。对于Vector3这类常用结构体ILRuntime的CLR绑定会生成优化代码但自定义的结构体需要注意。委托缓存对于需要重复使用的跨域委托比如事件回调应该在初始化时转换并缓存起来而不是每次调用都重新转换。避免反射在热更代码内部也应避免使用C#反射因为ILRuntime内部可能仍需解释执行反射操作代价很高。热更代码质量热更DLL本身的代码质量同样影响性能。避免不必要的内存分配、使用对象池、优化算法等通用优化准则依然适用。8.2 常见问题排查表下表罗列了ILRuntime使用中最常见的一些错误、可能原因及解决方法现象/错误信息可能原因排查与解决方法TypeLoadException或找不到类型1. 热更DLL与主工程使用的Unity版本或第三方DLL版本不一致。2. 未生成或未注册该类型的CLR绑定。3. 热更代码引用了主工程中不存在或被裁剪掉的类型。1. 确保热更工程与主工程引用相同版本的Unity程序集和第三方库。2. 重新生成并注册CLR绑定代码。3. 检查主工程的link.xml文件确保所需类型不被IL2CPP裁剪。InvalidCastException(跨域继承或接口转换时)跨域适配器未正确生成或注册。1. 检查接口/基类是否为public。2. 确认已为其生成CLR绑定并在CLRBindings.Initialize中注册。3. 确保热更类正确实现了接口或继承了基类。委托调用报错或无效1. 未注册对应的委托适配器。2. 跨域委托未使用ConvertDelegate进行转换。1. 为用到的委托类型如UnityAction,System.Action生成绑定。2. 对于跨域事件订阅务必使用appDomain.DelegateManager.ConvertDelegate。真机上崩溃编辑器正常1. IL2CPP代码裁剪导致类型或方法丢失。2. 未注册必要的CLR绑定在Mono下靠反射工作IL2CPP下失效。3. 热更代码中存在平台相关的不安全代码。1. 在Assets目录下创建link.xml文件添加preserve指令保护必要的类型和程序集。2. 确保所有跨域交互都有对应的CLR绑定。3. 审查热更代码移除或用安全代码替代平台调用(P/Invoke)或不安全代码块。热更后逻辑未生效1. 新的DLL未成功下载或覆盖旧文件。2. AppDomain未重新加载新的程序集。3. 热更代码的入口点未被调用。1. 检查文件下载路径、版本号和MD5校验。2. 确保在加载新DLL前释放旧的AppDomain和相关资源。3. 添加日志确认热更模块初始化流程被正确执行。内存泄漏1. 跨域委托未正确注销导致对象无法被GC回收。2. 热更代码中持有对主工程大型对象如Texture的长期引用。1. 在热更模块卸载或对象销毁时务必注销所有事件监听。2. 使用弱引用(WeakReference)或解耦设计避免循环引用跨越两个域。8.3 关于代码裁剪Striping的特别提醒这是IL2CPP发布时最大的“坑”之一。IL2CPP在构建时会进行代码裁剪移除它认为“未被使用”的代码。如果主工程中某个类或方法仅被热更代码通过反射或接口方式调用IL2CPP可能无法识别这种依赖关系从而将其裁剪掉导致热更代码运行时找不到类型或方法。解决方案是使用link.xml文件。在Unity项目的Assets目录下创建一个名为link.xml的文件内容如下linker assembly fullnameAssembly-CSharp preserveall/ !-- 保留主工程所有代码 -- assembly fullnameUnityEngine preserveall/ !-- 保留UnityEngine所有代码 -- assembly fullnameMyFramework !-- 保留自定义框架程序集 -- type fullnameMyFramework.EventCenter preserveall/ type fullnameMyFramework.IUIWindow preserveall/ !-- 列出所有可能被热更代码用到的类型 -- /assembly /linkerpreserveall会保留该程序集或类型的所有内容。为了平衡包体大小你可以更精确地指定只保留特定的类型和方法。这需要根据项目的实际依赖仔细配置。热更新是Unity项目特别是商业手游的必备能力。ILRuntime以其优秀的性能和接近原生的开发体验成为了一个非常可靠的选择。从环境搭建、理解原理到代码分割、处理跨域调用再到最后的打包部署和问题排查每一步都需要耐心和细致的实践。记住关键在于清晰的架构设计——明确主工程与热更工程的边界以及稳健的更新流程——具备版本管理、下载校验和回滚能力。