Lua,ILRuntime, HybridCLR(wolong)/huatuo热更对比分析

这两年，各种Unity热更新方案如雨后春笋般出来了，今天来写篇文章来对比一下Unity各大热更新方案的优缺点。目前主流的Unity热更新的方案有:

Lua系解决方案: 内置一个Lua虚拟机,做好UnityEngine与C#框架的Lua导出。典型的框架有xLua, uLua,大体都差不多。

ILRuntime解决方案: 内置一个.net 字节码解释器,解释执行.net字节码。

puerts解决方案: 内置一个JavaScript/TypeScript解释器，解释执行TypeScript代码。

HybridCLR(wolong) huatuo: HybridCLR(wolong)之前的名字叫做huatuo,在Unity的il2cpp里面添加一个可以装载.net字节码,解释执行.net的字节码的功能。

 对啦！这里有个游戏开发交流小组里面聚集了一帮热爱学习游戏的零基础小白，也有一些正在从事游戏开发的技术大佬，欢迎你来交流学习。

接下来我们从几个点来分析比对这几个热更新的方案:

(1) 可热更的代码的范围;

(2) 发布新版本的时，新版本的性能与老版本热更;

(3) 热更解释执行效率的对比分析;

(4) 哪种方案更符合开发者的开发习惯;

可热更的代码的范围对比

Lua,方案都是项目种内置Lua虚拟机,它能热更的范围是使用Lua开发的所有脚本都可以热更，C#开发的代码可以通过提前的hotfix来做热更补丁。虽然Lua方案看上去Lua代码和C#代码都可以热更，但是其实hotfix来做c#代码热更的时候，需要打标记,你无法预判哪些需要C#可能会被更新，同时hotfix经过几个版本迭代，以前版本有热补丁，新版本没有热补丁，管理起来非常的麻烦。

ILRuntime/purets方案都是Unity内置.net字节码解释器/TypeScript/JavaScript解释器, 在热更项目中编写的代码,都可以热更，但是普通C#编写的代码无法热更新。HybridCLR(wolong) huatuo方案: 在IL2CPP VM中内置一个.net 字节码解释器,同时还会把.net里面的数据对象映射到native 的数据对象,所以huatuo的任何c#编写的代码都可以热更新。

这一局, HybridCLR(wolong) huatuo完胜。可以更新任意C#实现的代码，如果要热更新，就把这个c#代码所在的.dll字节码库装载到il2cpp vm 就可以解释执行,如果不加载.dll的字节码，就使用原来的 il2cpp的native代码。

新版本的性能与老版本热更

这一局也是HybridCLR(wolong) huatuo完胜,当有新版本发送的时候，比如1.0, 我们开发了一些热更代码，到2.0, 发布2.0的时候，1.0的是热更了服务器上的代码解释执行, 2.0是直接代码就可以了，但是Lua/purets/ILRuntime 2.0版本都是解释执行，而HybridCLR(wolong) huatuo, 1.0是加载更新的.dll 到il2cpp vm虚拟机，解释执行IL字节码。但是当我们发布2.0的时候，就不用加载.dll, 那么直接使用2.0 il2cpp转好的native代码直接可以被机器执行，所以其它方案都是解释执行，而HybridCLR(wolong) huatuo新版本是native 代码。总结一下Lua/ILRuntime/puerts热更方案，新版本都是解释执行热更代码，而HybridCLR(wolong) huatuo使用native代码直接运行，新版本native性能,比解释执行性能要好。

热更解释执行效率的对比分析

上面分析了，新版本的时候，Lua/ILRuntime/puerts仍然是解释执行，而HybridCLR(wolong) huatuo是native code,接下来分析一下都是热更解释执行效率与性能的对比，Lua/ILRuntime/puerts是在C#层内置虚拟机,所以热更代码的内存，都是运行在虚拟机域的内存对象,如果要访问native c#的对象，都要用函数包起来来访问，而HybridCLR(wolong) huatuo在解释执行IL字节码的时候，先把字节码的对象内存，映射成native内存块，所以热更解释执行IL字节码的同时，能直接访问 native内存对象。这样就不用像其它热更一下用函数包起来,性能达到最好。数据对象的内存访问已经讨论了，接下来在看解释执行，都是解释二进制字节码,这些解释执行的效率基本都在一个数量级上，由于HybridCLR(wolong) huatuo可以直接访问native 内存对象，所以热更部分的执行性能上HybridCLR(wolong) huatuo要优于其它方案。

哪种方案更符合开发者的开发习惯

这局又是HybridCLR(wolong) huatuo完胜,使用HybridCLR(wolong) huatuo热更方案的时候，你不用管哪些要热更，哪些不用热更新,只要按照模块利用Unity 的ADF机制来生成不同的项目,并生成对应的.dll, 底层打包的时候，都统一用il2cpp转成native code, 如果新版本哪个.dll 要更新了，只要把生成的新版本的.dll放服务器上，那么就从服务器装载进来到il2cpp vm中，这样就可以解释执行。所以HybridCLR(wolong) huatuo 和普通的Unity开发几乎一样。

而其它的方案,都要分成native c# 工程和热更项目代码，这样不方便相互之间的调用，还要维护热更代码与框架代码等，比较麻烦,不符合普通Unity的开发习惯。如果你有一个Unity的项目要支持热更新，一定使用HybridCLR(wolong) huatuo方案能让你少改代码。所以开发习惯这块，HybridCLR(wolong) huatuo优于其它的方案。

通过几个对比，以HybridCLR(wolong) huatuo为代表的基于il2cpp vm的热更方案，将会是Unity热更方案的主流首选。如果不出意外，未来的热更的趋势就是HybridCLR(wolong) huatuo这种技术原理的热更方案。

本节分享就到这里，关注我，可以学习更多的Unity游戏开发，框架设计相关知识。