不知不覺，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性能保障體系的意義。至於爲何我們要這麼做，我想通過下面這則故事來進行解釋，大家讀完之後自然就明白了。

扁鵲是春秋戰國時的名醫，他有兩個哥哥，三兄弟都精通醫術。魏文王曾問扁鵲：“你們家兄弟三人，都精於醫術，誰的醫術是最好的呢？”

扁鵲回答：“大哥最好，二哥差些，我是三人中最差的一個。”魏王不解地說：“但是你的名氣卻是最大的啊。”扁鵲解釋說：

“大哥治病，是在病情發作之前，那時候病人自己還不覺得有病，但大哥就下藥剷除了病根，使他的醫術難以被人認可，所以沒有名氣，只是在我們家中被推崇備至。

我的二哥治病，是在病初起之時，症狀尚不十分明顯，病人也沒有覺得痛苦，二哥就能藥到病除，使鄉里人都認爲二哥只是治小病很靈。

我治病，都是在病情十分嚴重之時，病人痛苦萬分，病人家屬心急如焚。此時，他們看到我在經脈上穿刺，用針放血，或在患處敷以毒藥以毒攻毒，或動大手術直指病竈，使重病人病情得到緩解或很快治癒，所以我名聞天下。”

魏王大悟。

項目的研發需要持續改善，而解決問題的最佳時機就是在你看到問題的當下，而非在問題發生之後。

查看原文 >>