一、CPU性能
该游戏在CPU占用方面的性能非常不错，下图为该游戏在红米Note2 设备上按照剧情进行游戏时的性能数据。可以看出，在红米Note2 上运行的24979帧中，超过33ms的帧数占比为4.3%，超过50ms的帧数占比为1.2%。考虑到切换场景时资源加载的开销，一款游戏如果超过33ms的帧数占比低于10%，则说明该游戏在绝大多数时刻的运行中都是非常流畅的。
通过进一步统计，该游戏的CPU性能超过了84%的红米Note2设备上的测试游戏，其能耗更是低于91%的同设备测试游戏。
其整体CPU性能的优秀表现与其各个模块的合理使用是分不开的。下面，我们就详细讲解一下其CPU性能方面的亮点之处。
1、渲染模块
通过UWA性能测评报告，我们可以看到该游戏详尽的渲染模块性能开销。该游戏在红米Note2设备上运行时的渲染模块CPU开销如下图所示。通过统计，半透明物体渲染的CPU消耗均值为1.5 ms，主要集中在 0.7~2.7ms 范围内（5%~95%）。不透明物体渲染的CPU消耗均值为1.8 ms，主要集中在 0.2~4.6ms范围内（5%~95%）。
Draw Call峰值为340，虽然峰值较高，但仅在场景切换处出现，这是因为项目在动态加载后通过代码调用StaticBatching的方式来合并Draw Call，所以可以看到Draw Call数量在进入场景后迅速回落。同时，Draw Call数量主要集中在 48~179 范围内（5%~95%），属于合理范围之内。
下图为该游戏在红米Note2上的具体CPU性能堆栈。可以看到，该游戏在红米Note2上无论是不透明开销还是半透明开销均处于较低水平，这得益于研发团队对于场景模型、蒙皮网格和UI的控制十分得当。
美中不足的是Shader.SetPass稍高，这主要是渲染模块中RenderState的切换较为频繁所致，对此，建议大家对场景中的Material数量进行控制，具体可以参考：《使用MaterialPropertyBlock来替换Material属性操作》
2、UI模块
该游戏在红米Note2设备上运行时的UI模块CPU开销如下图所示。该游戏使用UGUI作为UI界面的解决方案。经过统计，UI模块总体的CPU占用均值为1.9ms，主要集中在0.1~3.6ms范围内（5%~95%），属于合理范围之内。
其均值高于70%的行业数据，这是因为该项目使用的是Unity 4.7版本进行开发，该Unity版本中，UGUI并没有像Unity 5.3版本以后将部分拼合操作放到子线程中进行。在这一点上，Unity 4.x的UGUI性能较之5.3+版本确实要多一些性能上的开销。堆内存平均每帧分配为5.5B，仅高于5%的行业项目，这说明该游戏UI界面的制作及UI重建的影响范围非常合理。目前，UWA推荐UGUI模块中，平均每帧堆内存分配尽可能控制在2KB以下。
从下图中可以看出，Canvas.SendWillRenderCanvases在不同的运行时刻均出现CPU高值，但通过运行截图可以看到，其共同特点是CPU耗时高值均发生在画面底层的UI选人界面出现时。因此，该UI界面的出现或相关操作极有可能是引发Canvas.SendWillRenderCanvases CPU过高的原因，建议研发团队对该界面进行进一步检测。
3、动画模块
在UWA测评报告中，该游戏运行时的动画模块CPU开销如下图所示。
可以看出，除进入场景时出现CPU高值外，其在战斗副本中的CPU开销均控制在较低水平。Animator.Update的CPU均值为1.8ms，主要集中在0.1~3.4ms区间内，其性能较为优秀，高于28%的行业项目。同时，MeshSkinning.Update的CPU均值为1.8ms，主要集中在0.1~3.4ms区间内，高于21%的行业数据。
同时，经过进一步检测发现，其进入副本时的CPU高值均为lhAnimatorEvent.OnEventCallback回调函数所致，具体的CPU耗时堆栈如下图所示。通过此堆栈可知，其耗时主要为UI界面的加载耗时，且进一步通过资源管理信息可知其主要开销为luaUI_PK(Clone)的Active操作和luaUI_Hall(Clone)的Deactive操作所致。因此，建议研发团队可进一步检测该UI的制作是否合理，并对其进行完善。
4、GC调用
该研发团队对于GC调用频率控制得非常出众，游戏在运行过程中，GC调用频率为1921帧/次，优于目前95%的行业内游戏。
一般来说，如果一款项目的GC调用频率可以控制在1000帧/次以上，就已经相当出众了。该游戏的GC调用频率如此优秀，主要得益于研发团队对于项目代码堆内存的控制。下图为游戏运行25000帧的代码堆内存具体分配情况。对于使用UGUI的游戏来说，我们建议游戏运行每1万帧中，Top10函数的堆内存分配总和小于30MB，而该游戏运行25000帧，其Top10函数的堆内存分配总和才26.91MB，足见该团队对于堆内存分配的理解非常深刻。
二、内存模块
《战地先锋》在内存上的表现如下图所示。总内存峰值达到249MB，Mono堆内存峰值为32.5MB。243MB的总内存分配相对来说略高，研发团队可尝试在低端机器上对资源进行进一步控制，从而降低低端机器上的内存占用。
1、Mono堆内存
从上图可知，该游戏的总体Mono堆内存控制得很好，在25000帧中，Mono的堆内存峰值仅为 32.5MB。该值属于合理范围之内（<40MB）。
但是，从走势上来看，其堆内存的占用在游戏运行过程中持续处于上升趋势，对此，建议研发团队对缓存池进行进一步检测，排查项目是否存在堆内存泄露的隐患。
2、资源内存
经过统计，该游戏的纹理资源数量峰值为618个，内存占用峰值119.5MB。纹理内存占用较高，目前高于82%的行业项目。经过统计，在内存占用峰值处，ETC1格式纹理占有221个，Alpha8格式纹理占有5个，RGBA32和ARGB32格式纹理共占有120个，RGB24格式纹理占有87个，其余为RGBA16格式纹理。
对于RGBA32、ARGB32的纹理，我们建议在视觉效果可以保证的情况下，尽可能使用ETC1格式纹理（Android平台）进行替换，不仅可以达到更小的内存占用，同时可以获得更快的加载效率。而对于无法进行硬件压缩的纹理，可以通过Dither方法尝试将其转换成RGBA16格式的纹理，具体做法可以参考此篇文章。
其他资源的内存占用情况如下：
Mesh资源：
内存峰值高于41%的项目
AnimationClip资源：
内存峰值高于40%的项目
AudoClip资源：
内存峰值高于73%的项目
AudioClip的内存占用较高，高于73%的行业项目。对此，研发团队可尝试将内存占用较高的音频资源通过Stream的方式来进行加载，该方式可极大降低AudioClip资源的内存占用。
以上则为《战地先锋》游戏在CPU性能和内存管理方面的具体使用情况。优秀的CPU性能、非常少的堆内存分配以及引擎模块间的合理使用，足以看出该研发团队非常深厚的技术功底和对于引擎相当优秀的把控能力。
三、性能优化、进无止境
该游戏在Shader加载和GameObject Active/Deactive方面仍有一定的提升空间。在此，我们对其进行罗列，希望同样可以帮助到大家的研发项目。
1、Shader加载
目前，游戏副本切换时存在较高的Shader解析（Shader.Parse)开销，如下图所示。通过具体资源信息中的Shader资源分析，可以定位是如下几个Shader的加载耗时，对此，建议研发团队尝试对频繁使用的Shader进行预加载并常驻内存，从而减少不必要的Shader重复加载耗时。
2、GameObject Active/Deactive调用次数过高
该游戏在运行过程中，GameObject Active/Deactive的调用次数过高，在游戏运行的25000帧中，Active调用268952次，Deactive调用393490次。其调用的具体次数如下图所示（下图为游戏运行每10帧进行一次Sample，而每个Sample的数值为前10帧中Active/Deactive调用次数的总和。
其中，GameObject的Active/Deactive Top10资源信息具体如下所示，因此，研发团队可通过下表直接对频繁进行Active的GameObject进行完善。Deactive的完善亦然。
频繁的Active/Deactive操作不仅会造成CPU的浪费，同时，它还很可能间接造成更大的CPU耗时，比如Animator.Initialize耗时。该游戏的Animator.Initialize调用较为频繁，且耗时较高，如下图所示，而这就是频繁的Active/Deactive操作所造成的结果。因此，对于GameObject不必要的Active和Deactive操作进行控制，是非常有必要的。
最后，非常感谢《战地先锋》研发团队对 UWA 的认可和支持。感谢他们乐于将项目性能数据与大家一起分享，让更多的研发团队了解到一款性能优秀的3D移动游戏在各个模块上可以做到怎样的程度。同时，也欢迎更多的开发团队可以与我们一起来分享你们的性能数据，让更多的游戏开发者受益！
PS：安利这款FPS手游，在TapTap上已经获得了8.6的高分，并将于9月7日在14个安卓渠道同时开启付费删档测试，欢迎大家来预约！
原文出处：侑虎科技
本文作者：admin
转载请与作者联系，同时请务必标明文章原始出处和原文链接及本声明。
