Crash率10%降至1%,腾讯专家是这样打磨精品游戏的

来自 腾讯GWB游戏无界 2019-05-09
资讯

[ 转载自 腾讯GWB游戏无界 ]

Crash率10%降至1%,腾讯专家是这样打磨精品游戏的

随着开发工具的不断迭代和开发人员能力的不断提升,制作一款游戏也不再是一个难事。每一个开发团队无论规模大小,都在努力让自己的产品尽善尽美。但有时候可能由于经验不足、时间紧迫等原因,还是会遇到一些自身无法解决的困难。这时候他们其实很需要得到一些行业专家的指导和帮助,而腾讯游戏学院恰好就提供了这样的资源。

腾讯代理的一款暗黑类ARPG手游《拉结尔》即将上线,这款游戏由腾讯游戏学院专家进行了历时4个多月的打磨指导,从线上沟通到现场分析,重点解决了一些客户端的问题。下面就为大家总结一下项目组遇到的问题以及专家董根的解决方案,相信会给有类似困惑的开发者们一些帮助。

提升游戏流畅度,降低场景内存占用

拉结尔的开发团队和专家之间先是通过邮件进行了初步的沟通,针对开发团队提出的性能问题,给出了一些针对性的建议。研发团队提出了以下几个问题:

1. 项目中使用的PSS比标准的(UWA),超过1G;游戏启动400+MB,进入到游戏景1+G了;在Xcode看到在登录完成后内存高达660+MB,其中数据表(MONO)的200+MB,其他未知模块消耗400+MB,请问这部分的内存能降低么?怎么降低?

专家解答:MONO内存包含的不只是数据表,如果是整体MONO内存比较高,建议可以通过Unity官方开源的Memory Profiler进一步分析,如果确认是数据表的部分,可以看看是否表格设计的列过多,能不能精简一下,或者在加载的时候用更精简的结构转存一下,能手动定义的字段不要通过Key-Value访问。表格中的字符串统一读到字符串表中,原先记录中的字符串用id来代替,这样可以减少重复字符串。这些是常用的手段,但建议项目组结合实际的分析结论确定优化办法。

2. Unity3d 5.6.4自带的Cloth组件,无规律的出现闪退,Cloth布料的制作和使用是否是有一些规则,能让cloth运行更稳定? 另外Cloth组件中的SleepThreahold是间隔时间停顿么?怎么使用?能对Cloth组件的性能消耗能降低么?

当前项目使用Cloth组件,发现在导入fbx的时候勾选了Optimize Mesh选项,Cloth组件同级挂载的SkinnedMeshRenderer的Bounds很大概率(70&~80%)出现NaN;不勾选Optimize Mesh后,NaN错误没有再出现了;请问这个NaN是否会对布料的计算产生性能消耗?

专家解答:SleepThreahold是指布料顶点的移动速度在多小的时候就进入asleep状态不再更新。Bound变成NaN这个有可能是一个Unity的Bug,这个主要会影响Unity做视椎裁剪,带来视觉错误或者额外的性能开销,同时对其他依赖Bound的逻辑也会有影响。

按现在的移动设备跑布料系统压力非常大,效果上要有保证的话性能开销非常高,压低参数又比较容易出现模拟穿帮,另外Unity的布料也是集成的NvCloth,这个布料库在移动端的稳定性确实不好,所以手机上还是建议不要使用布料。通常情况下用Dynamic Bone等插件也能做到不错的效果。

3. (Android平台下)音频加载和播放都会出现较为严重的卡顿(CPU耗时300毫秒以上),怎么平衡效果和效率?(目前没有进行太多音频的平台设置,直接拿起就播放的)

专家解答:如果是长时间的背景音乐,建议在资源上打开Streaming,短时间(1、2秒以内)的音效如果都很卡的话,主要就要靠压低采样率了,或者尝试采用不压缩的格式

4. 当前项目使用了T4M的地表插件,美术使用了4层,导致渲染耗时比较严重(4ms);就当前项目而言如何兼顾美术的需求又降低消耗?

专家解答:地表的多层混合建议在渲染本身上做优化,一方面是减少贴图,在可接受的范围内尽量减少贴图的尺寸,如果可以的话去掉一些层的法线贴图。另一方面可以重写一下地形的Shader,用最简单的光照模型,减少不必要的贴图采样。地形的顶点数也留意一下,不要太夸张就好。如果能对多层的权重做一些限制(例如单个位置同时仅允许2层权重有效),则有更多的办法。

5. 烟雾的特效(已经用了序列帧),但是overdraw还是很高;如何降低overdraw?

专家解答:这样的问题还是要从美术方面入手,尽量降低半透明面片的大小和数量,避免使用充满全屏或接近全屏的烟雾,可以提供一下具体overdraw比较高的画面看看

6. 目前场景物件比较多,全部都是Static。然后烘焙后Lightmap可能会造成batch断掉,造成drawcall很高。对于这种场景物件很多的情况,有没有什么好的做法或建议?

专家解答:最直接的办法就是在可接受的范围内尽量降低LightMap精度,使烘培出来的LightMap尽量少,越少就越不容易打断batch,最优的状态是只有一张,那么就不存在打断batch的问题了。

还可以对场景进行切块,把每个块单独放在一个临时场景中,内容保证在一张Lightmap的容量内,然后单独烘培这个场景,最后把烘培结果取出,运行时手动给设置上。这样可以保证单块之内不会因为LightMap而打断batch。

解决资源丢失,显示异常问题

为适应手游快速更新的节奏以及方便控制战斗场景内存,由Resources方式调整成AB包的方式,针对调整过程中的一些坑点,专家也耐心提供解答。

研发团队提出了以下几个问题:

1、 目前存在很多shader丢失问题该如何解决?

专家解答:是否将Shader打了依赖包?或者代码中有动态切换Shader宏的操作?如果有,建议在Shader的包中带上一组空材质,将可能的变体组合都在材质上设置一下,因为Shader打包因为没有材质引用,所以无法识别所有的变体。研发解决后也反馈了解决方式:shader的丢失是U3D的着色器剥离,已设置成手动的,一些使用shader.find的方式都替换成读取AB中的方式了。

2、 关于资源下载的大小,因为资源是零散的,然后相互之间有依赖关系;可能会分配到不同的chunk中,导致,每下一个都要多带上之前的资源;目前我采用的是,把chunk块分的大小从32扩大到128块,如果设置到128块,会不会性能相关问题,读取上会不会卡顿,依赖关系是否会增加?

专家解答:再多分细一些完全没有问题,以后热更新粒度也会更细。

3、 在ui上的角色怪物显示在安卓平台上出现了问题,表现为rt的透明度全部为1,导致角色相机在没有渲染的地方也显示了camera的clear color。问题出于一个bloom的后处理,整个脚本取消了就没问题,但我们把OnRenderImage换成只有一行blit(src,dest)以后问题还是存在。

专家解答:目标RT和源RT相同的时候,Untiy会创建一张临时RT作为目标RT,最后再将它拷贝回来,拷贝的过程通过截帧看到在部分平台下写入A通道被关闭,虽然暂时不清楚Unity内部的机制,但是通过CommandBuffer重新实现的话,可以手动控制后期流程中的每个环节,规避掉这个问题。

Crash率优化—从10%降至1%

从19年三月份开始,腾讯专家也利用周末时间直接出差到开发团队所在地,现场协助分析和解决问题。

初次线下沟通的过程中,在没有log只有底层堆栈的情况下,腾讯专家针对崩溃情况给出一定的分析。在内存分配失败的时候,要先确认一下当时的内存占用情况,有几种可能:一是确实内存不足,二是内存碎片太多导致找不到连续空间,三是资源上有问题导致传了一个未初始化的值作为size去分配内存。如果是最后一种情况可以把资源加载的记录打印一下,看看是否和特定资源的加载有关联,如果是前两种情况就比较麻烦了,只有持续优化内存了。

第二次线下沟通专家通过现场分析崩溃规律和日志,建议增加更多定位日志,查阅代码,发现unsfae指针,存在越界风险,可能带来闪退问题,并且排除闪退是由于接入sdk的可能性。

最后专家也针对特殊字体/字符,提出调用系统字体的方法,以减少闪退的问题。与此同时,专家还和研发主程交流了开发流程和规范等问题,分享了一些个人的经验,有效提升了开发效率。至此《拉结尔》项目一系列的问题都得到有效解决。

文章评论
游戏葡萄订阅号