性能总结，反应项目性能的状况以及严重性

1. 总体帧数：真人真机测试十分钟左右得到的帧数（专业会员15分钟左右）
你也许会问：游戏帧数越高越好吗？
理论上来说，是的。以一秒30帧为例，10分钟测试下来，理想的性能帧数可以跑到16000~18000帧左右。所以，如果你的项目帧数较低，那么你的游戏可能正在经受一定的帧率卡顿问题。

2. GC次数：测试过程中系统垃圾回收操作（Garbage Collection）的调用次数
需要注意的是，每次GC调用均会造成一定程度上的卡顿，降低了项目运行的流畅度。如果开发人员的逻辑代码分配堆内存过大过快的话，则GC调用的次数也会随之增加。那么标准是什么呢？我们建议把这个频率控制在1000帧/次以上，当然数值越大越好！

3. CPU均值：测试过程中平均每帧的CPU占用
UWA提供了多种测试机，覆盖了市面上高/中/低档的主流机型，如小米系列、三星系列等。一般来说，相同测试条件下，设备性能越好，CPU耗时的均值肯定是越低的。

很多朋友上来直接问，我们项目想优化到50+、60的fps，这个可能吗？

CPU耗时超过33ms的帧数耗时超过了68%（请注意，UWA的建议是低于10%），超过50ms的帧数耗时达到35%，我相信开发者看到这个数据的时候，一定是这样的：

莫着急，其实谁的项目优化前不是这样呢？等优化N轮后再晒晒美丽的性能数据吧，只要功夫深，铁杵磨成绣花针！

好的，那么我们喝口凉水压压惊，继续来看下面CPU占用走势图：

各个模块的CPU耗时走势图在这里是一清二楚的，也就是告诉大家哪些模块需要你们大动刀子了。未来的连载篇中我们会就具体模块给大家作一一介绍。

谈优化必谈内存

UWA报告中先给出了两个大指标：总内存和堆内存，也是项目负责人、发行运行商比较关注的指标。同样，由于内存模块是重中之重，UWA报告中对该模块进行了深度剖析，包括Reserved Total，Used Total等细分指标，能反应内存分配是否合理、堆内存是否增加过多以及是否存在内存泄露等重大问题。我们回头会逐一说明。

上图中，项目（卡牌类型）的总内存峰值为289MB，堆内存峰值为76MB，小编觉得有点过高了哦。那么内存把控多少是比较合理的呢？

1、内存
我们建议把内存把控在150MB以内。这是经过了大量的项目优化后的经验数值。其实，对于目前市场主流的Unity游戏来说，其内存占用主要集中在120~200MB。同时，顾及到例如iPhone 4和512MB/768MB等低端Android机型，其应用的自身总体内存占用不可超过200MB（iPhone 4的安全线应该在180MB左右），所以我们将Reserved Total设定在150MB，这是Unity引擎的自身内存分配。另外，某些渠道对Android游戏的PSS内存进行了严格的限制。一般要求游戏的PSS内存在200MB以下。这是我们将Reserved Total内存设定在150MB的另外一个重要原因。

不过呢，考虑到现在设备越来越高端，不少开发团队为了彰显美术表现力而舍弃了低端设备。 个人也觉得稍微高出这个标准也是无可厚非的事，更何况《六龙争霸》都在三星S3上跑到了221MB呢，当然未来UWA也会不断更新我们的测评机制，给大家一个更有时效性和差异性的标准啦。

2、堆内存
我们建议把堆内存把控在40MB以内。目前Unity所使用的Mono版本有这么个特点，即：Mono的堆内存一旦分配，就不会返还给系统。这意味着Mono的堆内存是只升不降的。在移动设备上的内存占用可谓是寸土寸金，因此我们要着重对堆内存把把关。

哪些函数是造成性能问题的罪魁祸首呢？

根据二八定律，80%的性能问题出在20%的性能瓶颈之中。我们的总结报告中也给大家罗列出来了。

1.高CPU占用函数

2.高堆内存分配函数

该部分所列出的代码函数既包含引擎模块函数，也包含自己的逻辑代码函数。小编再次提醒，由于这些函数占据了项目80%的性能开销，所以一定要各个击破！另外在UWA报告中的“代码效率”一栏中，我们也能查看到每个函数的具体调用情况，包括其调用次数、耗时分布、相关堆栈等信息，我们将在后期给大家做出详解。

关于任务列表

另外要提一下的是，测评报告还根据性能状态给出了优化任务列表，按照问题的严重程度设置了优先级，并对每个优化任务给出了需要检查或优化的步骤。

小编建议大家按照上面的顺序来进行优化，特别是在项目非常紧急的情况下，因为很多性能问题其实是相互牵制的，比如堆内存分配过高会加速GC的到来等等。当我们把这些大头都优化一轮之后再提交上来复测下，说不定效果立竿见影呐！

原文出处：侑虎科技
本文作者：admin
转载请与作者联系，同时请务必标明文章原始出处和原文链接及本声明。