从定标准到搭流程，看UWA性能保障体系搭建的实例分享

本次分享选自UWA DAY 2022 “UWA性能保障体系进一步拓展”议题，来自侑虎科技CTO张强的分享。从 “性能评分”、“推荐值”、“设备分档”和“自动化平台”四部分介绍UWA团队近一年来在性能保障上的探索。特别适合游戏初期进行项目质量规划和标准制定的大中型团队，以及正在研发周期过程中的中小型游戏研发团队。后者由于人力物力问题，并没有充足的资源来将质量标准在前期就定制完备，所以需要在整个项目研发阶段过程中对质量标准都不断进行迭代和调优。希望本文可以帮助到上述团队更加方便地达成目标。

以下是演讲实录（部分删改）：

大家好，我是UWA公司张强，本次分享由我来带关于性能保障体系的进一步拓展的分享。将分为 “性能评分”、“推荐值”、“设备分档”和“自动化平台”四部分，前三个是我们希望针对工业化方向上的“标准化”和“专业化”的完善工作。最后在“How to 性能保障体系”中，我们结合实例说明如何打造一个最简化的性能保障体系。

1. 性能评分

性能数据好不好，我们需要通过量化的指标说明。

下图中我们可以看到五个重要的指标，包括FPS 、Jank、内存峰值、耗电和温度，通过这5个指标计算出最终的评级，前两个指标对玩家的体验更直接一些，所以权重更高。

然而，随着越来越多项目对于性能有更精细化的要求，例如在高端设备上预期达到60帧，以及某些海外设备在内存上需要支持2G设备等，研发团队自然也需要一些更为精细的推荐值。

所以，UWA针对项目的目标帧率和目标内存，提供了更为科学的评级分数，并基于分数再给到一套更贴合需求的推荐值。

2. 推荐值系统

在这一年内，我们对于推荐值这个系统做了大量优化，包括：

2.1 基于耗时的推荐值优化
不同帧率目标下，每个引擎模块达到多少阈值是合理的？UWA做了大量的测试和分析得出了一套独有的推荐值系统。例如：图中对于30帧目标的物理模块耗时，与60帧时的耗时是不同的。那么对于追求60帧的项目，这些推荐值就明显更有指导价值。

同样的，根据实际的设备内存去调整资源内存阈值才是更为合理的方式。

2.2 通过设备算力分析不同设备上的参数推荐值
移动端上有一些比较特殊的参数影响着性能表现的，比如渲染面片数。对于GPU耗时来说，只要能够控制在25ms以下时就比较健康。但对于不同档位的设备而言，能渲染的面片数存在巨大差距。下图是小米5X、小米8和小米10能承载的渲染模块的阈值上限。

因此，我们就不仅要从帧率的层面调整阈值，还要从设备本身的算力上调整推荐值。

对于研发团队而言，设备分档也极为重要，尤其是低端机的定义需要尽早确认，越早规划后面返工的概率就越小。当研发团队有了自定义的设备分档之后，就能对玩家的设备算力进行评估，从而做一些性能和画面的平衡策略。

设备分档比较常见的方式是参照某些设备上能够获取到的部分字段，包括Device Model、SOC、GPU、CPU和内存等。目前更常用的还是针对GPU的型号，例如Mali、Adreno 以及 PowerVR ，可以通过一些固定的模式匹配出某些隐藏的字段，便于我们综合评估它的算力。

也有些额外的情况，例如某些设备虽然配置比较好，但不在已知配置列表中，我们也可以通过特殊的白名单做一些调整；还有某些特殊的设备，可能它的GPU算力评估下来还不错，但它的内存非常小或者它的CPU频率非常低，这就需要我们根据内存和CPU再去做分档的调整。

通过以上的思路可以相对全面地评估一个设备所在的算力档位。当完成设备的分档之后，我们就可以进一步进行性能和画质等方面的平衡设计。

3. 分级

3.1 画质分级
在游戏普遍追求高品质的当下，适当的画质分级就显得非常有必要。在和众多团队合作过程中，UWA摸索总结了以下维度，例如帧率、屏幕分辨率、大面积的不透明Shader、大面积特效使用的Shader、以及整体的Overdraw和渲染面片数等，这些都是在做画质分级的时候需要考量的。

3.1.1 场景

3.1.2 特效

另外，在后处理上，像Bloom、DoF和AA的使用，都可以针对高、中、低设备去做不同的设定，从而控制GPU端的压力。

3.2 内存分级
内存部分我们也建议针对性地做一些策略。对于资源内存，我们在不同设备上提供了阈值推荐，如下表；而Mono和Lua，因为其本身是逻辑层面的内存占用，所以通常是一个固定的数值。

内存分级通常会有一些比较快速的方式：给高、中、低配的设备设定不同的Prefab等级；或者是把一个场景一分为三，高配显示三个部分，中配显示两个部分，低配就只显示其中一个部分。

针对纹理，还可以通过Texture Streaming，或是通过QualitySettings.masterTextureLimit直接把纹理分辨率强制下降到1/4；针对网格，尤其是超大的场景，可以考虑结合HLOD替换一些非常远的建筑；如果是一些中距离的建筑，可以考虑针对LOD 0做一些动态的加载卸载。

还有一些比较通用的方式：通过修改缓存策略，比如说特效的缓存、动态的角色、怪物的缓存，通过设定一些上限和缓存的时间也可以有效地控制低端机上的内存。

3.3 测试用例
做了以上这些分级后，我们下一步就需要制定不同的测试用例，以遍历到我们关心的测试场景。

例如在项目的中后期，我们需要就新手流程、UI、战斗副本做遍历，以及进行压力玩法测试等。

而在项目前中期，也可以设计一些用例，例如场景中放置多个相机去播放动画模拟玩家、测试玩家在不同角度、不同场景的不同位置，检测场景渲染压力是否正常；还可以针对高、中、低不同档位的设备分别做测试，验证画质分级是否合理，从而帮助我们更早地发现制作流程中的问题。

下图是一个性能测试的典型例子。

结合UWA的性能测试工具获取每一段在播放过程时，它的FPS或者是其他维度的性能数据，基本上2~5分钟就可以体现出它的性能压力；这时候如果画质分级已经完成，也可以针对高、中、低不同档位的设备分别测试，验证画质分级的合理性；最后也可以通过类似右下角的统计表，查看每一个相机、每一个子场景的性能数据。

对于这个运行性能的数据检测，我们主要是通过GOT Online做日常检测。

同时，UWA在这一年中也增加了很多GPU Counter的数据，包括：Overdraw、ShaderCycles、带宽和图元，便于发现一些更为细节的性能瓶颈。具体的注意点如下：

Overdraw
研发团队要特别留意粒子系统是否比较多，或者面积比较大；一般我们建议低端设备上常驻的粒子特效的Overdraw尽量不要超过2层。

Shader Cycle/带宽
Shader Cycles可以比较综合地评估画面在渲染层面上的压力，因为它是像素着色相关的综合指标。不同GPU芯片上的Shader复杂度计算都不一样（即使同一个Shader），所以没有绝对的数值可以参考，但可以通过相对值查看局部是否有问题。

图元
我们建议关注“被剔除的图元数”的占比，一般来说该值通常是小于50%的。如果这个值明显高于50%，那多数可能是美术同学在场景里面放了一些非常巨大的模型，导致相机只照到一部分但整个模型都参与了渲染，造成了比较大的浪费。通过这个数据检测，我们就能够尽早地去暴露出美术制作层面上的问题，从而优化制作流程。

4. 自动化测试

完成以上这些工作后，如何得到性能数据就成了重中之重。项目、用例、设备的不同组合会产生庞大的测试工作量，从而占据大量人力。而QA本应该集中精力于测试用例的维护，以及数据的分析与统计，从而更好地服务于项目制作与流程的优化。所以，自动化平台就承担了非常重要的角色。而UWA Pipeline就能很好地满足这一需求：可以管理真机、进行多设备调试、上传下载脚本等日常需求。

目前UWA Pipeline上使用的测试用例脚本是Airtest与Poco的组合，可以通过Poco的UI树或者图像识别的方式完成。UWA会持续优化这方面的稳定性和维护性。

对于上文我们提到的场景/特效测试，这部分测试流程是不依赖于点击操作的，可以通过Airtest+Poco+RPC接口调用的方式实现整个测试框架的搭建，在持续性和维护性上都非常好。

同时，UWA GOT Online也与Poco SDK进行了深度的结合，项目组可以在Poco的代码中调用接口实现GOT Online的自动测试开启、区间标记和数据上传。

由此我们就可以实现“测试用例 -> UWA测试工具集成 -> 测试设备指定 -> 自动化测试 -> 自动上传数据”的全自动过程。后续通过对报告数据的整理分析，形成对项目的持续监控。一旦发现数据中的隐患，团队就可以及时地应对。同时，通过UWA的推荐值系统，进一步方便大家定位不合理的性能指标。

5. UWA性能保障体系

到此，我们已经可以通过自动的方式获取性能数据，这些数据借助UWA平台又可以得到优化方向，再把这个循环持续往复，就可以确保整个开发、制作流程，以及游戏层面所表现出来的性能的健康度。

那么，要把这样的功能点落地会涉及到哪些细节的步骤呢？我们以一个常见的需求为例。

5.1 需求描述
a. 项目已经制作好了若干个场景，也布好了一些相机点位，通常是玩家经常会遍历的地方；
b. 项目组希望能够搭建自动化平台，需要指定高中低的设备以及测试用例，每天或每周定时在这些设备上测试；
c. 美术同学还会每周往里面新增各种资源，完善里面的一些细节。

希望实现了这个平台后，项目组每周都可以查看最新的性能数据，分析这周的制作过程里有没有出现问题。我们可以把这样的预期效果认为是非常简单的一套保障体系的缩影。

5.2 搭建流程
第一步我们需要在工程里面去做一些配置，包括：
a. 集成UWA GOT SDK
b. 集成Poco SDK
c. 通过C#脚本实现切换相机点位的代码，并添加Poco的RPC调用逻辑

第二步就是自动化的配置：
当我们已经做好工程的一些配置，并且打包之后，我们可以通过Airtest的IDE连接到一个固定的测试机，安装好游戏后就可以开始编写测试用例。

整个耗时基本上控制在一小时之内，包括可能学习Airtest IDE的用法、UWA SDK提供的一些接口方法以及一些调试工作。

接下来就是UWA Pipeline的搭建了，简要的步骤如下：
a. 需要安装一个主节点
b. 需要打包的子节点
c. 准备自动化测试的子节点（如果需要控制的设备量比较大，可以考虑用工控机作为子节点）

5.3 制作流水线 & 数据查看
接下来就是制作流水线，这个步骤可以在局域网内的其他电脑上进行。

我们首先在Pipeline文件夹里添加自定义的流水线，在这个流水线里我们可以去配置整个流程。

a. SVN的更新，就是把我们的仓库同步到打包节点上，更新资源信息
b. 触发工程打包，打出APK
c. 这个APK上传到“包管理”
d. 执行自动化测试。在UWA Pipeline的自动化测试的节点里有一个“GOT Online” Stage ，完成具体的配置后，一旦流水线走到这个Stage， 它就会按照这些配置去执行自动化测试。
a～c三步都是在Pipeline里内置好的，只要配一下对应的这个路径即可。

整条流水线运行完之后，数据就会被上传到UWA云端解析。每条流水线会有运行记录，我们就能看到这一次流水线的运行总共生成了多少份性能报告和报告信息。

如此一来，整个流程就可以自动化地运转起来了：
美术同学添加资源 -> 流水线自动地去拉最新的资源 -> 打包测试生成数据 -> QA查看数据，做简单的分析统计 -> QA反馈性能隐患

通过这样的方式，可以让项目组的场景制作流程以比较稳健的方式持续下去，而对于美术而言，也可以慢慢形成一个良好的制作习惯。

这些量变改善的最后，我们会发现性能优化的工作开展变得容易且从容了许多。从根本上讲，大幅度返工的工作变得很少了，即使有问题，都在项目开发人员的掌控之中了。

---

在工作流程中，即使是认可性能保障的团队，如果在以上任意一环中缺少方法或工具，内部推动都可能会阻力重重，因此希望以上性能保障的拓展分享给大家有所启发或借鉴；当然UWA也会持续深耕该领域，期待明年给大家更落地更深入的实践分享。

本文《UWA性能保障体系进一步拓展》的课题视频可前往UWA学堂免费浏览。