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

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

关于腾讯游戏学院专家团
如果你的游戏也富有想法充满创意，如果你的团队现在也遇到了一些开发瓶颈，那么欢迎你来联系我们。腾讯游戏学院聚集了腾讯及行业内策划、美术、程序等领域的游戏专家，我们将为全世界的创意游戏团队提供专业的技术指导和游戏调优建议，解决团队在开发过程中遇到的一系列问题。

项目指导合作请联系微信：18698874612