这两年，各种Unity热更新方案如雨后春笋般出来了，今天来写篇文章来对比一下Unity各大热更新方案的优错误谬误。目前主流的Unity热更新的方案有:
对啦！这里有个游戏开发交流小组里面堆积了一帮热爱学习游戏的零基础小白，也有一些正在从事游戏开发的技术大佬，欢迎你来交流学习。


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


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


新版本的性能与老版本热更
这一局也是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性能,比解释执行性能要好。
热更解释执行效率的对比分析


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


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