写在前面
\\xLua是Unity3D下Lua编程解决方案,自2016年初推广以来,已经应用于十多款腾讯自研游戏,因其良好性能、易用性、扩展性而广受好评。现在,腾讯已经将xLua开源到GitHub。
\\2016年12月末,xLua刚刚实现新的突破:全平台支持用Lua修复C#代码bug。
\\目前Unity下的Lua热更新方案大多都是要求要热更新的部分一开始就要用Lua语言实现,不足之处在于:
\\xLua热补丁技术支持在运行时把一个C#实现(函数,操作符,属性,事件,或者整个类)替换成Lua实现,意味着你可以:
\\这个新特性iOS,Android,Window,Mac都测试通过了,目前在做一些易用性优化。
\\那么,腾讯开源的xLua究竟是怎样的技术?它是为何如此设计的?更令人关心的是,xLua的性能如何?带着这些问题,InfoQ对其作者进行了采访并将内容整理成文。
\\嘉宾简介
\\车雄生,05年毕业,在华为工作了6年,跟着先后在两游戏创业公司待了几年,15年进入腾讯互娱公共组件中心。目前专注于一些游戏公共组件的开发。
\\技术背景
\\腾讯自研手游,就我了解的项目来说,大多数游戏引擎都是Unity3D,少数用coco2d。
\\xLua这个插件具体用到了哪些游戏中?虽说xLua是2015年3月就完成了第一个版本,但由于当时项目组热更的意识并没有很普遍,需求不是很强烈,xLua的开发资源都调到更紧急的项目了。直到15年年底正式集成到我们的apollo手游开发框架,才迎来xLua的第一个项目。到目前为止,我们已知的应用了xLua的项目有十多个,其中不乏一些重量级IP,或者按星级标准打造的产品。
\\在xLua之前,面对iOS无法热更新的问题,有用ulua的,有用slua的,也有项目用自研的脚本语言,不过当时用人更新的项目也不多。
\\热更新流程
\\手游的热更新流程很简单,只是启动时检测下是否有新版本文件,有的话就下载覆盖老文件,然后启动。
\\ \\下载的文件如果是图片,模型这些是没问题的,但如果是Unity原生的代码逻辑,无论是以前的Mono AOT或者后来的il2cpp,都是编译成native code,iOS下是跑不了的。
\\解决办法就一个,别用native code,别用jit,解析执行就可以了。包括xLua在内的所有热更新支持方案都是通过“解析执行”来实现代码逻辑热更新。
\\来自xLua的 Hello world
\\(1)三行代码跑lua脚本
\\一个完整的例子仅需3行代码:
\\下载xLua后解压到Unity工程Assets目录下,建一个MonoBehaviour拖到场景,在Start里头加上这么三行:
\\\XLua.LuaEnv luaenv = new XLua.LuaEnv();\luaenv.DoString(\"CS.UnityEngine.Debug.Log('hello world')\");\luaenv.Dispose();\\\
运行就可以看到Console打印的hello world。
\\(2)C#调用lua系统函数math.max
\\xLua支持把一个Lua函数绑定到C# delegate。
\\我们先声明一个delegate,并为它加上CSharpCallLua标签:
\\\[XLua.CSharpCallLua]\public delegate double LuaMax(double a, double b);\\\
然后在上面那例子加上这么两行(luaenv销毁前):
\\\var max = luaenv.Global.GetInPath(\"math.max\");\Debug.Log(\"max:\" + max(32, 12));\\\
就那么简单,把lua的math.max绑定到C#的max变量后,调用就和一个C#函数调用差不多了,而且,最最重要的是,执行了“XLua/Generate Code”后,max(32, 12)调用是不产生(C#)gc alloc的,既优雅,又高效!(更详细的可以看XLua\\Doc下的文档。)
\\xLua全局观
\\(1)易用性:编辑器下无需生成代码支持所有特性
\\xLua的易用不仅仅体现在编程,还体现在方方面面的细节考虑,甚至考虑到团队配合工作流。
\\xLua仅有两个菜单选择,分别是生成代码和清除生成代码。在菜单之外,甚至只需要在build手机版本前执行一下“Generate Code”即可(这也有API可集成到项目的自动化打包流程)。
\\这就是xLua的特色功能之一:编辑器下无需生成代码支持所有特性。
\\之所以做这个功能,是因为有的项目反馈,“生成代码”对于策划美术太过遥远,教了很久还是老忘;还有个大项目反馈说由于代码很多,每次生成代码后,Unity3D都要转很久。
\\(2)扩展性:授之以鱼,不如授之以渔
\\开发中我们往往要用到很多东西,比如用PB和后台交互,解析json格式的配置文件等等。虽说我们都可以在C#那找到相应的库,然后通过xLua去使用这些库,但这效率不高,最好能有相应Lua的库。
\\不少方案是直接集成一些常用的Lua库,但这带来些新问题:这些库不一定用到,却增大安装包;集成的库也不一定符合项目习惯:json解析有人喜欢rapidjson,有人爱用cjson,所谓众口难调;对于某些项目,这些库还是不够,还是得自己去想办法加;
\\腾讯团队的设计原则是授之以鱼,不如授之以渔,因此xLua:
\\(3)性能的保证
\\游戏的性能备受关注,因此任何模块的变化都需要尽可能不降低甚至调优游戏整体的性能。xLua设计原则是在保证运行效率的前提下,尽量的保证开发效率。
\\对于性能这块,有几个至关重要的版本:
\\第一个版本1.0.0在05年3月份发布,当时delegate,interface作为最主要的C#访问Lua的设定,从接口层面避免了boxing、unboxing、gc alloc,这是一个良好的起点。做一个通用组件的都知道,接口一开始设计不合理导致的问题很难解决,别人已经用了,甚至已经养成习惯了,很难纠正。ps:说起这习惯,有的从别的lua插件转为使用xLua的童鞋,一开始习惯用LuaFunction.Call去调用lua(xLua也保留了这接口,可用于性能要求不高的场合),他们后期就痛苦了,还得一个个地方的改回来。
\\第二个很重要的版本是2.0.0(06年3月发布),这版本主要目标就性能优化,因为当时有个对性能要求极其严苛的项目想用lua,严苛到什么程度呢?他们觉得C#性能都不放心,战斗系统打算用C++写。那版本我们把虚拟机切换到luajit,加入了lazyload技术,逐行语句的优化,甚至关键地方不用C#提供的容器,自己写专用的(比Dictionary实测性能高4倍)。。。可以认为我们重做了一个xLua。最终他们的选型测试结论是选xLua。
\\后来和一些项目的交流发现,项目组很关注gc alloc这指标,甚至比lua和C#间的互调性能指标还要看重。于是有了2.1.0版本(06年7月发布),这版本主要目标是gc优化,我们重写了反射,反射调用的gc减少到原来的几分之一,性能提高了3倍左右。我们设计了一个全新的复杂值类型支持方案,该方案支持的类型更多(只要struct的字段都是值类型即可),包括用户自定义的struct(别的方案都不支持),也更省内存(Vector3为例,内存占用只有别的方案的30%)。但也有劣势的地方,比如你调用Vector3上的一些方法,会比ulua、slua要差,因为后面两个把Vector3用lua重新实现了,这类耗时不大的运算相比lua和C#直接的适配成本小太多了,直接在lua做更划算,不过这差距仅限于那几个ulua、slua完全重新实现的类。
\\上面只是三个重大节点,我们觉得性能是一个需要持续关注的点:平时想到一个好点子,就会改改,测试下,有提升就加入;建立性能基线,防止某个新功能的加入,某个bug的修改把性能给改坏了。
\\xLua内置Lua代码profiler;支持真机调试。目前lua profiler只是一个小工具,所以没有做图形化界面,典型的一个报告如下:
\\ \\网上也有类似的工具,我们这个的优势是对C#函数的支持以及luajit下更为准确。
\\真机调试支持各lua插件都一样,就是把ZeroBraneStudio调试需要用到的luasocket库预先编译进去而已,没什么值得介绍的地方。
\\技术实现的细节
\\(1) 泛型
\\泛型类型除了运行时动态实例化之外都支持,而运行时动态实例化需要jit的支持,iOS下行不通。举个例子,如果你配了对Dictionary\u0026lt;int, string\u0026gt;生成代码,那这个类型是可以用的,但如果你新更新的lua代码,想用一个Dictionary\u0026lt;int, double\u0026gt;,这个类型之前没生成代码,而且C#里头也没任何地方使用过,这就不支持。静态实例化的泛型,其实和非泛型类型处理上没区别。
\\(2) 委托事件的封装
\\委托封装是根据委托的接口生成一段操作lua栈的代码作为委托的实现。举个例子就很好懂了。比如对于委托:delegate double Add(double a, double b),我们生成如下代码:
\\\public double SystemDouble(double a, double b)\{\ RealStatePtr L = luaEnv.L;\ int err_func =LuaAPI.load_error_func(L, errorFuncRef);\ \ LuaAPI.lua_getref(L, luaReference);\ \ LuaAPI.lua_pushnumber(L, a);\ LuaAPI.lua_pushnumber(L, b);\ \ int __gen_error = LuaAPI.lua_pcall(L, 2, 1, err_func);\ if (__gen_error != 0)\ luaEnv.ThrowExceptionFromError(err_func - 1);\ \ double __gen_ret = LuaAPI.lua_tonumber(L, err_func + 1);\ LuaAPI.lua_settop(L, err_func - 1);\ return __gen_ret;\}\\\
这代码把调用转给lua函数,调用委托就是调用这函数。
\\其它方案都有delegate的支持,一般仅用于在lua侧主动传递/设置一个lua函数到C#,而xLua支持更为完整,比如:
\\作为这技术的一个延伸,xLua支持用一个c# interface引用一个lua table,这个特性和一些IOC框架配合可以实现C#和Lua间无感知(模块间都通过interface耦合,然后由框架去组装)。
\\(3) 无缝支持生成代码及反射
\\生成代码固然重要,已然是各大主流方案的标配。
\\反射有的方案明确不支持,但从项目的反馈来说,也是至关重要的:有的项目代码很多,已经接近苹果的80M Text段的限制,对他们来说,代码量大小关乎到能否发布,反射方式性能不如生成代码,但对安装包影响小。
\\这的无缝有两个含义:
\\对于il2cpp的stripping,xLua也考虑到了,只要你对一个类配置了ReflectionUse,会自动生成Unity的link.xml配置文件,将该类型列为不剪裁。
\\其他Lua插件一览
\\在xLua之外,还有其他的Lua插件,如 uLua、SLua、C#light等。
\\(1) ulua应用项目是最多的,由于开源得早,名气也最大,这是它很大的优势。腾讯也有项目用ulua,反馈比较多的问题是它版本的前后兼容问题:
\\(2) slua代码质量比cstolua好很多(很多人当时选slua的理由),部分支持反射。性能按我们的测试用例整体比tolua c#略低,另外代码质量对比tolua c#已经形成不了明显优势。
\\(3) C#light,个人觉得主要有两个不足:
\\事实也证明了,C# light基本淡出市场,可以忽略不计了。
\\(4) LSharp是C# light作者的后续作品,倒是可以期盼些,从il层面执行,这两个问题有望改善,可惜后面没了下文(不维护了)。
\\相比之下,腾讯在设计xLua时,实现的功能更全,这“全”体现在C#的特性支持得更全些,lua虚拟机版本支持更全;更易用些,比如编辑器下不用生成代码;另外,性能也不比它们差。
\\说到功能更全,可能有人抱怨并没有pb,json,sqlite等等功能。其实稍熟悉lua的人都知道,那只是把一些现成lua扩展编译进去而已,算不上是它做了这些功能。预集成好处是方便,坏处是没选择的余地,用不上的东西会占空间,用得上的东西也不一定是你喜欢的库。
\\xLua的lua库基于cmake编译,要加这些库门槛很低,有教程,改一个Makefile搞定各平台编译。在C#测也提供了api来初始化这些库。总而言之,xLua的原则是授之以渔。
\\xLua的灵感来源
\\xLua立项当初,考察了当时能找到的所有方案,并分析各方案优劣,定出第一个版本的特性,大体是基于NLua基础上加上代码生成。介绍下NLua,NLua的作者就是LuaInterface的作者,NLua可以认为是LuaInterface的升级版,而前面也说了,第一版uLua是LuaInterface的Unity移植版本,也不能算原创。
\\因为是“站在”生成代码当时有看过cstolua的实现(那时还没挂ulua的牌),觉得它通过硬编码字符串拼接的方式维护性不太好,就用模版来做。感觉这步是走对了,后续生成代码调整起来比较简单,这对性能调优很有好处。
\\经过十多个版本的迭代,优化,现在NLua的影子比较淡了(NLua仅支持反射,而xLua的反射在2.1.0版本已经完全重写),就剩下C#引用类型对象在lua的表达的思路没变。
\\此外,遇到需要调整较大的bug,我们也会先看同类插件是不是已经解决了,对比他们的修改方案和我们的,选更适合的。
\\xLua背后的研发与团队
\\xLua目前迭代了十多个版本,从第一个项目开始,平均一个月一个版本。
\\研发团队人员目前有一个全职开发。测试使用的是腾讯互娱的公有资源,很规范:有一套不断补充的功能自动化用例,性能测试也建立了基线,确保不会因为功能迭代而影响性能。腾讯互娱有专门的客户端兼容性测试实验室,至少中版本号以上的变动我们会提交给他们针对top 100的机型进行兼容性测试。
\\至于lua,luajit的更新跟进,先说luajit吧,luajit变动不大,我第一次用luajit是11年,那时支持到lua5.1,现在也还是lua5.1,中间只是一些bug的修复,性能优化,或者新平台支持等,我们要做事情不多。而lua中版本间差别还是蛮大的,但中版本变动并不频繁,从5.1到5.2用了6年,从5.2到5.3用了3年,5.3是2015年初发布的,我个人觉得到下一次中版本变动会很久,不亚于甚至大于5.1到5.2的时间跨度(5.2个人认为只是一个过渡版本)。
\\小版本一般改改bug,等稳定后直接升级就可以了,不需要做很多事情,目前xLua的lua版本用的是lua的最新版本5.3.3。
\\聊聊C#,谈谈Lua
\\C#在开发效率和运行效率平衡得很好,语言特性也比较全,个人觉得是很优秀的一门语言。在Unity3D上的缺憾主要是其mono版本太低,一些很古老的bug,比如著名的foreach性能问题很多个版本都没解决,新的特性,比如await又不支持。
\\另外在手机平台iOS不允许应用下载native code运行,jit,刚好把mono应用的热更新给堵死了,要是mono虚拟机能够做到像luajit那样,jit走不通就用interpret模式,其实就没lua或者其它热更新方案什么事了。
\\而lua被称为游戏脚本之王,在游戏领域应用比较广泛,它设计之初就考虑到嵌入式领域,比如相对它提供的特性来说,它体积非常小,启动一个vm占资源也不多,性能也是脚本里头的佼佼者。
\\lua相对C#而言,首先是它支持解析执行,进而支持热更新。而免编译对开发效率提升也是蛮大的,特别是较大的项目。
\\lua的动态类型有利有弊,好的是没有编译期的类型检查,快速开发比较有优势,特别在需求三天两头就变的游戏领域。缺点是要做出健壮的软件得有大量的测试来保证,还有由于要做运行期检查,性能会比静态类型语言低。
\\lua的一大特色是语言级的协程(coroutine)的支持,比Unity3D基于generator模拟的协程要好很多,对于复杂异步业务逻辑编写很有帮助,xLua的配套例子有范例(ps一下,Unity3D的mono版本升级到支持await的话,是更理想的异步方案)。
\\至于C#和lua间如何配合,可能每个人都有不同的看法,但至少有一点是确定的:需求变更大,预计很可能需要热更的地方,用lua。当然,也可以尝试最新的开发模式,全C#开发,lua fix bug。
\\写在最后
\\xLua应该还有不足,我们会在发现的第一时间去修改。腾讯xLua团队极度欢迎大家在发现不足之后提出反馈。
\\