为什么此刻大部门Unity公司还是在用Lua热更新?
前言热更新,在手游时代一出来,就成为了开发者着要解决的一道难题。因为每次发布新版本,如果都去安装,好不容易拉来的用户,就流掉了,毕竟你不是《王者荣耀》和和平精英,玩家会主动更新。有时候为了做游戏活动,我们可能要改削活动代码,活动过后,又结束,所以就需要有一种手段,用户不用从头安装游戏的情况下,能更新一些代码和业务逻辑。
热更新分为2部门:代码热更新与资源热更新,资源热更新有成熟的流程,以前的AssetsBundle以及此刻的Addressable。热更新代码就成了开发者要并吞的难题。
unity C#代码,在运行的时候,先把所有代码(框架+逻辑)都加载到内存,然后执行代码,所以代码加载完成,就无法再改了, 所以普通的C#代码,无法做代码热更新。 代码热更新的基本道理是内置一个代码解释器,游戏app运行的时候,先把底层C#代码与代码解释器运行起来,进入入口函数后,再加载游戏逻辑代码,加载完成,再使用解释器来解释执行 “逻辑代码”。这样就有机会在入口函数的时候,先到云端的处事器上把最新的逻辑代码下载下来,然后再加载到内存,完成加载后,跑最新的代码逻辑。
搞懂的热更道理以后,问题就变成了,内置哪个脚本语言的解释器?使用哪个脚本语言开发。游戏行业和其他行业纷歧样,大部门的核心功能都在游戏引擎代码中,而游戏引擎的代码,基本上每个引擎各成一体,没有统一的尺度, 所以做为游戏行业的脚本语言,就需要2大特点:高效,轻量级。高效指的是脚本语言执行高效,轻量级指的是脚本语言很容易嵌入游戏引擎,同时脚本的体系不大,没有过多的与语言本身无关的系统和库内置在里面。满足这两大特点,的脚本语言其实不多。有一个编程语言,在它创立之初就是保持这2大理念,在2001年摆布的时候被魔兽世界选为脚本语言,而风靡游戏行业,这个语言就是Lua。当Unity 需要做热更新的时候(2013年开始),而普通的C#又做不到的时候,而对于游戏行业来说Lua脚本热更新已经是很成熟的方案,自然Lua 热更新就成为了Unity热更新的首选。
基于Lua做Unity热更新,需要解决两大问题:
(1)Unity引擎内置Lua解释器, 可内置尺度Lua,与运行性能更好的LuaJIT。
(2)导出Unity引擎接口给Lua脚本调用。
这两大问题有开源的框架帮我们解决了,著名的就有xLua与uLua。基于这两大框架,我们就可以使用Lua来开发Unity项目了。
所以Lua在Unity热更新中的地位,是行业历史选择的必然成果。但是Lua毕竟不是Unity指定的C#,
很多同学不会Lua,此刻热更新也多了一些解释型C#的方案,里面的佼佼者就是 C# Light与ILRuntime。此刻ILRuntime热更也在Unity中慢慢风行起来。附视频教程 大师可以去主页学习小组参考一下
页:
[1]