06-认知篇-对比-ILRuntime深度解析

ILRuntime深度解析

前言

在 HybirdCLR 出现之前，Unity 热更新领域长期被两类方案主导：一类是基于 Lua 脚本的桥接方案（xLua、ToLua、SLua），另一类就是基于纯 C# 解释器的方案。ILRuntime 正是后者中最具代表性的作品，由掌趣科技（Ourpalm）开发并开源，在 2016 年至 2021 年期间，是 Unity 社区中应用最广泛的纯 C# 热更新方案。

ILRuntime 的出现解决了当时的一个核心矛盾：Lua 方案虽然能实现热更新，但要求开发者掌握一门新语言，且 Lua 与 C# 之间的类型鸿沟带来了巨大的开发成本和维护负担。ILRuntime 另辟蹊径——不在 Unity 引擎层做任何修改，完全在托管代码层面实现了一套 CLI（Common Language Infrastructure）运行时，直接读取并解释执行标准的 .NET 程序集（DLL）。这意味着 C# 开发者可以继续使用 C# 编写热更新代码，不需要学习 Lua，不需要编写桥接代码，不需要处理 Lua 和 C# 之间的类型映射。

从技术演进的角度来看，ILRuntime 代表了一类重要的技术路径——"纯托管解释器"方案。理解 ILRuntime 的工作原理、优势与局限，不仅有助于理解为什么 HybirdCLR 代表了技术上的重大突破，也有助于在真实项目中做出合理的技术选型决策。本文将从架构原理、性能特征、适用场景等多个维度，对 ILRuntime 进行全面深度的分析，并在每个关键维度上与 HybirdCLR 进行对比。

一、ILRuntime的架构原理

1.1 纯C#实现的CLR运行时

ILRuntime 本质上是一个用 C# 实现的 CLI 运行时。标准的 .NET 运行时（如 Mono、CoreCLR）通常是用 C/C++ 编写的，它们直接操作内存、管理线程、处理原生调用。ILRuntime 则完全工作在 Unity 的托管环境中，通过 C# 代码模拟了一个 CLR 的行为。

这意味着什么？当 ILRuntime 加载一个 DLL 文件时，它并不依赖任何原生库来解析 PE 结构和 IL 指令。它自己读取 PE 文件头、解析元数据表（Metadata Table）、提取 IL 字节码（IL Body），然后用自己的解释引擎逐条执行这些 IL 指令。整个过程完全在 C# 的托管堆上进行。

从运行时的层次结构来看，ILRuntime 构建了一个两层体系：

• 底层——IL 解释执行引擎：负责解析 IL 字节码、管理虚拟执行栈、处理异常、管理类型系统等。这是 ILRuntime 的核心，承担了所有热更新代码的实际执行工作。
• 上层——Unity 集成层：负责处理热更新代码与 Unity 原生代码（AOT 代码）之间的交互，包括跨域继承、CLR 重定向、委托转换等。这是 ILRuntime 的"胶水层"，解决了纯 C# 解释器无法直接与 Unity 运行时互操作的问题。

这种两层架构的设计决策深刻影响了 ILRuntime 的后续发展。下层决定了它的能力边界和性能上限，上层决定了它的可用性和开发体验。

1.2 IL解释执行引擎的工作方式

ILRuntime 的解释执行引擎采用栈式虚拟机（Stack-based VM）模型，与 ECMA-335 标准定义的 CLI 执行模型一致。当一个热更新方法被调用时，其执行流程如下：

Step 1: 定位方法体
当热更新代码中发生方法调用时，ILRuntime 在自身的类型系统（ILType、ILMethod 等）中查找目标方法的元数据，获取其 IL 字节码和异常处理子句信息。

Step 2: 初始化栈帧
为本次方法调用创建栈帧（StackFrame），栈帧中包含了：

• 局部变量数组（locals）
• 参数数组（args）
• 操作数栈（operand stack）
• 当前指令指针（IP）
• 异常处理状态

Step 3: 逐条解释执行IL指令
ILRuntime 的核心解释循环（Interpreter Loop）从当前 IP 位置读取 IL 指令，解析操作码（OpCode）和操作数（Operand），然后执行对应的 C# 逻辑。以几个常见 IL 指令为例：

• ldloc.0：将局部变量 0 压入操作数栈 -> 从 locals 数组取值，push 到 operand stack
• ldc.i4.5：将整数常量 5 压入栈 -> push 5 到 operand stack
• add：弹出栈顶两个值相加，结果压回栈 -> pop 两个值，用 C# 的加法运算，push 结果
• stloc.1：弹出栈顶值存入局部变量 1 -> pop 值，写入 locals[1]
• call：调用指定方法 -> 创建新的栈帧，递归进入解释循环
• ret：返回 -> 弹出返回值，销毁当前栈帧，回到调用者的栈帧

Step 4: 处理异常和分支
遇到throw指令时，ILRuntime 在当前栈帧的异常处理子句中查找匹配的 catch/finally 块。遇到br/brtrue/brfalse等分支指令时，根据条件跳转到目标 IL 偏移位置继续执行。

Step 5: 返回调用者
当方法执行完毕（遇到ret指令），ILRuntime 将返回值（如果有）压入调用者的操作数栈，销毁当前栈帧，调用者继续执行。

这个过程与 Mono 或 CoreCLR 的解释器在逻辑层面是相似的，区别在于执行效率：Mono 的解释器是 C 语言实现的，ILRuntime 的解释器是 C# 实现的。C# 代码运行时本身又要经过一层 IL2CPP 的转换（在 iOS 平台）或 Mono 的解释/编译（在 Editor 中），这意味着 ILRuntime 的解释器实际上是"解释器的解释器"，性能损耗是叠层的。

1.3 与Unity的集成方式

纯 C# 解释器面临一个根本性的挑战：Unity 运行时（以及整个 .NET 基础类库）是用原生代码或 AOT 编译的，它们对 ILRuntime 中定义的"热更新类型"一无所知。当我们需要在热更新代码中继承 MonoBehaviour，或者将热更新对象传递给 Unity API 时，必须有一种机制来桥接两个世界。

ILRuntime 通过两个关键机制解决了这个问题：

跨域继承（Cross Domain Inheritance）

跨域继承是 ILRuntime 最核心也最精妙的设计之一。它的核心思路是：在 AOT 侧（主工程）预定义一个"适配器类"，这个类继承自目标基类（如 MonoBehaviour），并持有对热更新侧对象的引用。所有虚方法的调用都被适配器转发到热更新侧对象。

以 MonoBehaviour 为例，具体流程如下：

Unity运行时 -> MonoBehaviourAdapter（AOT侧） -> HotUpdateMono（热更新侧） | | | MonoBehaviourAdapter.Awake() | |------------------------------->| | | HotUpdateMono.Awake() | | 执行热更新逻辑 | <--------------------------- | | 返回或调用基类方法 |

ILRuntime 在运行时为每个需要跨域继承的热更新类型生成适配器代码。这个过程是自动的——开发者只需要在热更新代码中定义class MyBehavior : MonoBehaviour，ILRuntime 会在加载程序集时检测到这种跨域继承关系，并自动生成对应的适配器。

适配器的生成遵循以下规则：

• 为每个跨域继承的类型生成一个适配器类
• 适配器类继承自同一个基类（如 MonoBehaviour）
• 适配器中的每个可重写方法（virtual、abstract）都会被包装成一个委托调用
• 适配器实例与热更新实例之间通过一个WeakReference保持关联

这种设计的代价是明显的：每个热更新 MonoBehaviour 对象在内存中实际对应两个对象——AOT 侧的适配器对象和热更新侧的真实对象。Unity 引擎只能感知到适配器对象（因为它是真正的 MonoBehaviour），而适配器对象又持有对热更新对象的引用。这种双重对象结构带来了额外的内存开销和间接调用成本。

CLR 重定向（CLR Redirection）

CLR 重定向是 ILRuntime 处理性能瓶颈和兼容性问题的另一个关键机制。其基本思路是：当热更新代码调用某些特定的 AOT 方法时，不是通过解释器执行，而是重定向到一段手动优化的 C# 代码。

为什么需要 CLR 重定向？主要有两个原因：

第一是性能。某些方法在热更新中被频繁调用，比如DateTime.Now、Debug.Log、List<T>.Add、Dictionary<TKey,TValue>.TryGetValue等。如果每次调用都走完整的 IL 解释路径（解析指令、压栈弹栈、类型检查等），性能开销会非常大。CLR 重定向允许将这些高频调用直接映射到一段高效的原生 C# 代码。

第二是兼容性。某些 .NET 方法在解释执行上下文中无法正常工作，因为它们可能在内部使用了 P/Invoke、sizeof、Marshal等底层操作，这些操作在 ILRuntime 的解释环境中无法正确执行。通过 CLR 重定向，可以为这些方法提供在 ILRuntime 上下文中的替代实现。

CLR 重定向的配置方式是在 AOT 侧编写一个静态类，通过 ILRuntime 提供的 API 注册重定向映射：

// 示例：为 Debug.Log 注册 CLR 重定向 appDomain.RegisterCLRMethodRedirection(typeof(Debug).GetMethod("Log"), (ILContext context) => { // 从栈上获取参数 var message = context.Stack.Pop() as string; // 直接调用 Unity 的 Debug.Log（注意这是在 AOT 侧） UnityEngine.Debug.Log(message); return true; // 表示已处理 });

CLR 重定向是 ILRuntime 性能优化中最为关键的手段之一。一个精心配置了 CLR 重定向的项目，性能可以比默认配置提升数倍。但这也意味着 ILRuntime 的性能高度依赖于 CLR 重定向的覆盖率和质量——这是一个"手工优化"的过程，需要开发者对热更新代码中哪些方法是性能热点有清晰的认识。

1.4 主要模块组成

ILRuntime 的代码库由以下几个核心模块组成：

其中，AppDomain是最核心的入口类。ILRuntime 的 AppDomain 相当于 CLR 中的应用域（Application Domain），负责管理所有加载的程序集、类型和方法。开发者的主要交互对象就是 AppDomain——通过它加载 DLL、实例化类型、调用方法。

二、ILRuntime的优势

2.1 纯托管代码，无原生依赖

ILRuntime 完全由 C# 实现，不依赖任何原生库。这意味着：

• 平台无关性：只要 Unity 能运行的目标平台，ILRuntime 就能运行。不存在平台适配问题，不需要为 iOS、Android、Windows 等不同平台分别编译原生库。
• 接入简单：将 ILRuntime 的 DLL 复制到项目中即可使用，不需要修改 Unity Player Settings，不需要调整 IL2CPP 编译参数，不需要处理复杂的环境配置。
• 零侵入性：ILRuntime 不需要修改 Unity 引擎本身，不与 IL2CPP 或 Mono 的运行时产生冲突，随时可以移除或替换。

在 HybirdCLR 出现之前，"纯 C# + 零原生依赖"是 ILRuntime 相对于 Lua 方案的一个显著优势。Lua 方案需要在 Unity 项目中集成 Lua 虚拟机（LuaJIT 或标准 Lua），而 Lua 虚拟机是用 C 语言编写的，对于某些平台（如 iOS 的 JIT 限制）需要额外处理。

2.2 支持完整的反射

ILRuntime 对 .NET 的反射机制提供了较为完整的支持。热更新代码中可以使用Type.GetType()、typeof()、MethodInfo.Invoke()、PropertyInfo.GetValue()、Attribute.GetCustomAttribute()等标准反射 API。

对于 Unity 开发来说，反射支持意味着：

• 序列化/反序列化框架：可以正常工作，如 Newtonsoft.Json、MessagePack 等
• 依赖注入框架：基于反射的 IoC 容器可以正常使用
• 自定义 Attribute：可以在热更新代码中定义和使用
• 编辑器工具：基于反射的编辑器工具（如 Inspector 绘制）可以部分工作

这在与 Lua 方案对比时是一个重要优势——在 xLua 中，Lua 代码无法直接使用 .NET 的反射 API，热更新代码中的类型信息对 AOT 侧是"不可见"的。ILRuntime 虽然也有反射方面的限制（下面会详述），但整体上提供了更接近原生 C# 的反射体验。

2.3 开发体验在当时的方案中较好

从 2016 年到 2021 年这个时间窗口来看，ILRuntime 的开发体验相比 Lua 方案有显著的提升：

• 同一个语言：开发 AOT 代码和热更新代码使用同一种语言（C#），不需要在 C# 和 Lua 之间频繁切换上下文
• 类型检查：热更新代码在编译时能获得 C# 编译器的类型检查，虽然部分语法受限，但比 Lua 的动态类型安全得多
• 代码复用：可以将部分工具类/算法库直接放在热更新 DLL 中，不需要为 Lua 重新实现
• IDE 支持：热更新代码仍然使用 Visual Studio / Rider / VS Code 编写，获得智能提示、代码补全、重构支持

对于那些"一门语言打天下"的团队来说，ILRuntime 显著降低了热更新的心理门槛。不需要学习 Lua 的 metatable、coroutine、模块系统等概念，不需要处理复杂的 Lua-C# 桥接调试场景。

2.4 社区活跃，文档完善

ILRuntime 在巅峰时期拥有活跃的社区生态：

• GitHub 开源，提供了丰富的示例项目
• 完整的中文文档和教程
• QQ 群活跃，社区解答了大量接入问题
• 多个商业游戏项目成功上线，为方案的有效性提供了实际验证

GitHub 上 ILRuntime 的 Issues 和 Discussions 中积累了大量的踩坑经验和解决方案，这些沉淀对于新接入的团队是非常宝贵的参考资源。

三、ILRuntime的劣势

3.1 性能开销大

性能是 ILRuntime 最为明显的短板。由于采用纯 C# 实现的栈式解释器，ILRuntime 在执行热更新代码时引入了巨大的性能开销。

根据 HybirdCLR 官方的性能测试数据以及社区开发者的大量实测，ILRuntime 与 AOT 原生执行的对比如下：

性能瓶颈的根源在于多层间接执行：

ILRuntime热更新调用路径： C# ILRuntime解释器代码 + 被 IL2CPP 编译为 C++ / 或 Mono JIT + 实际的 IL 指令执行逻辑（读取字节码、push/pop、类型检查） + 每执行一条 IL 指令，需要多次 C# 方法调用 + 分支判断

每一次 IL 指令的解释执行，在 ILRuntime 中对应着至少一次虚方法调用或委托调用（如从操作码表查找执行函数），再加上类型检查、空值检查、边界检查等。这些开销在频繁调用的循环中会被放大数倍到数十倍。

举个例子，一个简单的for (int i = 0; i < 100000; i++) sum += array[i];在 ILRuntime 中执行时，循环体的每次迭代都需要：

1. 解释ldloc指令（加载局部变量 i）
2. 解释ldloc指令（加载 array 引用）
3. 解释ldelem.i4指令（数组元素访问，包含类型检查和边界检查）
4. 解释add指令（加法运算）
5. 解释stloc指令（存储结果到 sum）
6. 解释ldloc指令（加载局部变量 i）
7. 解释ldc.i4.1指令（加载常量 1）
8. 解释add指令（i + 1）
9. 解释stloc指令（存储 i++ 结果）
10. 解释ldloc指令（加载局部变量 i）
11. 解释ldc.i4指令（加载常量 100000）
12. 解释blt指令（条件跳转）

12 条 IL 指令的每条都需要经过 ILRuntime 解释循环的完整处理。这个开销是 AOT 原生执行（直接对应几条 CPU 指令）无法比拟的。

3.2 兼容性限制

ILRuntime 虽然使用 C# 编程语言，但并不意味着所有 C# 语法特性都可以在热更新代码中使用。其兼容性限制主要表现在以下几个方面：

泛型限制：这是 ILRuntime 最受诟病的兼容性问题。ILRuntime 不支持在热更新代码中定义泛型类或泛型结构体。泛型方法的支持也有限——热更新代码不能调用那些在 AOT 侧没有预先实例化的泛型方法。这意味着像List<T>、Dictionary<TKey, TValue>这些泛型集合在热更新代码中的使用受到严格限制，开发者需要手动在 AOT 侧声明所有可能用到的泛型实例化类型。

部分API不支持：ILRuntime 无法支持那些底层依赖 P/Invoke、COM Interop、或者直接操作内存的 API。例如：

• System.IO.File中的部分方法（底层调用 Win32 API）
• System.Net.Sockets（底层调用原生 socket API）
• System.Drawing（底层调用 GDI+）
• 自定义DllImport声明

Delegate转换问题：热更新中的 delegate 与 AOT 中的 delegate 不能直接互转。开发者需要通过 ILRuntime 提供的特定 API（如appDomain.Delegate或appDomain.ConvertDelegate）来桥接。

值类型（struct）限制：struct 在热更新侧和 AOT 侧之间的传递可能存在内存布局不一致的问题。ILRuntime 使用StackObject来表示值类型，而 AOT 侧使用标准 CLI 的内存布局。两者在转换时如果 struct 包含引用类型字段或复杂嵌套，可能会出现问题。

部分反射操作不支持：System.Reflection.Emit当然不支持（这需要 JIT 的能力），MethodInfo.Invoke在某些场景下也可能因为参数类型不匹配而失败。

3.3 内存占用

ILRuntime 的内存占用问题主要来自三个方面：

跨域继承的双重对象：如前所述，每个需要跨域继承的热更新对象（如热更新侧的 MonoBehaviour）在内存中都对应两个对象——AOT 侧的适配器对象和热更新侧的真实对象。适配器对象持有对热更新对象的引用，而热更新对象也可能持有反向引用。这意味着内存开销翻倍，并且增加了 GC 压力。

以一个包含 100 个 MonoBehaviour 的游戏场景为例，如果全部使用 ILRuntime 热更新，内存中实际存在 200 个对象（每个 MonoBehaviour 对应一个适配器和一个热更新对象）。而在 HybirdCLR 中，同样的情况只有 100 个对象。

CLR重定向缓存：CLR 重定向需要维护一张从方法元数据到重定向实现函数的映射表。当项目中配置了大量 CLR 重定向时，这张映射表本身会占用不少内存，并且每次方法调用前的查找操作也有 CPU 开销。

类型元数据重复：ILRuntime 维护了自己的一套类型系统元数据（ILType、ILMethod、ILField 等），这些信息与 IL2CPP（或 Mono）运行时已经维护的类型元数据高度重复。对于一个大型项目，这套重复的元数据可能额外占用数 MB 甚至数十 MB 的内存。

3.4 Debugging体验限制

ILRuntime 虽然提供了调试器支持，但其调试体验与原生 C# 调试存在较大差距：

• 调试器需要额外配置：需要单独开启 ILRuntime 的调试服务，并在 IDE 中附加到远程调试端口
• 断点可靠性：部分场景下断点可能触发异常或无法命中，尤其是在处理跨域继承的方法时
• 变量查看不完整：在执行栈中的某个栈帧查看局部变量时，某些复杂类型的变量可能显示为 "Cannot evaluate expression"
• 无Edit and Continue：调试过程中无法修改代码并继续执行
• 性能开销：开启调试模式后，解释器的执行会进一步变慢，影响调试体验
• 发布版本难以定位问题：发布的 Release 版本中，异常堆栈信息通常只包含 IL 偏移量，不包含 C# 源文件的文件名和行号。需要借助 ILRuntime 提供的工具来将 IL 偏移量映射回源代码位置，增加了问题定位的复杂度

3.5 不支持多线程、async/await

ILRuntime 不支持真正的多线程执行。所有的热更新代码都在 Unity 主线程上解释执行。这意味着：

• System.Threading.Thread、System.Threading.Tasks.Task在热更新中不可用
• async/await编译器生成的异步状态机在 ILRuntime 中无法正确执行
• System.Threading.Mutex、Semaphore、Monitor等同步原语不可用

对于现代 Unity 开发来说，这个限制越来越成为瓶颈。许多游戏逻辑（如资源加载、网络通信、数据计算）都需要异步处理，而 ILRuntime 无法在热更新代码中直接使用 async/await，迫使开发者使用回调或协程来替代，导致代码可读性和维护性下降。

协程（IEnumerator / StartCoroutine）在 ILRuntime 中虽然可以工作，但性能较差，且不能配合yield return new WaitForSeconds之外的大部分 YieldInstruction 类型。

四、ILRuntime vs HybirdCLR 深度对比

4.1 性能对比

性能是 ILRuntime 与 HybirdCLR 之间最显著的差异。两者的核心架构差异决定了性能量级的差距：

为什么会有这样的差距？核心原因在于 HybirdCLR 的 C++ 解释器是直接运行在硬件上的原生代码，而 ILRuntime 的 C# 解释器本身运行在 IL2CPP/Mono 之上，多了一层抽象。这层抽象的代价是数倍的性能损耗。

另一个关键差异是 Intrinsic 函数的覆盖度。HybirdCLR 对大量性能敏感的底层操作（如数组索引、字符串操作、数学函数、类型转换等）提供了 Intrinsic 实现——即直接将 IL 指令映射到高效的 C++ 代码片段，绕过了解释器。而 ILRuntime 需要开发者手动配置 CLR 重定向，覆盖面有限且维护成本高。

4.2 兼容性对比

从表格可以清晰地看到，HybirdCLR 在几乎所有兼容性维度上都有显著优势。特别是泛型、多线程、async/await 和 unsafe 代码的支持，这些在现代 C# 开发中越来越重要的特性，ILRuntime 完全无法满足。

4.3 内存占用对比

ILRuntime 的内存额外开销来自跨域继承对象和类型元数据重复，这在大型项目中可能造成数十 MB 的额外内存消耗：

以一个实际的 MMORPG 项目为例，社区报告显示：

• ILRuntime 方案：热更新相关内存约 50-80MB（包含类型元数据、适配器对象、CLR绑定缓存等）
• HybirdCLR 方案：相同逻辑的热更新代码，内存约 30-40MB（仅为热更新代码的数据和对象本身）

对于内存敏感的移动端游戏来说，ILRuntime 多出的这部分内存占用可能会对低端设备产生显著影响。

4.4 学习成本对比

ILRuntime 的学习曲线呈现出"先低后高"的特征：刚开始接入时看起来很简单（都是 C#），但随着项目深入，各种"坑"逐渐显现——为什么这个泛型用不了？为什么这个 struct 传参出错了？为什么这个反射调用报错了？这些问题的排查和解决需要深入理解 ILRuntime 的内部机制。

HybirdCLR 的学习曲线则是"平直的"——接入后几乎所有 C# 特性都可以直接使用，开发者不需要成为 HybirdCLR 的专家就能高效开发热更新代码。

4.5 社区与生态对比

从社区趋势来看，2022 年 HybirdCLR 开源后，社区的重心已经明确从 ILRuntime 和 Lua 方案转移到了 HybirdCLR。ILRuntime 的开发者掌趣科技虽然仍在维护项目，但更新频率和响应速度已经明显放缓。

五、ILRuntime的适用场景与迁移建议

5.1 ILRuntime仍适合的场景

尽管 ILRuntime 在多个维度上已被 HybirdCLR 超越，但这并不意味着 ILRuntime 在任何情况下都应该被抛弃。以下场景中，ILRuntime 仍然是可以考虑的选择：

场景一：已有稳定运行的ILRuntime项目
对于一个已经基于 ILRuntime 开发了数年的游戏项目，如果：

• 项目已经稳定上线，没有严重的性能问题
• 团队对 ILRuntime 的"坑"已经充分掌握，有成熟的规避免方案
• 热更新代码量适中，性能瓶颈可控

在这种情况下，强行迁移到 HybirdCLR 可能带来不必要的风险和成本。建议保持现状，在后续的重大版本更新中再考虑迁移。

场景二：极轻量级的游戏/工具
如果项目只需要非常少量的热更新逻辑（比如几 KB 的配置读取逻辑、一些简单的 UI 控制），ILRuntime 的接入简便性（复制 DLL 即可使用）反而是一个优势。对于这种场景，ILRuntime 的性能开销和兼容性限制几乎不构成问题。

场景三：对原生代码侵入零容忍的团队
有些团队或项目有严格的"不修改引擎"策略。ILRuntime 完全以托管代码形式运行，不修改任何引擎层面的代码，这种零侵入性在某些组织中可能是被优先考虑的特性。

5.2 从ILRuntime迁移到HybirdCLR的路径

对于决定迁移的团队，建议采用以下分阶段策略：

第一阶段：评估与准备（建议2-4周）

1. 代码审计：全面梳理现有 ILRuntime 热更新代码，识别依赖 ILRuntime 特定机制的代码（跨域继承、CLR重定向、委托转换等）
2. 性能基准：建立迁移前的性能基准数据（帧率、内存、加载时间等），用于迁移后对比
3. HybirdCLR学习：团队关键成员深入学习 HybirdCLR 的原理和接入流程

第二阶段：基础设施搭建（建议1-2周）

1. 安装 HybirdCLR Unity Package，配置项目
2. 划分 AOT 程序集和热更新程序集
3. 配置 AOT 泛型引用（可使用 HybirdCLR 的自动分析工具）
4. 调整构建和打包流程以输出热更新 DLL

第三阶段：热更新代码迁移（建议2-4周，取决于代码量）

1. 自动化迁移为主：大部分 ILRuntime 热更新代码的 C# 逻辑本身可以直接应用到 HybirdCLR 中，因为语法层面都是标准的 C#
2. 重点重写：
   • 移除所有 CLR 重定向配置（HybirdCLR 不需要）
   • 移除跨域继承适配器相关代码（HybirdCLR 不需要）
   • 将委托转换代码（ConvertDelegate）改为标准 C# 委托
   • 检查并修正泛型使用（ILRuntime中受限的泛型在HybirdCLR中可以直接使用）
3. 测试覆盖：对每个热更新模块编写全面的单元测试和集成测试

第四阶段：测试与验证（建议2-4周）

1. 功能测试：确保所有热更新功能在 HybirdCLR 下的行为与 ILRuntime 一致
2. 性能测试：对比迁移前后的帧率、内存、热更新加载时间等核心指标
3. 兼容性测试：在所有目标平台（Android、iOS、Windows 等）上验证
4. 压力测试：在长时间运行、高负载场景下验证稳定性

第五阶段：灰度发布（建议1-2周）

1. 选择少量测试用户或测试服进行灰度切换
2. 监控异常率和性能指标
3. 确认无重大问题后全量发布

5.3 迁移注意事项

在迁移过程中，以下问题需要特别关注：

泛型相关的重写
ILRuntime 项目中常见的泛型规避模式——如在 AOT 侧预声明List<int>、Dictionary<string, object>等泛型实例化——在 HybirdCLR 中可以全部移除。HybirdCLR 支持热更新代码中自由使用泛型，无需预声明。

跨域继承代码的简化
ILRuntime 中的跨域继承通常涉及以下代码模式，需要在迁移时移除：

// ILRuntime模式（需要额外配置） // 1. 创建MonoBehaviour适配器 // 2. 注册CLR重定向 // 3. 使用特定API执行实例化 // HybirdCLR模式（标准C#） // 1. 直接在热更新DLL中定义MonoBehaviour // 2. 直接挂载到GameObject上 // 3. 直接使用AddComponent

CLR重定向配置的清理
ILRuntime 项目中通常有一个专门的 CLR 重定向配置文件，定义了大量的方法重定向。迁移时，这些配置可以全部删除——HybirdCLR 不需要也不支持 CLR 重定向机制。

性能测试的验证
迁移完成后，务必进行详细的性能对比测试。从社区和官方数据来看，迁移到 HybirdCLR 后，热更新代码的性能通常会有 3-10 倍的提升，内存占用降低 30%-50%。如果性能提升不明显或出现退化，需要排查：

• 是否大量热更新代码被频繁调用（循环热点）
• 是否正确配置了 AOT 泛型引用（缺少泛型实例会导致热更新代码走解释器路径时效率更低）
• 是否存在跨程序集的大量方法调用（可能需要调整程序集划分）

总结

ILRuntime 作为 HybirdCLR 出现之前 Unity 生态中最主流的纯 C# 热更新方案，在技术史上有着重要的地位。它证明了"纯 C# 解释器"这条技术路径的可行性，为大量 C# 开发者提供了不依赖 Lua 的热更新能力，避免了学习新语言和维护桥接代码的负担。

从技术原理上看，ILRuntime 的核心是一个用 C# 实现的栈式虚拟机，通过跨域继承和 CLR 重定向两个关键机制与 Unity 运行时集成。这种设计在保证零原生依赖的同时，也带来了性能、兼容性和内存方面的固有局限。

从技术对比的角度来看，ILRuntime 与 HybirdCLR 的差异本质上是"纯托管解释器"与"原生解释器"两种技术路线的差异。HybirdCLR 通过在 IL2CPP 运行时中嵌入高效的 C++ 寄存器解释器，在性能（提升 3-10 倍）、兼容性（支持完整 C# 特性）、内存占用（降低 30%-50%）和学习成本（零学习成本）四个核心维度上实现了对 ILRuntime 的全面超越。

对于技术的演进，我们不应苛责 ILRuntime 的不足，而应理解它在当时技术条件下的合理选择。正是 ILRuntime 积累的大量实践经验——从跨域继承到泛型限制、从性能优化到内存管理——为 HybirdCLR 的设计提供了重要的参考和方向。可以说，没有 ILRuntime 的实践积累，就没有 HybirdCLR 今天的成熟度。

对于新项目，建议直接使用 HybirdCLR。对于已有 ILRuntime 项目，本文提供了从评估到灰度发布的完整迁移路径，建议团队根据自身情况评估迁移时机和风险。

下一篇（第 07 篇）将深入解析 xLua——Unity 生态中最主流的 Lua 热更新方案，分析其架构原理、优势局限以及与 HybirdCLR 的对比，敬请期待。

参考资源

• ILRuntime GitHub
• ILRuntime 官方文档
• HybirdCLR 性能测试报告
• ECMA-335 标准
• HybirdCLR 官方文档