他的最新文章
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)为什么unity3d引擎只能做一些手游，中小型游戏，大型游戏为什么不用，难道unity3d引擎的极_百度知道
为什么unity3d引擎只能做一些手游，中小型游戏，大型游戏为什么不用，难道unity3d引擎的极
为什么unity3d引擎只能做一些手游，中小型游戏，大型游戏为什么不用，难道unity3d引擎的极限达不到大作的水准？
我有更好的答案
还有铁血的闪回是不是也是unity。大游戏宁可自己开发独立引擎或是用Unreal这类基于C++的引擎看了几个Unity的都是界面简单内容简单的，像是战舰海战，室内突击，名字记不清了，大致这个意思。还是用的C#/JAVA脚本处理速度跟不上，积木类游戏工具的通病
为您推荐：
其他类似问题
unity3d的相关知识
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。腾讯开源手游热更新方案，Unity3D 下的 Lua 编程
xLua是Unity3D下Lua编程解决方案，自2016年初推广以来，已经应用于十多款腾讯自研游戏，因其良好性能、易用性、扩展性而广受好评。现在 腾讯已经将&&开源到GitHub。2016年12月末，xLua刚刚实现新的突破：全平台支持用Lua修复C#代码bug。目前Unity下的Lua热更新方案大多都是要求要热更新的部分一开始就要用Lua语言实现，不足之处在于：接入成本高，有的项目已经用C#写完了，这时要接入需要把需要热更的地方用Lua重新实现；即使一开始就接入了，也存在同时用两种语言开发难度较大的问题；Lua性能不如C#；xLua热补丁技术支持在运行时把一个C#实现（函数，操作符，属性，事件，或者整个类）替换成Lua实现，意味着你可以：平时用C#开发；运行也是C#，性能秒杀Lua；有bug的地方下发个Lua脚本fix了，下次整体更新时可以把Lua的实现换回正确的C#实现，更新时甚至可以做到不重启游戏；这个新特性iOS，Android，Window，Mac都测试通过了，目前在做一些易用性优化。那么，腾讯开源的xLua究竟是怎样的技术？它是为何如此设计的？更令人关心的是，xLua的性能如何？带着这些问题，InfoQ对其作者进行了采访并将内容整理成文。技术背景腾讯自研手游，就我了解的项目来说，大多数游戏引擎都是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。第一和第三行分别LuaEnv的创建以及销毁，所谓LuaEnv可以理解为lua虚拟机，往往整个工程一个虚拟机即可：DoString里头可以是任意合法的lua代码，例子中调用了UnityEngine.Debug.Log接口打印了一个log（C#的静态函数在CS下直接可用）；（2）C#调用lua系统函数math.maxxLua支持把一个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：提供了接口、教程，在不修改xLua代码的情况下，开发者可以根据个人喜好加入库；通过cmake实现跨平台编译，可以选择伴随xLua一起编译，修改一个makefile文件，搞定各平台编译。除了很方便加入第三方Lua插件，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&int, string&生成代码，那这个类型是可以用的，但如果你新更新的lua代码，想用一个Dictionary&int, double&，这个类型之前没生成代码，而且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_
}这代码把调用转给lua函数，调用委托就是调用这函数。其它方案都有delegate的支持，一般仅用于在lua侧主动传递/设置一个lua函数到C#，而xLua支持更为完整，比如：支持C#主动用delegate来引用一个lua函数。用delegate代替类似object[] Call(params object[] args)的接口调用lua最大的好处是可以避免值类型传递时的boxing/unboxing，还有参数数组，返回值数组的gc alloc；支持返回delegate的delegate，可对应到lua的高阶函数；作为这技术的一个延伸，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，反馈比较多的问题是它版本的前后兼容问题：ulua最早是一个叫LuaInterface开源库的Unity移植，在2015年初换成cs2lua，又在2016年初换成tolua c#，只所以说“换”，是因为这从API角度看可认为三个不同的产品，它们间很难升级，而且是每换一次，之前的版本就彻底不维护了，这给项目带来很大的困扰。ulua的第一个版本纯反射，并不实用，已经淡出市场，现存应用用后两个版本居多。cstolua版本接口比较混乱：它保留了第一版ulua接口之余，搞了一套新接口，这两套接口之间并不正交，也不是后者完全替代前者，让人有点无所适从。到了tolua c#版本，这问题解决了，但同时也把反射特性（老接口）给废了。不过总体来说，ulua在向好的方向走。(2)&slua&代码质量比cstolua好很多（很多人当时选slua的理由），部分支持反射。性能按我们的测试用例整体比tolua c#略低，另外代码质量对比tolua c#已经形成不了明显优势。(3)&C#light&，个人觉得主要有两个不足：按其实现原理来说，性能不会靠谱，到不了手机上实用的地步；由于不完整支持C#，本质上只是另一种叫C#light的语言（C# like？名字倒很贴切），这两者代码配合起来也复杂，甚至它能做到比C#和lua配合更复杂些事实也证明了，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#，谈谈LuaC#在开发效率和运行效率平衡得很好，语言特性也比较全，个人觉得是很优秀的一门语言。在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团队极度欢迎大家在发现不足之后提出反馈。稿源：
xLua 的详细介绍：
xLua 的下载地址：
转载请注明：文章转载自 开源中国社区
本文标题：腾讯开源手游热更新方案，Unity3D 下的 Lua 编程
本文地址：登录以解锁更多InfoQ新功能
获取更新并接收通知
给您喜爱的内容点赞
关注您喜爱的编辑与同行
966,690 二月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
腾讯开源手游热更新方案，Unity3D下的Lua编程
腾讯开源手游热更新方案，Unity3D下的Lua编程
2&他的粉丝
日. 估计阅读时间:
，人工智能、区块链、大数据、架构等领域海内外先驱实践！
亲爱的读者：我们最近添加了一些个人消息定制功能，您只需选择感兴趣的技术主题，即可获取重要资讯的。
Author Contacted
语言 & 开发
295 他的粉丝
架构 & 设计
701 他的粉丝
0 他的粉丝
0 他的粉丝
0 他的粉丝
0 他的粉丝
10 他的粉丝
572 他的粉丝
2 他的粉丝
2 他的粉丝
相关厂商内容
相关赞助商
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
架构 & 设计
文化 & 方法
InfoQ.com及所有内容，版权所有 ©
C4Media Inc. InfoQ.com 服务器由 提供, 我们最信赖的ISP伙伴。
极客邦控股（北京）有限公司
找回密码....
InfoQ账号使用的E-mail
关注你最喜爱的话题和作者
快速浏览网站内你所感兴趣话题的精选内容。
内容自由定制
选择想要阅读的主题和喜爱的作者定制自己的新闻源。
设置通知机制以获取内容更新对您而言是否重要
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。这可能是针对MMORPG最全的一份Unity手游性能蓝皮书
这可能是针对MMORPG最全的一份Unity手游性能蓝皮书
优化是一个“抽丝剥茧”的过程，需要研发团队花费大量的时间和耐心去完成。正值UWA成立两周年之际，借着ChinaJoy蓄势待发之势，UWA发布年Unity手游性能测评数据分析蓝皮书，希望能为游戏行业的从业人员提供详实的信息和针对性的建议。此份蓝皮书收集了提交到http://www.uwa4d.com上的所有项目，我们从总体性能数据、引擎各模块开销、内存占用等方面进行了汇总分析，这呈现Unity手游行业现状。报告目录：一、MMORPG手游总体性能开销分析二、MMORPG手游CPU模块性能开销分析三、MMORPG手游内存模块性能开销分析四、MMORPG手游资源管理分析五、UWA对于MMORPG手游研发团队的建议一、MMORPG手游总体性能开销分析iOS设备的CPU性能普遍高于Android设备，Android设备的CPU均值主体范围为14.4~73.6 ms，iOS设备的CPU均值主体范围为9.2~43.5 ms。在Android设备上，CPU耗时集中在17~50ms区间，而在iOS设备上，CPU耗时集中在33ms以内。我们选择了测评次数最多的四款机型来进行统计，这四款机型分别是红米2、红米Note2、华为6Plus和三星S6。1）大部分MMORPG手游在中低端设备的性能开销较高，大于33ms的耗时占比范围在60%~70%。2）精品化过程中的MMORPG手游在低端移动设备上的CPU开销明显增大。相较2016年同期，2017 Q2 MMORPG手游的CPU开销均值增长超过50%。无论是高、中、低端的Android设备，渲染、UI、加载/代码都是需要研发团队重点关注的，它们的消耗总和占了总开销的80%。下面我们就来具体分析这些主流模块的开销情况。二、MMORPG手游CPU模块性能开销分析1. 渲染模块严重程度：地狱为了能够更好地反映出各个性能参数的整体使用情况，我们统计了每种性能参数的主体使用范围，其范围区间是[5%~95%]，以下数据中P5代表5%，P95代表95%。MMORPG手游的Draw Call数量普遍较高，且设备性能越好，数量峰值越高。这主要有以下几方面原因：1）研发团队普遍开始针对不同机型来制定自适应的渲染LOD策略，主要包括模型LOD和Shader LOD等。2）除LOD外，研发团队同样会对一些渲染效果进行有针对性的设置，最常见的是阴影的处理，高端机上开启实时阴影，而低端机上则通过较为简单的阴影面片或Projector来处理。另外，水体模拟也越来越多地在项目中被使用，高端设备上开启水面反射效果，也会增加一定量的Draw Call。但就目前数据表明，研发团队已经开始有意地对Draw Call进行控制，UWA建议Draw Call占用的P95 & 200，72.3%的项目可以将其控制在这个范围内。1）MMORPG手游的场景渲染三角形面片数量普遍较高。且设备性能越高，数量峰值越高。经过统计，在中低端设备中，40.4%的项目能将渲染三角形面片数控制在100K以下。2）场景复杂程度明显增加，虽然2017 Q2数量有所回落，但相较于去年同期，仍然增幅33%。同时，较高的渲染面片数量也大幅增加了中低端设备的GPU渲染压力和耗能压力。Graphics.Bilt操作平均每次调用的CPU耗时主要分布在: 0.1~5.1ms。与Instantiate开销类似，该项CPU开销在低端设备上的上升趋势较为明显，但在2017 Q2大幅下降。这主要是因为，在2017 Q1后，MMORPG项目普遍开启了多线程渲染功能。2. UI模块严重程度：地狱使用NGUI作为UI解决方案的项目占据了相当高的比例，NGUI目前仍然是MMORPG研发团队对于UI系统使用的主要解决方案。MMORPG是目前手游中工程技术难度最为复杂的游戏品类之一，对于UI模块的选择，大多数团队仍然倾向于从稳定性和把控性两方面出发，这也是NGUI占比持续较高的主要原因。下面我们将分别说明NGUI和UGUI的CPU耗时和堆内存占用情况。UI模块的性能开销依然很高，也是我们统计中的第二大性能杀手。在中低端设备上，超过90%的研发项目在UI端都面临较为严重的性能问题，主要体现在以下几个方面：（1）MMORPG游戏的界面复杂，功能多（技能、背包、角色、任务、商城等），数量大（血条、名称、飘字等HUD）。（2）同一时刻存在大量需要更新的Panel，比如，移动中血条等HUD、NPC不断更新的提示icon、面板中（任务、首充等）的提醒动画、聊天框和弹幕中随机出现的滚动文字等。以上情况都是MMORPG项目研发团队每天面对的主要UI问题，可能一个Widget的使用疏忽，就能让研发团队的UI模块性能开销飙升一个量级。注意：从重要函数上来看，UGUI的CPU占用大幅低于NGUI。需要说明的是，Unity 5.2版本之后已经开始将UI的部分计算操作移到子线程中进行，而主线程中的表现则为WaitingForJob、PutGeometryJobFence等，在本次报告中，我们并没有将这两项开销统计在内。经统计，NGUI中堆内存每10000帧分配的主体范围为 6.1~103.3 MB，UGUI中堆内存每10000帧分配的主体范围在10.9 MB以内。从堆内存分配来看，UGUI远低于NGUI。3. 逻辑代码严重程度：噩梦1）GC触发频率很高，是造成卡顿的主要原因之一，目前只有10%的项目可以将GC的触发频率控制在1000帧/次以上。2）随着MMORPG游戏越来越重度化，GC平均耗时在逐步上升。GC耗时会逐渐成为游戏运行时的主流性能杀手，需要研发团队时刻注意！1）Instantiate实例化操作平均每次调用的CPU耗时主要分布在: 1.4~33.1 ms，且主要集中在10ms以内。2）Instantiate实例化耗时在2017 Q2之前一直处于上升趋势，但在2017 Q2中大幅下降，这说明越来越多的研发团队开始重视项目运行时的资源管理。Shader.Parse 操作是比较突出的性能杀手，目前平均每次调用的CPU耗时主要分布在 5.8~134.4ms。但随着越来越多团队了解该项的耗时特性后，该项的CPU耗时呈现出较为明显的下降趋势。4. 动画模块严重程度：噩梦1）Animator.Update/Animation.Update的开销在中低端设备上的耗时普遍较高，但整体耗时在2017年上半年明显降低。2）MeshSkinning.Update的耗时普遍较低。5. 粒子模块严重程度：普通1）粒子系统的CPU开销普遍较低，且近一年来下降趋势较为明显。2）粒子系统的数量使用仍然较大，这样会造成较高的内存占用。UWA建议将粒子系统的使用数量峰值控制在400以下，目前仅24.8%的项目达到。6. 物理模块严重程度：普通物理模块的性能普遍较好，但呈现出较为明显的上升趋势，因此在中低端机上依然需要研发团队关注。三、MMORPG手游内存模块开销分析内存泄露是研发过程中经常面临的严峻问题，依然有将近半数的项目存在不同程度的内存泄露。但我们可以看到，内存泄露的比例正在逐步降低，相较于去年同期，2017 Q2的内存泄露占比已经下降了6%。总体内存严重程度：地狱1）总体内存峰值主要分布在146.8~576.9 MB区间，且均值在350MB以上；2）随着MMORPG游戏的精品化趋势，其内存占用也逐步增加，虽然2016 Q4稍有回落，但整体内存的上升趋势较为明显。总体堆内存严重程度：地狱1）总体堆内存峰值主要分布为 18.3~117.2 MB，仅34.2%的项目可以把总体堆内存峰值控制在40MB以内；2）堆内存使用上升趋势明显，建议研发团队重点关注。对此，UWA建议重点关注以下几点：（1）严格关注配置文件的使用，避免一次性加载过大的配置文件而撑大堆内存；（2）不少项目的堆内存增大是由于热更新所致。因此，对于过大的数据Data的使用，建议通过分帧进行，并及时进行GC回收；（3）避免不必要的代码堆内存分配，虽然是老生常谈，但从趋势上可以看出，大多数研发团队仍需加强重视。项目的内存占用很大一部分来自于资源的使用，下面我们将对项目中主流资源的使用情况进行分析。1. 纹理资源内存严重程度：地狱1）纹理内存峰值主要分布为 27.8~174.6 MB，且主要分布在50~100MB区间。2）内存峰值占用在2016 Q4大幅下降，但在今年后又开始逐步上升，建议研发团队密切关注自身项目的纹理资源使用情况。2. 网格资源内存严重程度：噩梦1）网格资源内存峰值主要分布为 8.5~ 70.4 MB，且主要集中在40MB以内；2）MMORPG游戏的场景普遍较大、角色普遍较多，因此，其网格资源量明显高于其他类型游戏。但从使用趋势上来看，其最近一年的使用趋势较为平稳，均值均在30MB上下浮动。1）动画资源内存峰值主要分布在: 3.5~ 58 MB，且主要集中在15MB以内。2）内存使用趋势较为平稳，平均峰值内存长期控制在20~25MB区间之内。3. Shader资源内存严重程度：噩梦1）Shader资源内存峰值主要分布为 0.1~ 5.6 MB，且主要集中在1MB之内。2）从内存趋势上来看，2016年内存占用下降较为明显，2017年略有上升。4. RenderTexture资源内存严重程度：地狱1）RenderTexture资源内存峰值主要分布为 0.1~ 100.9 MB，且在各个区间都较为平均；2）内存使用上升趋势明显，建议研发团队对其在自身项目中的使用情况特别关注！5. 粒子系统资源内存严重程度：噩梦1）粒子系统资源内存峰值主要分布为 1.3~ 34.8 MB，且主要集中在20MB以内。2）粒子系统的内存占用在2016年Q3期间较高，而后在2016年Q4大幅下降，但仍然还有较大的下降空间。目前，粒子系统的内存占用较为“虚高”，即游戏运行期间Active数量远小于内存中的总数量，在大部分项目中，Active的粒子系统数量占比不到10%，即粒子系统的内存占用峰值应该在5MB左右。四、MMORPG手游资源管理分析1）在资源加载方面，AssetBundle.Load和Resource.Load是项目中的主要加载方式；2）通过调用趋势可以看出，研发团队对于Resources.Load的使用仍然有增加的趋势。对此，UWA强烈建议研发团队尽可能使用AssetBundle作为游戏资源的主要加载方式。1）LoadFromFile和New WWW是项目中AssetBundle的主要加载方式；2）LoadFromFile的使用在2017 Q2上升了6%，这是在UWA DAY 2017上我们非常建议的AssetBundle加载方式（Unity 5.3版本后），研发团队可以通过UWA Blog的相关文章查看具体的性能对比。Instantiate/Destory和Active/Deactive调用次数较高，需要研发团队根据自身项目情况时刻注意：1）由于Active/Deactive每次调用的CPU开销不大，且不会造成崩溃、闪退等问题，所以研发团队极易忽视这两项操作所带来的性能问题，因而出现了游戏运行1万帧Active/Deactive上万次调用的情况。因此，此处存在着很大的性能浪费；2）Instantiate/Destory的调用次数同样较高，虽然不如Active/Deactive频繁，但每5帧调用1次Instantiate的频率依然不容忽视，建议研发团队坚持加强项目的资源管理，避免不必要的频繁Instantiate/Destory操作发生。五、UWA 对于MMORPG手游研发团队的建议第一，警惕渲染模块和UI模块这两大性能杀手！随着精品化MMORPG项目的日益增多，这两项在接下来很长一段时间内依然是研发团队在性能优化时的重中之重！渲染方面，Draw Call的优化技巧已被越来越多的团队所熟练掌握，并且随着设备的发展，Draw Call的影响将越来越小，反观渲染Triangle数量将逐步成为渲染模块新的性能瓶颈，越来越大的渲染Triangle量会给GPU、耗电和发热等带来巨大的压力；UI方面，UI网格重建开销在未来相当长的一段时间内仍然是研发团队头痛的问题，目前手游MMORPG仍然处于“端游手游化”的转变初期阶段，大多数研发团队考虑更多的仍是功能上的迁移和与移动端的结合，在UI技术上的沉淀较为薄弱。第二，逻辑代码方面，Instantiate实例化开销虽然在2017 Q2呈现较为明显的下降趋势，但仍需要研发团队持续对资源管理进行监控。同时，GC开销上升趋势明显，需要研发团队加强对Mono堆内存的优化意识；第三，内存泄露占比持续下降，但内存占用持续升高。虽然移动设备的内存量逐年增大，但对于希望覆盖面广阔的游戏团队来说，内存的控制仍然刻不容缓；第四，在内存优化方面，大部分研发团队都将精力放在纹理、网格和动画片段等主要资源上，但通过上述分析发现，Mono堆内存和RenderTexture内存占用在2017年的上升趋势非常明显，对此，建议研发团队在接下来的研发中密切关注这两项的内存使用；第五，动画资源和粒子系统的内存优化空间依然很大。对于前者，建议研发团队关注以下技术：动画片段的精度缩减技术，该技术在UWA Blog和UWA问答上都有详细的讲解和代码分享；关注Retargeting技术，该技术可以大幅降低多角色的动画片段内存占用，预测随着MMORPG项目的进一步重度化，该技术会得到越来越多团队的青睐。对于后者，则建议研发团队关注粒子系统的资源配表，结合UWA线上性能报告，对不常使用的Particle System进行合理规划。六、资源加载方面，New WWW、Resources.Load依然是研发团队非常常用的资源加载方式。但UWA建议尽可能尝试通过LoadFromFile(Async)和AssetBundle.Load来加载相关资源，从而获得更好的性能。研发团队可在UWA Day 2017的相关Blog中找到对应的性能比较和分析；七、以上数据是我们对于MMORPG手游性能数据的整体研究和趋势分析，旨在从宏观上为大家展现项目中普遍存在的性能瓶颈和研发团队容易忽视的潜在性能问题。但同样需要说明的是，优化是一个“抽丝剥茧”的过程，需要研发团队花费大量的时间和耐心去完成。UWA建议：多做测试，以数据说话，空杯心态，将经验归零。以上就是UWA发布的年MMORPG手游性能测评汇总和分析。此次，我们从性能参数上增加了资源加载、资源卸载等数据扩充了报告的完整性，在测评参数上加入了机型、历史数据等方便研发团队能及时进行横向和纵向的比较。我们深信数据是会说话的，总有规律值得我们追溯求实、鉴往知来。同时我们也会不断细化评析的标准、划分，以使得这些数据更有代表性和说服力。
来源：游戏葡萄
叶子猪每日行业播报系叶子猪游戏网出品的资讯栏目，仅作于汇聚互联网游戏行业的每日资讯，如需查看文章出处可点击阅读原文。}