提升市场竞争力,这些细节你都把握了吗?
- 作者:admin
- /
- 时间:2018年10月24日
- /
- 浏览:3796 次
- /
- 分类:厚积薄发
优化工作向来是个复杂系统的工程,且不说前期的框架预设、大量的版本迭代、美术和性能的需求平衡,单从每个版本的上万帧测试数据中定位真正的性能瓶颈,其工作量就已可想而知。
无论项目是否复杂或简单,当我们开展优化工作前,这些问题都需在胸中有丘壑。那么如何井然有序地定位和排查性能问题呢?我们定位到了性能的真正瓶颈了吗?今天小编以一个优化前期的MOBA手游的UWA性能测评报告为例,深入分析该项目在真机上的运行情况,并讲解如何通过报告中的功能模块更高效地定位性能瓶颈,希望能对大家的项目有所参考。
一、关于性能简报
在这次优化讲解的时候,我们将从报告的“性能简报”模块入手(每个项目性能报告的首页),该模块作为UWA性能评测报告中的一大模块,将引擎性能模块的数据更有序、更核心地汇总成一个完整的优化体系,建议大家在优化项目之初先仔细参阅该模块的数据。点击这里可以快速了解UWA性能简报。
在性能简报的第一个模块,可以直观查看到最近测试的项目报告中的重要参数、其优化效果和性能变化趋势。
从性能排名的模块中,我们提供了测评项目在国内数千款测评项目中,同设备和同类型的横向排名,从而帮助大家更客观地发现项目中的优势和不足。
引擎模块的性能排名
内存模块的性能排名
UWA解读:该项目在CPU模块和内存上均有大量的提升空间。CPU模块的压力主要来自于引擎的渲染和UI,物理、粒子和动画,逻辑代码较为严峻。内存模块中各个资源的占用内存普遍都较高,Mono堆内存分配也较大。
在性能简报的最下方,是UWA针对本次性能提测所提供的分析与建议,在这里将所有引起以上参数开销的性能问题逐一列出,并通过精准的页面链接跳转定位到问题源头,协助开发者进行有效地排查。其中,标红部分的问题较为明显,建议研发团队优先处理。
优化任务队列是我们提供给用户的性能优化切入点,下面我们将逐一分析上图中罗列的问题。
二、优化队列详剖析之内存篇
2.1 内存占用
本次报告的内存占用峰值为660.3MB,高于行业同类型同设备,当前行业均值为305MB,因此需要研发团队密切关注。特别的,如果要保证在一些1GB内存的设备比如iPhone 6或6 Plus上不闪退,我们建议尽量不要超过280MB。
内存的主要构成来自资源内存和Mono堆内存,在此我们做下详细分析。
2.1.1 资源内存之纹理 (内存超标)
排查方向:
1) 纹理的分辨率、格式
如性能简报中显示,RGBA32和ARGB32都不是Android原生支持的格式,不但内存占用较大,且加载效率也低下,建议尝试转成ETC1等硬件支持的格式。如果效果不满意也可以尝试通过Dither算法,对某些高精度的纹理进行处理,转成RGBA4444或RGB565格式,以降低内存占用。
补充说明:在图表中我们也看到不少N/A资源:一般是new出来没有命名的纹理资源,建议在这些纹理new出来之后,给.name赋值,以方便进行纹理资源管理。
2)在查看纹理的具体使用情况时,我们同时发现其冗余情况较为严重。下图为按峰值倒序排序的资源列表截图,可以看到数量峰值大于1的纹理有100多个,当两张纹理的名字、尺寸、格式等属性都相同,UWA就会将其视为具有高风险冗余的资源。
关于冗余的排查优化方法:
a) 检查AssetBundle(即打包的时候就有冗余)中是否有冗余,该问题可通过AseetBundle资源检测服务来定位;
b) 检查AssetBundle重复加载情况,是否有AseetBundle反复加载导致的缓存漏洞。
2.1.2 资源内存之网格 (内存超标)
排查方向:
1)表格中顶点数大于5000的属于超大网格,需要进一步排查是否有必要。
按Vertex数量进行排序,可以看到第一页的网格顶点数都在1w左右,这个会造成一定程度的内存压力。
2)上图中也可发现,大量网格含有Tangent属性,Tangent属性一般为导入引擎时生成,会增大网格的内存占用,如果实际上不需要Tangent属性,可在Inspector面板中修改设置,关闭Tangent导入选项。
列表中显示Tangent数量为-1的网格,表示Read/Write选项被关闭了,所以统计不到。在此,UWA建议研发团队提交一个临时的打开该选项的版本,来检查网格的属性是否合理。
3)存在冗余的问题,解决方法同纹理
另外,我们在排查资源清单的时候发现了大量的内置资源,在这里提醒大家关于内置资源的处理方法可参考这篇文档:零冗余解决方案(其他类型的资源可借鉴)
2.1.3 动画资源(内存超标)
根据性能简报的提示页面转到动画文件的使用信息列表,如下图所示:
对于大于200KB且时长较短的动画资源,UWA认为可以进一步排查。这里看到资源列表按照内存占用排序,前3页内存占用大小都超过了200KB,建议使用一些精度处理的方法来进行优化:通过降低浮点数精度的方法来减小动画文件的大小。需要注意的是,这种方案会导致动画精度一定程度上的损失,需要大家衡量下结果。
2.1.4 粒子系统内存 (数量和内存超标)
排查方向:
1)Active的粒子系统数量过多,UWA建议在中低端设备上不超过50个,可以考虑通过一些设备分级的策略做改善(剔除某些在部分机型上表现力较差的粒子系统)
2)缓存的数量过大(UWA建议不超过600个),如下图中实际粒子的使用走势图所示,蓝线表示内存中的粒子系统数量,紫线表示实际上Active的量,从而得知大量粒子系统始终没有Active过(表格中显示Active数量峰值为0),但在运行时都被加载了。
在下图中,对于始终未被Active的粒子系统,我们建议研发团队针对配表优化。
2.1.5 材质(数量超标)
对于Material资源的把控主要在于数量而非内存,UWA建议材质数量控制在300以内。
排查方向:冗余
对于Instance类型的冗余Material资源,两种优化方法:
1、尝试通过《使用MaterialPropertyBlock来替换Material属性操作》方法对其进行优化;
2、当我们修改了一些特定GameObject的资源属性时,引擎会为该GameObject自动实例化一份资源供其使用,比如Material、Mesh等。以Material为例,我们在研发时经常会有这样的做法:在角色被攻击时,改变其Material中的属性来得到特定的受击效果。这种做法则会导致引擎为特定的GameObject重新实例化一个Material,后缀会加上(Instance)字样。其本身没有特别大的问题,但是当有改变Material属性需求的GameObject越来越多时,其内存中的冗余数量则会大量增长。一般情况下,资源属性的改变情况都是固定的,并非随机出现。比如,假设GameObject受到攻击时,其Material属性改变随攻击类型的不同而有三种不同的参数设置。那么,对于这种需求,我们建议直接制作三种不同的Material,在Runtime情况下通过代码直接替换对应GameObject的Material,而非改变其Material的属性。这样,成百上千的Instance Material在内存中消失了,取而代之的则是这三个不同的Material资源。
对于非Instance类型的冗余Material,建议研发团队通过资源检测服务来查看AssetBundle中是否存在冗余资源。
以上是主流资源的使用情况和分析建议,下面我们再关注下报告中检测到的其他资源的使用情况:
2.1.6 字体(内存超标)
主要问题:冗余
2.1.7 Shader
排查问题和关注方向:
1)Shader冗余
2)部分常用的Shader是否可以做成常驻的,考虑做法是Shader加载后放在脚本中,引用之后不卸载;
3)Shader的内存占用往往不会造成明显的问题,但是数量如果过大,容易导致Shader.Parse在中低端上的高耗时;
4)资源列表中查到有不少Standard Shader,如下图所示,由于其会带来不必要的Shader计算开销,从而大幅增加GPU中对应像素的计算压力。对此,建议研发团队尝试对其用普通的Shader来替换。
2.2 Mono 堆内存
2.2.1 单次分配过大
报告显示部分函数的Mono堆内存单次分配较大,建议大家通过详细的堆内存报告中定位堆内存分配过大的时刻。这里推荐用UWA GOT针对部分函数进行打点拆分。
2.2.2 堆内存泄露
经分析,报告也存在堆内存泄露的风险,我们通过对比相同游戏场景(均为副本)的不同采样点,发现某些函数存在堆内存驻留的问题,如下图运行到16000帧和4000帧时,游戏场景均为战斗副本中,但是函数Asset.WaitReadFileBywww有1.99MB的堆内存驻留,经过与研发团队讨论,初步判断这里疑似泄露。
其他函数也存在堆内存泄露的情况,建议研发团队逐一排查。
三、优化队列详剖析之引擎篇
3.1 渲染模块
渲染模块的开销较大,我们建议直接从堆栈信息中定位。通过性能简报提示,我们查看Camera.Render的堆栈信息如下所示,其中蓝色底纹的是需要大家关注的重点部分,即主要的渲染开销瓶颈。
RenderForwardAlpha.Render是指半透明渲染的耗时,在这层函数中,我们看到有两个高耗时的函数:
1)Mesh.DrawVBO和CreateVBO
这个函数在半透明下,就表示绘制半透明网格的耗时,半透明网格一般就是UI、场景里的半透明物件,还有半透明的Mesh特效。如果只是一帧其实问题不大,但如果是频繁开销,则需要研发团队特别注意。
经和研发团队的交流讨论,我们了解到的确存在Mesh特效过大的情况,因此我们建议是否可以设定一些设备分级的策略。
2)Material.SetPassFast
Material.SetPassFast是Unity引擎在渲染过程中Material的轮循切换开销,一般在Unity 5.0~Unity 5.3版本中出现(项目版本是Unity 5.3.5)。根据下图中的堆栈走势可发现这种情况是几乎每一帧都发生的,有渲染的地方就会有Material的切换。
从问题图中可以看出,在运行的21000帧中,Material.SetPassFast一共被调用118万次,频率较高。建议研发团队在报告中的具体信息页面查看材质是否有过多“冗余”的材质出现(本文2.1.5中有提及),尽可能降低材质的使用冗余度。
3.2 UI模块
从图表中可以发现UIPanel.LateUpdate()的重建较高,这块需要大家关注下UI制作是否合理,由于这块内容和研发团队的制作方法紧密相关,需要具体问题具体分析。所以详细的交流探讨细节我们不在此展开,建议同样有着这方面困惑的开发者可以参阅UWA Blog上关于UI的视频:Unity UI性能优化,这里我们提到了面对多种UI性能优化的技巧。
3.3 物理模块
从UI模块可知,研发团队使用的是NGUI,在每个Panel上都放置了一个Rigidbody,所以当UI Widgets摆在同一深度并存在相互叠加的情况时,会造成较多不必要的Contacts。建议研发团队看下是否能把UI层之间的碰撞检测关掉。
另外,在Unity 5.3.5版本上,如果想进一步降低物理模块的开销,在完全没有使用物理的情况下,可以将Fixed Timestep设置为0.05或0.1均可,降低它被调用的频率。同时,尽可能优化其他模块耗时,让每帧的总体耗时尽可能降低。另外,需要注意的是,修改Fixed Timestep也会影响FixedUpdate的调用,在修改之前一定要检测项目中是否有使用FixedUpdate。
3.4 粒子模块
粒子系统的耗时多与Active的粒子数量有关,这块建议结合粒子模块的内存问题(文中2.1.4有提及)一并优化。
四、GPU优化
最后还需要关注的是GPU问题,UWA在测试的时候发现该游戏在某些高端设备上耗电发热明显。
在GPU性能的Overdraw页面,我们可以看到GPU信息如下图所示:
下图为该帧下的截图,可以看出,特效和UI的屏幕占比过大,且存在UI叠层的概率较高。因此,研发团队需要特别关注技能特效和UI界面的制作情况,避免给GPU造成大量的计算浪费。
五、优化任务队列总结
1)AssetBundle的依赖打包方式
解决资源内存占用过大的问题
2)Mono堆内存分配
解决Mono堆内存大小和GC卡顿的情况
3)Mesh特效
解决渲染模块的耗时问题和GPU压力过大问题
以上就是该游戏的诊断内容,我们从UWA的性能简报出发,围绕CPU、内存、GPU三大模块的性能问题展开,通过数据报告的查看对比,整理出了一条较为完整的优化思路,希望能对大家的自身项目有所启发。目前,UWA的线上测评服务已经为数千款项目提供了解决方案,我们希望能帮到更多游戏开发者节约优化的成本,提升项目的性能表现力,迎接“精品”时代的挑战!