新终端游戏运营审核体系之——Clt性能专题

导语：研究影响客户端性能的因素很多，引发卡顿表现的根因也很多，为此客户端性能方向一直在尝试将性能进行切分和定位，同时期望将用户表现在游戏开发测试期间就重现定位出来。为了在游戏版本发布前就尽可能发掘性能瓶颈，也研发了各种性能指标监控和分析工具来辅助测试。但真正游戏发布上线后性能表现是否符合测试结果，如果不符合再去调整测试方法，是让这项专项更加精准的一个闭环递进。以下以某腾讯自研游戏（代号：SG）为例进行说明。

1. Clt性能审核闭环

1.1 需求分析&场景设计

 一般而言，项目需求（白皮书、策划案、TAPD需求等）大都是针对游戏功能进行描述，比如：新增xx系统，xx功能优化，xx数值调整，xx运营活动……。对我们游戏测试而言，我们需要对每个需求进行分析，了解其实现细节，评估该需求是否会影响客户端性能，进而进行相应的测试场景设计，以期性能测试覆盖版本变更内容。以SG为例，我们会对版本需求（TAPD）进行逐一分析确认，最终输出影响客户端性能的需求，如下图（来自版本审核计划）。

需求中，迷雾模式调整剂新英雄和皮肤是我们会特别关注的。前者是未大规模使用的模式，需要验证性能优化效果；后者是新版本的核心体验内容，需要确保新英雄不会比以往的英雄消耗更高的手机资源，造成用户体验不畅。因此我们需要进行迷雾模式性能对比测试，以及新英雄的单英雄模式测试。

1.2 性能采集

1.2.1 性能采集工具

UnityVerify 采集android平台手游的所有基础性能数据，针对FPS、内存、CPU、流量等数据进行基于版本的管理，同时专业版拥有对unity引擎中C#函数耗时消耗的实时采集和深度分析能力；

UnityCube 跟UnityVerify相比，对内存侧的分析更加专业，mono层运行态内存、资源问题分析；

AdrenoProfiler 由高通提供，分析高通芯片的GPU渲染性能即单帧分析更加专业；

WeTest GAutoMator 支持UGUI和NGUI的自动化测试框架，对于需要多人配合开局测试性能的场景，通过自动化脚本可节约人力；

因此研发测试阶段和专项审核阶段，针对性能采集和深度分析会用到这些工具。通常，fps、cpu、pss、gpu、流量，是5个基础的重要性能指标，其中，针对SG这样的moba类游戏，基于帧同步的实时性和包量较大的项目，FPS和流量更为重要。

1.2.1 性能采集场景

前面提到的跟版本内容相关的场景设计，此处的采集场景，更多是指手机设备、工具使用以及操作方式上的场景。以SG游戏 5V5模式为例，在游戏进入运营期后，我们需要确保随着版本的迭代，客户端性能保持平稳。那么如何界定性能趋势是平稳、下降还是有所提升呢？版本间性能数据对比是我们目前用的方法！那如何确保性能数据具有可比性呢？采集场景必须固定！例如：不同版本测试时，10个对战英雄必须一致；测试人员的操作方式必须一致。

1.3 深度分析

深度分析，是在基础性能采集的基础上，对影响游戏性能的相关指标进行更加专业的测试分析。以SG游戏为例，我们使用unitycube对影响内存的纹理大小、网格大小、资源重复率、gameobj数量等进行持续对比，使用自研工具对影响渲染消耗的粒子数量、顶点面片数量、纹理大小等进行持续监控，使用unityprofile对影响cpu资源的函数进行持续对比测试。以期在基础性能发现数据变差后，能够更进一步帮助开发定位性能问题所在。

1.4 审核报告

版本上线前，需要整合基础、深度分析结果，向项目干系人发送全面的带有结论的性能审核报告，供项目组作为评估版本是否符合发布标准的参考。

1.5 发布监控

1.5.1 性能监控

PS：版本号、地图id（模式）、画质（如果有）、机型是性能统计上报的基础字段，必须要有，否则会导致上报的数据无法归类统计，也就起不到任何指导作用了。

前面提到，fps、cpu、pss、gpu、流量为5个常见性能指标，但目前公司及行业内均没有可以不依赖于root对安卓和ios设备进行这5个指标数据的收集方案，因此，在SG项目中，采用的是程序内部统计部分关键指标，并利用msdk的灯塔上报功能进行统一上报。

1.5.2 数据上报

数据上报，采用的是apollo组件的ApolloHelper.GetInstance().ApolloRepoertEvent函数进行上报，数据会上报到灯塔平台的tdw数据仓库（t_sd_beacon_eventlog 表）中。

之所以需要用tpg库，是因为灯塔仓库中的数据由于量很大，数据临时保存7天，因此需要申请一个额外的资源库将数据导出来。同时tpg库也有针对各种语言的接口，适合对数据做二次处理。

1.5.3 数据统计

每个项目的情况略有差异，但整体步骤和环节保持一致。

1.5.4 数据展示

2 案例集

2.1 案例一  “玩家的抱怨”

“来自玩家的抱怨”

以游戏SG为例，每个版本发布后的前几天，在论坛、贴吧上总能看到不少的玩家反馈游戏“卡”，核对机型发现其性能并不差。“个体问题”、“他设备上可能运行了大量的软件”、“他网络卡”、“测试没有问题啊”等等各种质疑弥散在游戏研发团队中。

“如何审核的”

对游戏SG的版本需求梳理后，选择了高中低配多款机型，针对有变更的游戏场景（地图、英雄）进行审核。审核的方式是：组织10位测试人员，固定对局的10个英雄，使用“固定”的操作模式，对战10分钟，使用UV搜集性能数据进行两个版本间比较。考虑到每次测试过程并非绝对一致，如果平均fps连续3个版本偏差1帧以内，则性能符合预期。根据经验，审核方式并没有大的问题。

“是玩家误报还是测试不足”

推动项目组增加了一系列的性能数据上报，并对数据进行统计，在新版本发布后，得到了如下的曲线图，所有机型平均帧率下降了1帧！部分机型反弹了一小段，而部分机型则维持在低位。而事实上，版本能够发布，肯定是审核通过了的！少量对局的数据可靠，还是外网几十上百万的数据可靠，结果不言而喻。

“怎么改进”

【研发阶段】最直接会想到，内网测试对局数太少，单局数据不稳定性大。如果采用增加采集测试的次数，例如每一轮测试3次，将3次数据求平均再进行比较，但其实也并不见得有效。需要更多保障前后两次测试场景的一致性，例如将机型和英雄绑定（相同的机型，操作不同的角色，结果都不一样的，因为每个英雄的特效、age不尽相同）、机型和测试人员绑定（相同的人操作相同的英雄，模式会更固定）。但长线来说如果自动化采集更多的对局自动化计算会更加靠谱的做自动的大数据的产生，这是我们持续在跟进验证的。【运营监控】开发配套工具，对性能数据进行持续的展示监控。

2.2 案例二  “问题依旧”

“新的困惑”

当案例一中的改进落实后，在新的版本发布后，外网玩家仍然大量反馈卡。而查看监控数据，fps平稳，网络延迟平稳，内网测试结果显示版本间各项数据（fps、pss、cpu和gpu）也很平稳！

“新的数据指标”

影响客户端卡顿的因素，除开fps和网络延迟，还有什么呢？通过对舆情数据的分析得出，玩家设备表现并非是一直卡（低帧），而是“随机”的顿卡。再回头看性能数据指标，fps波动特性明显没有得到评估！而这一特性的评估可以使用方差/标准差进行统计。

“持续的改进审核方法和监控内容”

于是，【研发阶段】改进了测试工具，除了统计fps均值以外，fps标准差也进行跟踪，同时确定标准：连续版本间的标准差不得超过2。【运营监控】对于外网监控，由于计算方差或标准差，需要对每帧fps值进行记录，这可能会导致游戏内存占用增多甚至数组越界造成crash的风险，因此目前暂时没有在外网统计该项指标。

需要我们在已设定好的工作模式下寻求新的改变，掌握外网实际数据。穷则变，变则通，通则灵！

3 关于手游性能数据上报监控的未来思考

如何尽可能低成本、便捷的上报各游戏性能数据是需要思考的，也需要根据游戏个性来做各自不同的定制化的。