@HybridClr介绍
C# -> HybridCLR 热更新介绍
以下讲简单阐述下个人理解的Hclr的相关知识，以及在使用中遇到的坑点.
在使用HybridCLR 前的一些基本知识储备
为了方便下文的更好的理解,建议大家先简单过一下下文的一些名称和一些简单的知识点：
- CommonLanguageRuntime ，公共语言运行环境；
- Ahead Of Time (AOT)，指运行前编译 -> 静态编译环境；
- Just-in-time(JIT)，指即时编译（动态），边运行边编译；
- ILC2CPP，Unity提供的跨平台CLR的解决方案；
HybridCLR的基本运行原理
简单的用一句话概括：
对Unity提供的原生IL2CPP的方案进行深度改造,讲它由纯AOT的运行方案改造为AOT+interpreter的混合运行模式进行。
其中，主要实现了以下功能:
1.实现了支持用原生加载DLL、解析DLL。
2.支持动态注册到HybridCLR的相关解释器。
3.支持补充相关元数据。
4.支持AOT泛型的机制
5.支持HotFIX AOT
6.支持Mono使用热更脚本
7.支持资源上挂载热更新脚本
等等
…
跟其他的热更方案本质区别
HybridCLR是原生的c#热更新方案。原始il2cpp相当于只有aot的mono，而HybridCLR则给il2cpp新增了原生的interpreter模块，使得il2cpp变成一个全功能的mono，原生（即通过System.Reflection.Assembly.Load）支持动态加载dll，从而支持ios等平台的热更新。其他热更新方案则是新增了一个独立于il2cpp的第三方vm。
正因为HybridCLR是原生runtime级别实现，热更新部分的类型与主工程AOT部分类型是完全等价并且无缝统一的。可以随意调用、继承、反射、多线程，不需要生成代码或者写适配器。
其他热更新方案则是独立vm，与il2cpp的关系本质上相当于mono嵌lua的关系。因此类型系统不统一，为了让热更新类型能够继承AOT部分类型，需要写适配器，并且解释器中的类型不能为主工程的类型系统所识别。
Lua(XLua、ToLua): 通过Lua虚拟机作为解释层，对游戏中启动一个Lua虚拟机，通过编写对应的Lua业务逻辑脚本，和少量的C#框架层代码(映射MonoAPI，绑定界面等)实现的整套热更新机制。因为本身Lua脚本语言它不属于Unity层，相当于一个第三方可读写的文本.只不过通过Lua虚拟机解释了。所以对于Unity本身而言，只是去下载了类Txt的东西而已。
ILRuntime：本质通过Mono.Cecil 函数读取对于的DLL字节码相关信息,通过IL内置的虚拟机来反解对应的字节码信息，从而得到原始DLL中的代码。这里缺点最大的地方是他无法直接使用Mono的API，也无法在资源上挂热更脚本.
从上述对应的热更方案实现原理来看,不难发现，无论是Lua也好、ILRuntime也好、HybridCLR也好，都是需要一层对应的虚拟机去解析自己的业务逻辑。但是Lua、IL因为并不是在原生层面上进行的拓展，没法直接使用到Mono层相关的元数据，导致在接入相关热更新方案的时候还是会导致对原有工程的开发流程有一个很大的改变和一定的学习成本。
HCLR官方的性能报告图
在实际接入过程中遇到的坑
1.在新增第三方库的时候，例如Dotween，AStart等相关第三方库，需要重新对AOTMetaAssemblyNames进行补充，重新出包。因为AOT的DLL列表好像是随着包出的。而且要记得扫描一下,要不然本身没补充到 出包也解决不了丢失引用的问题。
2.在对老项目子程序的管理：稍有不慎,就会导致引用混乱，可能跟自己对这块的理解程度不够，参考了第三方接入Hclr框架后对这块有一个概念:
3.如果资源上挂载了热更域的脚本，通过GameObject.GetComponent(string name) 是无法获取到组件的。这个好像是已知的Bug。 建议是使用 GameObject.GetComponent()
4.打包工作流相应的改动,需要参照HCLR调整打包相关的工具流程，对应的热更DLL不放进包内。
4.1需要生成对应的DLL文件和裁剪后的AOTDLL。
4.2需要使用HCLR提供的工具编译热更新DLL。
4.3IOS平台还需特殊处理下:对应文档HCLR IOS 特殊处理
以下为基于接入HCLR的第三方仓库推荐:Deer-Wolong
HCLR官方仓库:HybridCLR