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的可能性。

 

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