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游戏开发，框架设计相关知识。