游戏性能保障体系

来源

随着优化的项目越来越多，我们逐渐意识到性能瓶颈不仅是技术层面所致，也来源于开发流程。在游戏项目的精品化和重度化趋势中，任何一个中间环节产生了资源浪费，对最终结果的影响都可能难以预估和弥补。
所以，我们推出了游戏性能保障体系，我们认为性能优化不该局限于以前的“头疼医头、脚疼医脚”的救火行为，而应该将其扩展为质量保障体系的一环来保证研发团队更快地发现问题、解决问题，从而加快项目的研发效率。

性能瓶颈的产生

项目的性能问题并非一开始就产生，也不是某一天突然出现的，而是在研发过程中日积月累的产物。
在绝大多数的项目开发流程中，其性能耗时的走势大致如下图所示：

• 蓝色区域为研发期，一般为游戏立项后的功能开发和堆量阶段。在这一阶段中，功能开发是研发团队的主要目的，很少有团队在这一阶段会关注性能问题，即便是有QA的团队，这一阶段多数也是在测试功能的合理性和正确性，于是性能问题会在这里大量堆积，从0到1，再从1到100。

• 红色区域为上线测试和优化阶段，现在的项目研发团队多数都集中在这个阶段来进行优化，这时候主要功能已基本开发完成，后续是功能的调整、完善和调优；同时伴随大量玩家的涌入，性能问题被极速放大。卡顿、发热和崩溃问题是这一阶段开发团队和运营团队最为头疼的问题，熬夜、通宵也往往是“家常便饭”。

• 绿色区域是经过几轮测试和优化后，项目整体性能趋于稳定的状态。一般只要研发团队熬过了红色区域的优化阶段就可以顺利上线公测了。当然，后续也会有新版本的更新、新功能和内容的加入，所以不少项目的性能问题依然会再次涌现，即再经历前面的蓝色和红色区域，依次往复。

瀑布式的开发流程

造成上诉这种情况，其实是源于目前研发团队多数采用“瀑布流”式的开发习惯

从预案设计，到程序开发、美术开发和玩家测试，根据反馈优化性能和调整方案，直至游戏上线。在项目内容和功能开发的过程中，虽然QA团队会对项目不断测试，但基本上都是围绕功能和数值，针对性能相关的测试寥寥无几。而随着项目的精品化程度要求越来越高、同品类竞争项目的数量越来越多，这种开发方式在性能方面的弊端暴露无疑：

问题一：性能优化时间紧、难度大

在开发流程图中的红色区域，是性能问题暴露的重灾区。这一阶段中，项目团队的制作人、策划和运营团队都在不断催促程序对性能进行优化，以期快速达到流畅的表现效果。原因很直接也很现实：玩家用户不等人。但是，短时间内修复长时间积累的大量性能问题，这其实是非常困难的，甚至可以说是一个悖论：如果研发团队拥有在短时间内就可以力挽狂澜的技术实力，那么在之前的开发过程中，也不会留下大量的性能缺口。

问题二：研发时间更长

研发团队在蓝色区域开发时，会习惯性地将问题（特别是性能问题）的解决后置，希望在后续的测试和优化阶段中集中处理，这是因为除了保证功能的研发效率之外，不少研发团队潜意识中对问题的解决持有这样的态度：同样一个问题，现在还是以后修复其实工作量都一样。这里我们想借用Scrum之父Jeff Sutherland在《SCRUM：用一半的时间做两倍的事》这本书的原话，他非常强调问题一旦发现就立刻解决的重要性：

几年前我在加州曾和Palm公司的开发人员聊过天。他们开发出最早一批被大家认为“个人数字助理”的产品，即现在的通讯设备。当时他们自动把工作中做过的每件事都一一加以记录。他们记录的其中一件事是，解决程序Bug要花费的时间，也就是软件开发人员在开发自己的程序导致系统出问题时，得花多久的时间解决。每一次电脑都会自动追踪这件事。
现在假设某天测试人员在试图把Matt（一位研发人员）的程序整合到系统时，却侦测到了缺陷。Matt和大多数程序开发人员一样，都不想马上回头把程序改好，而是答应事后会修改，接着就继续写新的程序去了。
在大多数企业里，这样的测试动作甚至不会在写出程序的同一天进行，可能是等到程序写出来几周、几个月后才进行测试，问题都是到了那个时候才被发现。但是，Palm公司每天都针对所有程序都进行自动测试，因此一有问题就会立刻察觉。
测试人员检测全公司每一位“Matt”们，亦即数百名开发人员，并分析马上修改程序所花费的时间，和数周后才修复程序所花费的时间有何不同。不要忘了，软件是一种颇为复杂、牵连甚广的产物，你觉得上述两种改正的方式所花费的时间会相差多少？

答案是相差了二十四倍。假如程序在出现缺陷的当天被改正，这或许得花一个小时；但是数周后才被改正，就必须花费二十四小时。这和Bug是大是小、是复杂是简单并没有关系。

他在大量的实际项目中发现，同样的问题、同样的人去解决，但时间点的不同往往会让解决效率大相径庭。这种情况，在我们现在的项目研发过程中比比皆是。

问题三：团队士气低落

研发过程中的红色区域可以说是相当“磨人”的：卡顿、发热等问题造成的用户流失会给开发团队带来极大的压力。功能不好可以修正，数值不好可以调整，但真正麻烦的是明知道性能有问题却无从下手。这种有力使不出的无助感才最磨人，团队的士气也就在这一次次的测试中消磨殆尽。人心散了，队伍就不好带了。

性能保障体系

在不断优化游戏性能问题的同时，我们也慢慢地摸索出了一套游戏性能的保障体系。自动将性能分析集成到游戏代码中（这里选用的是Unity提供的URP系统，市面上还有UWA等），进而通过人工、或自动化(AirTest脚本)的方式进行性能测试。我们希望不仅从技术层面优化性能问题，同样也能从流程层面来优化开发效率。

性能保障系统自动化方案

项目组无需关心性能分析模块代码，打包选择Profiler模式将自动集成此代码到安装包内

• 打完安装包后，有两种方式可供选择
  • 选取自动化测试的脚本进行自动测试。测试完成输出两份报告：1.集成测试报告（主要突出功能通过率）2.性能分析报告（详见URP报告）
  • QA进行常规功能测试或者项目组进行性能分析时，把UPR工具开启。会输出性能分析报告。

工作流转变

我们希望通过性能保障体系来完善研发团队的研发流程，从而方便研发团队及时发现和解决问题。通过性能保障体系，可以让研发流程并形成如下几个快速反馈的闭环：
（1）对于QA团队，无论是研发、测试还是上线阶段，都可以针对性能进行及时监控；
（2）对于技术团队，性能问题及时发现、及时修复，具体问题具体解决；
（3）对于策划团队，性能问题背后的设计需求可及时调整和变更。

当上面的闭环逐步迭代流转起来之后，可以达到如下效果，性能耗时在开发过程中的趋势可以变成如下方式：

这样一方面可以将后期的优化工作前置，另一方面及时的问题解决可以极大减少后期的优化时间，还能尽早规避掉相同的性能问题，加快游戏的整体研发进度。

为什么要做性能保障体系

“防范大于救火”，这是性能保障体系的意义。至于为何我们要这么做，我想通过下面这则故事来进行解释，大家读完之后自然就明白了。

扁鹊是春秋战国时的名医，他有两个哥哥，三兄弟都精通医术。魏文王曾问扁鹊：“你们家兄弟三人，都精于医术，谁的医术是最好的呢？”
扁鹊回答：“大哥最好，二哥差些，我是三人中最差的一个。”魏王不解地说：“但是你的名气却是最大的啊。”扁鹊解释说：
“大哥治病，是在病情发作之前，那时候病人自己还不觉得有病，但大哥就下药铲除了病根，使他的医术难以被人认可，所以没有名气，只是在我们家中被推崇备至。
我的二哥治病，是在病初起之时，症状尚不十分明显，病人也没有觉得痛苦，二哥就能药到病除，使乡里人都认为二哥只是治小病很灵。
我治病，都是在病情十分严重之时，病人痛苦万分，病人家属心急如焚。此时，他们看到我在经脉上穿刺，用针放血，或在患处敷以毒药以毒攻毒，或动大手术直指病灶，使重病人病情得到缓解或很快治愈，所以我名闻天下。”
魏王大悟。

项目的研发需要持续改善，而解决问题的最佳时机就是在你看到问题的当下，而非在问题发生之后。