CPU性能

该游戏在CPU占用方面的性能非常不错，下图为该游戏在三星S3和三星S6上的CPU占用情况。可以看出，在三星S3上运行的11248帧中，超过33ms的帧数占比为18.1%，超过50ms的帧数占比为7.3%；在三星S6上运行的16409帧中，超过33ms的帧数占比为3.2%，，超过50ms的帧数占比为1.7%。

三星S3：

三星S6：

其整体CPU性能的优秀表现与其各个模块的合理使用是分不开的。下面，我们就详细讲解一下其CPU性能方面的亮点之处。

渲染模块

该游戏在三星S3设备上运行时的渲染模块CPU开销如下图所示。通过统计，半透明物体渲染的CPU消耗均值为 2.3ms，主要集中在 1.1~6.0ms 范围内（5%~95%）。不透明物体渲染的CPU消耗均值为 2.1ms，主要集中在 0.4~5.3ms 范围内（5%~95%）。Draw Call峰值为 223，且主要集中在 66~176 范围内（5%~95%），该值处于合理范围之内。

该游戏为移动端的MMORPG游戏，在三星S3低端设备上可以做到如此低的渲染开销，足见研发团队对场景管理、材质选择的把控能力。当然，美中不足的是，游戏主场景的三角面片数量较大，峰值为118300，如果可以将其控制在10万以内就更好了。同时，半透明渲染耗时一直稳定在3~10ms区间内，但不透明渲染与Draw Call和Triangle的变化趋势较为一致。可以推断出，战斗副本中用于不透明渲染的面片大致为4万面片，而主城中则为9-10万面片左右。

相信不少团队也遇到了场景网格面片数较高的情况。对此，我们建议可以尝试一些网格资源简化的工具，比如Asset Store上的SimpleLOD插件。

物理模块

该游戏在三星S3设备上运行时的物理模块CPU开销如下图所示。通过统计，物理模块总体的CPU占用均值为0.3 ms，主要集中在0.1~0.7ms范围内（5%~95%），该值处于合理范围之内（一般建议在3ms以下）。

物理模块的低效能开销主要得益于Contacts、Rigidbody数量的控制得当。在《六龙争霸》游戏中，Rigidbody控制在20以下，处于合理范围之内（<50）。Contacts数量一直为0，即说明游戏中并未用到任何物理碰撞，同时也说明研发团队对Physics Matrix进行了相当合理的设置，避免不必要的碰撞检测发生。

重要提示：不少项目中，Contacts数量较高的原因是由于NGUI的不当使用造成的，即UI widgets摆在同一深度并存在相互叠加的情况，从而形成了较多不必要的Contacts，进而造成了不必要的物理碰撞开销。建议大家通过UWA对物理模块中Contacts的数量进行详细地检测。

动画模块

该游戏在三星S3设备上运行时的动画模块CPU开销如下图所示。通过统计，物理模块总体的CPU占用均值为 0.9ms，主要集中在 0.3~1.7ms 范围内（5%~95%），该值处于合理范围之内（一般建议在 3ms 以下）。

通过分析可知，图中Animation.Update CPU开销较大处均为多人战斗处，从而可以推断出游戏中角色动画系统使用的老版本动画系统，而非Mecanim动画系统。在此，UWA建议大家在开发进度允许的情况下，尽可能使用Mecanim动画系统。相较于老版本，Mecanim的“Optimize GameObject”和多线程处理，均可以进一步提升动画系统的性能。

内存模块

《六龙争霸》在内存上的表现同样突出，如下图所示。总内存峰值为221MB，Mono堆内存峰值为25.5MB，且内存的升降较为一致。

Mono堆内存

从上图可知，该游戏的总体Mono堆内存控制得很好，在11248帧中，Mono的堆内存峰值仅为 25.5MB。该值属于合理范围之内（<40MB）。

资源内存

经过统计，该游戏的纹理资源数量峰值为357个，内存占用峰值58.8MB。在全部纹理资源中，ETC1格式纹理占有146个，RGB24格式纹理有10个，ARGB32和RGBA32格式资源数共有23个，其余为RGBA16格式。

项目中ARGB32和RGBA32格式的纹理均为UI Atlas纹理，项目团队为了达到更好的显示效果，并没有使用ETC1格式。在内存够用的情况，这其实无可厚非。同时，对于RGBA16和RGB24格式的纹理，我们建议在视觉效果可以保证的情况下，尽可能使用ETC1格式纹理进行替换，从而达到更小的内存占用。

其他资源的内存占用

Mesh资源：

Mesh资源稍大，UWA建议尽可能控制在20MB以内。建议尝试通过一些网格资源简化的工具来对场景网格进行进一步简化。

AnimationClip资源：

AudioClip资源：

以上则为《六龙争霸》游戏在CPU性能和内存管理方面的具体使用情况。虽然总体内存占用稍高，但优秀的CPU性能、较低的堆内存分配和合理的资源使用，足以说明该研发团队具备非常深厚的技术功底和对于引擎相当优秀的把控能力。

同时，该游戏在资源加载和实例化方面仍有一定的提升空间。在此，我们对其进行罗列，希望同样可以帮助到大家的研发项目。

性能优化、进无止境

Instantiate实例化

目前，游戏的战斗副本中Instantiate实例化的频率较高，如下图所示。较高频次的Instantiate/Destroy操作会造成一定的内存碎片，从而造成GC的加速到来。

对于频繁的Instantiate调用，我们一般建议如下：

对于一般的GameObject（比如技能特效、怪物角色等），可将其放入缓存池并通过Active/Deactive来进行切换；
对于使用频率较高的UI界面，则可通过直接改变Transform的方式来移进移出相机视域体，可以得到更加高效的性能。

GC调用

在测试过程中，GC的调用频率较高。游戏在三星S3上运行11000+帧时，共检测到GC调用55次，平均204帧/次。

GC的调用频率主要由代码的堆内存分配情况相关。下图为游戏运行过程中，GC的具体触发情况。经过统计，在 55 次GC调用中，由TaskQueueBehaviour.TaskCoroutine引起的为 26次，EntryPoint.Update引发了 19 次，UIRect.Start引起的为 6 次。

重要提示：建议大家一定要多关注代码的累积堆内存分配情况，因为它基本上决定了GC的调用频率。如果你的代码中存在分配10MB以上堆内存的函数，切记一定要详细检测，检测其堆内存分配是否合理。

动画资源冗余

在测试过程中，我们发现该项目的动画资源在使用上存在一定的冗余现象，如下图所示。图中红框内的数量峰值即表示该资源在测试过程中存在不同程度的冗余情况。点击资源，图表中即可显示该资源在项目测试阶段的具体使用情况，从而大家可以直接通过该曲线来定位资源出现冗余时的具体位置。

重要提示：一般情况下，这种情况是由AssetBundle没有进行完全依赖性打包所致。当你的项目出现资源冗余情况时，建议对AssetBundle的打包机制进行进一步的梳理，定位问题并完善相关的资源打包步骤。

粒子系统

在测试过程中，粒子系统的更新在中低端设备上占有较高的CPU开销。下图为三星S3设备上的粒子系统CPU占用情况。可以看出，在副本中的粒子系统占用较低，但在主场景中的的粒子系统开销较高。

对于这种情况，我们的建议如下：

尝试关闭离当前视域体或当前相机较远的粒子系统，离近后再进行开启，从而避免不必要的粒子系统Update开销；
根据机型的不同档次设定粒子系统不同的复杂程度，以降低粒子系统在中低端手机上的开销。

以上则为该项目在后续研发中可进一步提升性能的主要方面。在我们测评过的项目中，实例化频率过大，GC调用频率过高、资源冗余等问题也是绝大多数研发团队遇到的共性问题。希望以上的讲解对大家的相关问题有所帮助。

最后，非常感谢《六龙争霸3D》研发团队对 UWA 的认可和支持。感谢他们乐于将项目性能数据与大家一起分享，让更多的研发团队了解到一款性能优秀的移动MMORPG游戏在各个模块上应该做到怎样的程度。

欢迎更多的研发团队来使用UWA性能诊断工具，国民手游都用上了，你还在等什么？