如何让你的游戏性能转危为安？

不知不觉，UWA在游戏性能优化领域耕耘了三年。我们相继推出了三项性能优化产品和服务：UWA驻场深度优化、UWA线上深度性能测评和本地性能测试工具UWA GOT （及其Online服务）。截止到目前，我们已经深度优化了近90款游戏，线上性能测评服务了2000多款游戏、VR和AR项目。

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

---

在介绍UWA性能保障体系之前，我们先来看看项目的性能瓶颈是如何形成的，为什么它会成为多数研发团队的困扰。

项目性能在开发阶段的表现

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

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

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

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

以上就是目前绝大多数游戏研发团队正在经历的过程，之所以会出现这种情况，其实是源于目前研发团队多数采用“瀑布流”式的开发习惯，具体如下图所示。

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

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

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

问题二：研发时间更长

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

“几年前我在加州曾和Palm公司的开发人员聊过天。他们开发出最早一批被大家认为“个人数字助理”的产品，即现在的通讯设备。当时他们自动把工作中做过的每件事都一一加以记录。他们记录的其中一件事是，解决程序Bug要花费的时间，也就是软件开发人员在开发自己的程序导致系统出问题时，得花多久的时间解决。每一次电脑都会自动追踪这件事。

现在假设某天测试人员在试图把Matt（一位研发人员）的程序整合到系统时，却侦测到了缺陷。Matt和大多数程序开发人员一样，都不想马上回头把程序改好，而是答应事后会修改，接着就继续写新的程序去了。

在大多数企业里，这样的测试动作甚至不会在写出程序的同一天进行，可能是等到程序写出来几周、几个月后才进行测试，问题都是到了那个时候才被发现。但是，Palm公司每天都针对所有程序都进行自动测试，因此一有问题就会立刻察觉。

测试人员检测全公司每一位“Matt”们，亦即数百名开发人员，并分析马上修改程序所花费的时间，和数周后才修复程序所花费的时间有何不同。不要忘了，软件是一种颇为复杂、牵连甚广的产物，你觉得上述两种改正的方式所花费的时间会相差多少？

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

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

问题三：团队士气低落

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

---

关于UWA性能保障体系

在UWA不断优化游戏性能问题的同时，我们也慢慢地摸索出了一套游戏性能的保障体系，相继推出了三项性能优化产品和服务（驻场深度优化、线上深度性能测评和UWA GOT本地测试工具），可以满足不同研发阶段的优化需求。我们希望不仅从技术层面优化性能问题，同样也能从流程层面来优化开发效率。

最早推出的UWA现场深度优化服务旨在解决研发周期中红色区域的性能问题。我们用最直接的方法帮助研发团队快速解决问题。性能流畅、顺利上线——这正是处于这个阶段的团队最急切的需求。目前，UWA技术团队能在10~15天内完成一份200多页的性能优化报告，其中涵盖了CPU、内存和GPU等全方位的问题瓶颈分析和相应的解决方案。根据我们报告中的建议进行优化，多数项目的性能均可在1个月内大幅提升。目前我们深度优化过的项目近90款，几乎覆盖了行业内所有的游戏品类。但随着优化项目的数量逐渐增多，我们也意识到了这种服务存在一定的局限性：

1）每一款项目的深度优化，我们都需花费大量的时间和精力来测试和分析，导致我们只能服务于少数客户，而无法让广大研发团队受益；
2）有该需求的项目的上线日期迫在眉睫，迫于压力，研发团队无法对一些框架问题做大量甚至结构性的调整，对于他们来说性能重要，但维稳更重要。

因此，我们推出了UWA线上性能测评服务。通过该服务，研发团队可以在UWA官网上提交项目进行性能检测，24小时之内就会收到一份详细的性能测评报告。参考性能简报（测评报告中某一页面）中的优化任务队列，研发团队即可逐条定位和优化。

虽然线上测评服务还无法达到驻场深度优化的精准，但却大幅提升了UWA的易用性：打个包上传就可以坐等报告了。迄今为止，已经有2000多个研发团队使用过线上性能测评服务。该服务更适合于研发团队从研发中期就开始使用，将更多的问题在中期进行解决，而不是全部放到后期优化阶段。这不仅可以缩短整体的优化时间，也可以让研发团队在上线测试后对突发问题更加游刃有余。

但是，我们认为这还是不够快。对于技术团队来说，永远希望在改变一行代码、一个资源的下一秒就能看到它带来的变化。所以，我们在去年推出了本地测评工具UWA GOT，今年又推出了UWA GOT Online在线测评服务。它的特点就是快和方便，且足以满足日常的检测需求。研发团队可以直接在本地进行测试，并在测试后的几分钟之内就可以对性能趋势进行查看和分析。

同时，通过UWA GOT Online的云端分析引擎，可以快速对性能问题进行定位，并收到详尽的优化建议。目前该工具已经涵盖了重要的性能参数，如FPS、内存、能耗、资源信息、逻辑代码和引擎模块重要参数等，不仅方便技术团队使用，更重要的是QA团队也能从项目研发的早中阶段开始，定期地对自己的项目版本进行性能跟踪，一旦发现某个版本上的某个重要性能指标出现了问题，就可以及时反馈给研发团队进行完善和修复。

以上就是UWA性能保障体系的三项产品和服务，下面我们从性能优化的效率、精准度和覆盖范围三方面来简单地对其特点进行总结，以方便大家更容易地理解。

在效率上：
驻场深度优化的问题解决能力最深入，通过现场对项目进行分析，为团队提供定制化的解决方案，但耗时相对较长，一轮完整的执行需要10~15天；线上深度测评的问题能力次之，但时间大为缩短，24小时左右就可以得到性能测评报告；UWA GOT本地测评工具更加倾向于发现问题，加入了UWA GOT Online分析服务后，进一步提升了它的解决问题能力，但它的特点在于快和方便。

精准度和功能覆盖面：
驻场深度优化毫无疑问最为精准全面，几乎CPU、GPU、内存和引擎各个功能模块都可以覆盖到；线上深度测评次之；UWA GOT在这两方面都要弱于其他两个功能，但其在线分析（UWA GOT Online）功能让其在精准度方面大为提升。

UWA性能保障体系的三种产品各有其使用特点：UWA GOT适合于研发团队对于版本性能的及时监控，类似于我们经常佩戴的一些检测心率等人体指标的运动手环；UWA线上深度测评适合于研发团队定期对项目性能进行检测，类似于我们平时的“体检”；UWA驻场深度优化，则是在问题较为严重且时间非常紧迫的情况下的解决方案，类似于“做手术”。

UWA性能保障体系

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

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

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

---

为什么要做UWA性能保障体系

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

扁鹊是春秋战国时的名医，他有两个哥哥，三兄弟都精通医术。魏文王曾问扁鹊：“你们家兄弟三人，都精于医术，谁的医术是最好的呢？”

扁鹊回答：“大哥最好，二哥差些，我是三人中最差的一个。”魏王不解地说：“但是你的名气却是最大的啊。”扁鹊解释说：

“大哥治病，是在病情发作之前，那时候病人自己还不觉得有病，但大哥就下药铲除了病根，使他的医术难以被人认可，所以没有名气，只是在我们家中被推崇备至。

我的二哥治病，是在病初起之时，症状尚不十分明显，病人也没有觉得痛苦，二哥就能药到病除，使乡里人都认为二哥只是治小病很灵。

我治病，都是在病情十分严重之时，病人痛苦万分，病人家属心急如焚。此时，他们看到我在经脉上穿刺，用针放血，或在患处敷以毒药以毒攻毒，或动大手术直指病灶，使重病人病情得到缓解或很快治愈，所以我名闻天下。”

魏王大悟。

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