HybridCLR——划时代的Unity原生C#热更新技术

HybridCLR是一个特性完整、零成本、高性能、低内存的近乎完美的Unity全平台原生C#热更方案。

HybridCLR扩充了IL2CPP的代码，使它由纯AOT Runtime变成“AOT+Interpreter“混合Runtime，进而原生支持动态加载Assembly，使得基于IL2CPP Backend打包的游戏不仅能在Android平台，也能在iOS、Consoles等限制了JIT的平台上高效地以AOT+interpreter混合模式执行。

HybridCLR开创性地实现了“Differential Hybrid Dll“技术。即可以对AOT Dll任意增删改，会智能地让变化或者新增的类和函数以Interpreter模式运行，但未改动的类和函数以AOT方式运行，让热更新的游戏逻辑的运行性能基本达到原生AOT的水平。

HybridCLR(wolong)原作者walon（focus-creative-games创始人）将该系列课程放入UWA学堂连载更新，现已【免费上线UWA学堂】，本文先带大家对HybridCLR——划时代的Unity原生C#热更新技术有个简单的了解，更多内容可前往UWA学堂查看。

1. 基础概念

1.1 CLR
CLR即Common Language Runtime，中文叫公共语言运行时，是让.NET程序执行所需的外部服务的集合，是.NET平台的核心和最重要的组件，类似于Java的JVM。更详细介绍请看《公共语言运行时 (CLR) 概述》。

1.2 IL2CPP
IL2CPP是Unity开发的跨平台CLR解决方案，诞生它的一个关键原因是Unity需要跨平台运行。但一些平台如iOS，这种禁止JIT并导致依赖JIT的官方CLR虚拟机无法运行，而是必须使用AOT技术将Mananged程序提前转化为目标平台的静态原生程序后再运行。而Mono虽然也支持AOT，但性能较差以及跨平台支持不佳。

IL2CPP方案包含一套AOT运行时以及一套DLL到C++代码及元数据的转换工具，使得原始的C#开发的代码最终能在iOS这样的平台运行起来。

1.3 IL2CPP与热更新
很不幸，不像Mono有Hybrid mode execution，可支持动态加载DLL。IL2CPP是一个纯静态的AOT运行时，不支持运行时加载DLL，因此不支持热更新。

目前Unity平台的主流热更新方案xLua、ILRuntime之类都是引入一个第三方VM（Virtual Machine），在VM中解释执行代码，来实现热更新。这里我们只分析使用C#为开发语言的热更新方案。这些热更新方案的VM与IL2CPP是独立的，意味着它们的元数据系统是不相通的，在热更新里新增一个类型是无法被IL2CPP所识别的（例如，通过System.Activator.CreateInstance是不可能创建出这个热更新类型的实例），这种看起来像，但实际上又不是的伪CLR虚拟机，在与IL2CPP这种复杂的CLR运行时交互时，会产生极大量的兼容性问题，另外还有严重的性能问题。

一个大胆的想法是，是否有可能对IL2CPP运行时进行扩充，添加Interpreter模块，进而实现Mono hybrid mode execution这样机制？这样一来就能彻底支持热更新，并且兼容性极佳。对开发者来说，除了解释模式运行的部分执行得比较慢，其他方面跟标准的运行时没有区别。

对IL2CPP加以了解并且深思熟虑后的答案是——确实是可行的！具体分析参见第二节《关于HybridCLR可行性的思维实验》 。这个想法诞生了HybridCLR，Unity平台第一个支持iOS的跨平台原生C#热更新方案！

2. 原理

HybridCLR扩充了IL2CPP运行时，将它由AOT运行时改造为“AOT + interpreter”双引擎的混合运行时，进而完美支持在iOS这种禁止JIT的平台上以解释模式无缝地运行动态加载的DLL。如下图所示：

更具体一些，至少需要实现以下功能：

• 加载和解析DLL元数据
• 动态注册元数据，其中关键为Hook动态函数的执行流到解释器函数
• 实现一个高效正确的解释器
• 正确处理GC及多线程等运行时机制

3. 特性

3.1 标准运行时特性
近乎完整实现了ECMA-335规范，不支持的特性仅包括：

• 不支持Delegate的BeginInvoke，EndInvoke。纯粹是觉得没必要实现。
• 不支持MonoPInvokeCallbackAttribute。意味着你如果同时还接了Lua，你没法直接将热更新的C#函数注册到Lua中，但有一个不复杂的办法能做到这点。

由于HybridCLR极其完整的实现，让使用HybridCLR后的C#开发体验跟Editor下Mono开发几乎完全相同（除了调用一些IL2CPP没实现的.net framework函数，非专家级别的开发者难以构造出HybridCLR不支持的用例）。

另外，由于是运行时级别的实现，HybridCLR支持这些特性的同时，不需要你额外生成或者调整任何代码。对于开发者来说，相比Unity下原生C#开发，零额外的学习和开发成本。

3.2 AOT相关特性
由于IL2CPP AOT模块的存在，IL2CPP比标准运行时多了一些不存在的机制，因此HybridCLR也有一些额外的特性：

• 支持使用Interpreter Assembly替换AOT Assembly（限制：必须不存在其他AOT Assembly对它的直接引用）。
• 支持补充元数据机制，彻底支持AOT泛型，参见《AOT泛型限制及原理介绍》。
• 支持AOT Hotfix，可以修复AOT模块的Bug。
• 支持任意C#函数注册到Lua之类的虚拟机，不限于Static函数，并且也不需要MonoPInvokeCallbackAttribute。条件是注册和回调方式需要略微调整。

3.3 Unity相关特性

• 完美支持Unity的Assembly Def模块机制。
• 完美支持代码中挂载热更新脚本，无使用场景限制
• 完美支持资源上挂载热更新脚本，但要求打包工作流有少许调整，参见《MonoBehaviour相关工作流》。

4. 与其他流行的C#热更新方案的区别

从原理来说，HybridCLR几乎将热更新技术做到理论上的极限，与当前所有主流热更新方案不在一个层次。

4.1 本质比较
HybridCLR是原生的C#热更新方案。通俗地说，IL2CPP相当于Mono的AOT模块，HybridCLR相当于Mono的Interpreter模块，两者合一成为完整Mono。HybridCLR使得IL2CPP变成一个全功能的Runtime，原生（即通过System.Reflection.Assembly.Load）支持动态加载DLL，从而支持iOS平台的热更新。

正因为hHybridCLR是原生Runtime级别实现，热更新部分的类型与主工程AOT部分类型是完全等价并且无缝统一的。可以随意调用、继承、反射或多线程，不需要生成代码或者写适配器。

其他热更新方案则是独立VM，与IL2CPP的关系本质上相当于Mono中嵌入Lua的关系。因此类型系统不统一，为了让热更新类型能够继承AOT部分类型，需要写适配器，并且解释器中的类型不能为主工程的类型系统所识别。特性不完整、开发麻烦、运行效率低下。

4.2 实际使用体验或者特性比较

• HybridCLR学习和使用成本几乎为零。HybridCLR让IL2CPP变成全功能的Runtime，学习和使用成本几乎为零，几乎零侵入性。而其他方案则有大量的坑和需要规避的规则，学习和使用成本较高，需要对原项目作大量改造。
• HybridCLR可以使用所有C#的特性，而其他方案往往有大量的限制。
• HybridCLR中可以直接支持使用和继承主工程中的类型，其他方案要写适配器或者生成代码。
• HybridCLR中热更新部分元数据与AOT元数据无缝统一，像反射代码能够正常工作的，AOT部分也可以通过标准Reflection接口创建出热更新对象。其他方案做不到。
• HybridCLR对多线程支持良好。像多线程、ThreadStatic、Async等等特性都是HybridCLR直接支持，其他方案除了Async特性外均难以支持。
• HybridCLR中Unity工作流与原生几乎完全相同。HybridCLR中热更新MonoBehaviour可以直接挂载在热更新资源上，并且正确工作。其他方案不行。
• HybridCLR兼容性极高。各种第三方库只要在IL2CPP下能工作，在HybridCLR下也能正常工作。其他方案往往要大量魔改源码。
• HybridCLR内存效率极高。HybridCLR中热更新类型与主工程的AOT类型完全等价，占用一样多的空间。其他方案的同等类型则是假类型，不仅不能被Runtime识别，还多占了数倍空间。
• HybridCLR执行效率高。HybridCLR中热更新部分与主工程AOT部分交互属于IL2CPP内部交互，效率极高。而其他方案则是独立虚拟机与IL2CPP之间的效率，不仅交互麻烦还效率低下。

5. 运行性能

实际性能如理论估计，全面并且大幅胜出当前主流的xLua、Puerts、ILRuntime之类的热更新方案。

• 基础指令（数值计算及条件跳转等指令），由于各个语言之间差距不大，因此胜出不明显。
• 对象模型指令。由于没有跨语言交互的成本，几乎是数倍到数十倍的提升（如果指令自身消耗特别大，则差距不那么明显）。

性能测试用例来自ILRuntime提供的标准测试用例，测试项目来自Don't worry的github仓库。

测试结果显示，绝大多数测试用例都有数倍到数十倍的性能差距，差距极其夸张。唯独数值计算跟xLua有少量劣势，这是因为当前HybridCLR未对指令作任何优化，后续优化版本大多数基础指令都将有100～300%的性能提升。

6. 内存

HybridCLR是运行时级别的实现，因为热更新的脚本，除了执行代码是以解释模式执行，其他方式跟AOT部分的类型是完全相同的，包括占用内存。

6.1 对象内存大小对比
Lua的计算规则略复杂，参见《Lua数据结构和内存占用分析》。空Table占56字节，每多一个字段至少多占32字节。

ILRuntime的类型除了Enum外统一以IlTypeInstance表达，空类型占72字节，每多一个字段至少多用16字节。如果对象中包含引用类型数据，则整体又至少多24字节，并且每多一个Object字段多8字节。

7. 当前稳定性状况

技术评估上目前稳定性处于Beta版本。由于HybridCLR技术原理的先进性，Bug本质上不多，稳定得非常快。已经有一段时间未收到2020.3.33版本的Bug反馈。

• 目前PC、Android、iOS已跑通所有单元测试，可稳定体验使用。
• 2022.6.7第一款使用HybridCLR的Android和iOS双端休闲游戏正式上线。
• 2022.7将有至少2款重度项目和2款中度游戏上线。
• 2022年预计有几十款中重度项目及超过一百款轻度或者独立游戏上线。

已经有几十个大中型游戏项目较完整地接入HybridCLR，并且其中一些在紧锣密鼓作上线前测试。具体参见收集的一些完整接入的商业项目列表。

8. 总结

HybridCLR是一个划时代的Unity平台C#原生热更新技术，它将国内Unity开发的技术框架水平提高到新的高度，并深刻地改变Unity平台的开发生态。

本文内容就介绍到这里啦，更多内容可以前往UWA学堂进行阅读