查看原文
其他

腾讯大咖分享丨腾讯是如何做Unity手游性能优化的

2016-06-30 chunhe Gad-腾讯游戏开发者平台
俗话说,用户体验不谈性能就是耍流氓。 在PC游戏上的性能问题并没有那么明显,加个内存换个CPU或者刷个主频就能轻松搞定;到了手游时代后情况则显得比较严峻,捉襟见肘的内存使得资源加载时如履薄冰,加上高中低不同配置的机型让性能问题显得更加突出,一个低端机型上的卡顿就可能造成一大批屌丝用户的流失,这当然无法被忽视。
在手游的浪潮之巅,腾讯对于手游品质的要求从1.0到2.0再到现在的3.0,不仅是玩法和内容,在游戏质量的审核上也始终如一的保持着高要求高标准。
腾讯游戏的品质管理中心在Unity手游性能上进行了更深层次的挖掘,这是一个腾讯内部非常受欢迎的性能分析产品,无论你是否正在从事Unity相关的工作,听完这个良心产品的故事保证会让你增加90%的魅力值。但在此之前、先要看看你的“性”能到底行不行?
(下文有大量专业术语,有可能引起您的不适,请在家长指导下阅读。)
一.常见的Unity手游性能问题有哪些?
Unity手游的性能问题一直是被业内视为诟病,腾讯公司内部的TDR评审就是一个专门针对技术细节进行专家团评估的环节;早期的TDR评审关注的是内存是否超标、CPU是否饱和、网络流量是否过大等数据,经过近几年手游浪潮的洗礼,现在评审过程中会更加注重细分问题的研究和排查。 

如果说左边是玩家经常会遭遇到的表面现象,那右边则是基于Unity引擎深挖后的问题本质。 它们对游戏的具体影响是什么呢?就拿最近比较火的《王者荣耀》来举例,我们有幸参与了它上线前后的几个优化版本的分析,先后遇到过的问题和优化方法主要有下面几个: 
1.由于实时对战游戏的数据包数量巨大,早期版本的帧同步策略会导致比较明显的卡顿,通过进行数据包的合并与优化逐渐解决了卡顿问题;
2.频繁创建和销毁的小兵对象让CPU爆表了,大量的小兵如果采用实时内存的分配和回收,会产生大量的内存碎片和系统开销,解决方法之一就是采用高效的对象池进行优化,对每个内存对象的状态进行操作即可;
3.性能分析过程中,发现单人同屏和多人同屏时的开销都很大,通过视野裁剪技术,使得玩家视野外的不必要的特效和渲染可以全部关闭,极大降低了CPU、GPU和内存的开销;
4.在高中低三档机型上玩游戏时,分别加载不同层次的特效包,这也有助于降低CPU和内存的开销;
5.性能分析过程中发现副本内wwise音频组件占了30%的CPU时间,果断抛弃之,采用Unity自带音频功能,优化很明显;
6.游戏内界面采用了UGUI的方式实现,但大量的实时UI变化使得副本内每帧会有230以上的drawcall,导致中低端机型感受到明显卡顿,最终采用UGUI+自研究UI的组合拳,重写了一套紧密结合游戏自身特性的UI来实现战斗血条和浮动文字的效果。 
二.手游发布之前的性能分析
近年来,经过若干惨痛的教训之后,业内已经逐渐意识到手游性能已成为了生死存亡的关键,特别是对于做大DAU的手游来说尤为重要。
腾讯对于手游性能的测试和监控也是多管齐下,在新版本发布之前会再三确认性能是否符合发布标准,拿王者荣耀这款实时竞技游戏来说,在测试阶段会采集大量的性能数据进行分析,测试经理对各项性能指标进行评估并给出最终质量结论。 
如上图所示,首先,功能测试也就是通常所说的人肉测试,用于测试游戏的新、老功能点,测试工程师在工作过程中可以使用Cube进行数据采集;自动化测试则是基于腾讯WeTestgautomator自动化框架来实现,功能类似于Robotium,在无须人力参与的情况下能覆盖到绝大部分技能、角色和关卡;灰度发布指的是在一个很小范围定点推送手游的新版本,并观察运营期的质量情况和玩家反馈。
无论是哪种测试方法,在过程中都可以用Cube进行数据采集,在测试完成后,服务器会自动进行数据分析并给出多项性能数据结论;这些性能数据的结论来自于Unity官方的推荐标准值和腾讯游戏海量的经验库,如果同意机器给出的结论则可以巩固当前算法,当然也可以挑战自动分析的结论,帮助后台改进算法,最终版本质量结论还是来自于测试经理的判断。
看到这里是不是有一个疑问:不做性能分析行不行?当然行,并且你的产品照样能发布、能上线,带来的结果就是用户抱怨用户投诉用户流失。生病了、还得老老实实的去看病去吃药;冰冻三尺非一日之寒,一场大病的费用远比日常保养要贵的多,对应测试行业的名言就是“bug发现的越早、修复成本越小”。
 
三.Cube工具的简介
目前市面上大多数性能工具都还停留在操作系统级别的数据上, 在游戏自身的分析上似乎还缺少点什么,所以腾讯的工程师们觉得还可以往灵魂深处挖一挖,于是就研发了Cube这个手游性能分析工具,可以让用户以最小的成本在真机上进行游戏性能深度分析。
常见的游戏质量改进的过程如下图,Cube能帮你完成的是前两个环节,至于第三步、解决问题当然还是要开发人员去改代码了。 
通过Cube的深度分析,能够帮助开发者发现当前游戏内分类资源的占用情况。 
如上图所示,在资源分析纬度上可以给出如下结论:
1、资源使用总量是否在合理范围之内。
2、一个场景内的资源重复率。
3、资源对象拷贝的数量是否合理。
4、场景切换时保留的资源详情。
5、网格、纹理、音频、动画、GameObject等资源是否超标。 在性能分析纬度上,以腾讯的TDR标准为例,在高中低三档机型上会有不同的标准,Cube在三档机型中做了自动的筛选和判定,便于开发人员能更加直观的发现问题。(如下图)

首先、在游戏场景内对于FPS、CPU、PSS的变化趋势是需要重点关注的;其次、对于mono这种只增不减的东西,当然也是关注的重点,mono堆内存的不断分配会直接导致PSS内存增长且不可逆;再次、对于和渲染有关的drawcall,也是手游需要关注的性能指标之一,drawcall太高会导致FPS陡降,造成视觉上的卡顿。 
四.同类工具对比
MAT (Memory Analyzer Tool)的缺点:需要导入HPROF文件再分析;只能查看java层的内存情况,看不到native堆的详情; xcodeinstrument 的缺点:只能用于mac,ios;只能查看C++ 或 object C 的情况,看不到mono堆的详情; Unity Profiler 的缺点:需要单独编译develop版本;在PC上执行,没法捕获真机数据;内存数据跟实际真机的数据差异很大、多的时候有几十M差距;只能看到最近一段时间的数据,看不到总体的详情;  对于Unity大神和开发人员,你更关心的应该是详细的性能数据,都能满足你们。大神会说“我更喜欢看着Unity profiler直接调试啊”,那你还得腾出时间编译一个develop版本、还得重新跑一遍游戏、数据和真机还相差很多,关键是大神哪来那么多时间呢? 
所以答案是肯定的,日常测试工作中加入了数据采集和数据分析功能,就可以提高很大的工作效率。
我们常见的产品质量改进流程无非是下面这四步:
1)测试人员发现问题;
2)提bug 给开发人员;
3)开发人员编译develop版本;
4)开发人员用Unity profiler 定位原因;
用Cube进行游戏测试能帮你省掉后面2个步骤,何乐而不为呢?
通常情况下,开发人员是间隔几个星期甚至几个月才会去做一次性能调优的工作,中间已经隔了N个版本,有很多问题会被埋的很深;基于“问题发现的越早修复成本越小”的硬道理,功能测试人员完全可以用Cube进行日常的版本功能测试,让Cube在后台默默的为你发现各种性能问题。
1、即插即用、无须编译无须嵌入SDK、真机运行数据;

2、提供mono内存分配信息和mono快照对比;
3、能看到整个测试流程中的所有数据,而不仅仅是某一段时间;
4、被误操作产生的对象拷贝数量;
5、函数开销排名;
6、关卡间保留的冗余资源; 
五.性能优化的N种武器
作为一个以性能优化为己任的工具类产品,Cube不仅致力于问题的发现和定位,也希望为开发人员提供更多更实用的性能优化方法。
贴图:1、控制贴图大小,尽量不要超过 1024 x1024;
2、尽量使用2的n次幂大小的贴图,否则GfxDriver里会有2份贴图;
3、尽量使用压缩格式减小贴图大小;
4、若干种贴图合并技术;
5、去除多余的alpha通道;
6、不同设备使用不同的纹理贴图,分层显示; 模型:1、尽量控制模型的面数,小于1500会比较合适;
2、不同设备使用不同的模型面数;
3、尽量保持在30根骨骼内;
4、一个网格不要超过3个material;
动画:N种动画压缩方法;尽量减少骨骼数量;
声音:采用压缩MP3 和 wav;
资源方面的优化:1、使用 Resource.Load 方法在需要的时候再读取资源;
2、各种资源在使用完成后,尽快用Resource.UnloadAsset和UnloadUnusedAsset卸载掉;
3、灵活运用AssetBundle的Load和Unload方法动态加载资源,避免主要场景内的初始化内存占用过高;(实现起来真的很难…)
4、采用www加载了AssetBundle后,要用www.Dispose 及时释放;
5、在关卡内谨慎使用DontDestroyOnLoad,被标注的资源会常驻内存;
代码的优化:1、尽量避免代码中的任何字符串连接,因为这会给GC带来太多垃圾;
2、用简单的“for”循环代替“foreach”循环;
3、为所有游戏内的动态物体使用内存对象池,可以减少系统开销和内存碎片,复用对象实例,构建自己的内存管理模式,减少Instantiate和Destory;
4、尽量不使用LINQ命令,因为它们一般会分配中间缓器,而这很容易生成垃圾内存;
5、将引用本地缓存到元件中会减少每次在一个游戏对象中使用 “GetComponent” 获取一个元件引用的需求;
6、减少角色控制器移动命令的调用。移动角色控制器会同步发生,每次调用都会耗损较大的性能;
7、最小化碰撞检测请求(例如ray casts和sphere checks),尽量从每次检查中获得更多信息;
8、AI逻辑通常会生成大量物理查询,建议让AI更新循环设置低于图像更新循环,以减少CPU负荷;
9、要尽量减少Unity回调函数,哪怕是空函数也不要留着;(例如空的Update、FixedUpdate函数)
10、尽量少使用FindObjectsOfType函数,这个函数非常慢,尽量少用且一定不要在Update里调用;
11、千万一定要控制mono堆内存的大小;  
六.小结
性能优化就像海绵中的水,又或是内衣里的肉,挤一挤总会有的。
同时,性能优化并不是一劳永逸的工作,而是一个漫长而具有挑战的任务;项目的各个阶段都会有性能上的问题,在用户体验的基础上持续进行打磨,持续保持产品的良好性能才能赢得好口碑。(和保持身体健康是一个道理)

Unity手游的性能优化过程更像是一门时空转换的艺术, 持续在CPU和内存之间取得一个平衡。

空间不足时则需要释放一些无用数据,以获得更优的空间使用率;时间太长时就需要降低不必要的函数开销。例如在低端机上,为了节约有限的内存空间,静态加载的资源会相对较少,很大一部分资源通过动态加载和释放;而在高端机上则不用考虑空间的限制,可以一次性静态加载更多的资源,省去了不少loading和GC的工作,让游戏体验更加流畅。


(本文转载自:腾讯WeTest)

相关阅读:Unity性能优化专题---腾讯牛人分享经验Unity3D游戏丨《腾讯桌球》客户端开发经验总结
腾讯游戏开发者平台长按,识别二维码,加关注
经验分享丨项目实践项目孵化丨渠道发行做有梦想的游戏人-GAME AND DREAM-

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存