目前Unity热更新按照语言来划分，主要有以下体系：

Lua系：xLua、uLua、toLua等

Lua算是比较早的热更新解决方案，稳定性是经过大量产品验证的，所以很多公司都有自己的技术和框架积累，开发项目时就会选择所熟悉的Lua。
不管是哪种Lua框架，思路都是在Unity引擎里内置一个Lua解释器，将需要的接口导出给Lua调用，运行时进行解释执行

C#系：ILRuntime、HybirdCLR(wolong/huatuo)

ILRuntime

与Lua热更原理类似，只不过是Unity内置了一个.Net解释器，解释执行.Net字节码，所以一般是编写一个.net解释执行的项目进行热更

HybirdCLR

我们知道Unity打包发布大致流程如下：
Unity->.Net字节码->IL2CPP->静态C++代码->编译成二进制机器指令然后执行，是没办法直接做热更新

HybirdCLR扩展了IL2CPP runtime运行时的库，解释执行.Net的dll字节码，直接使用原来的内存对象数据，在native上开辟内存；不像虚拟机，在虚拟机上开辟内存，维护自己的堆栈。所以它的性能更好，没有数据跨域的问题。
可以把Unity项目利用ADF机制，分成多个.dll工程，每个.dll都可以做热更新

发布时：所有dll->IL2CPP->C++代码然后编译->原始包性能最好

热更时：所有dll->与发布时的dll作对比，检测是否需要更新->如果需要更新，那么会用扩展的il2cpp runtime加载.net .dll->然后解释执行，内存空间直接使用native，因为它没有虚拟机的概念

TypeScript系：Puerts

作者也是xLua框架的作者，与Lua方案类似，只不过语言换成了TypeScript

从热更原理来看分以下两种：

内置一个虚拟机

比如所有的Lua系、C#系的ILRuntime、TypeScript系
虚拟机有自己的堆栈，解释执行热更代码
Unity Core工程 + 热更工程

基于il2cpp解释执行.net，使用native内存

比如C#系的HybirdCLR

ADF->若干.dll

发布APK
.dll->cpp->native code->APK(内置扩展的il2cpp runtime用于解释执行.dll)

有热更的dll时，il2cpp来加载热更的.dll，这个.dll里面的方法，都会被解释执行，不会调用原来编译好的native code

基于以上对比，具体使用哪一种方案，可以从以下几个因素考虑：

• 团队技术积累。假如项目团队已经自己的有完整的成熟的框架，比如前后端都是Lua，那么选择Lua可能更合适；假如前后端都是C#，比如ET框架，那么就得选C#
• 团队大小。比如是小游戏或者休闲游戏，团队人数也比较少，那么选择自己喜欢的、熟悉的语言和框架就行
• 稳定性。各种热更方案都有各自的优劣，但是最终都要保证稳定性，要经过市场的检验。

最后，从技术原理和语言特性来说，除去以上的几个因素，最优的选择肯定是HybirdCLR，不管是运行性能、开发语言（因为Lua真的不适合做大型项目，特别是如果没有严格的编码规范的话，后期维护成本太大）