MOBA手遊《小米超神》案例精講

原文連結：https://blog.uwa4d.com/archives/2130.html

今天我們為大家帶來由福州朱雀網路研發的MOBA手遊《小米超神》的UWA測評報告分析。該遊戲在不同配置的移動終端裝置上，無論是畫面表現力，還是效能開銷都非常優異。在此，我們將對該款遊戲的效能資料進行深度剖析，希望通過這篇文章可以讓大家對移動遊戲各個模組的運行效率有更為深刻的認知，並對大家的項目研發有所協助。 一、CPU效能

該遊戲在CPU佔用方面的效能非常不錯，下圖為該遊戲在紅米Note2裝置上進行一場5V5戰鬥時的效能資料。

可以看出，在紅米Note2上啟動並執行19876幀中，超過33ms的幀數佔比為13.9%，超過50ms的幀數佔比為1.7%，並且從圖中可以看出，其CPU耗時較高處主要集中在5V5情境的資源載入階段。因此，該遊戲在戰鬥時的效能可以說是非常優秀，絕大多數時刻遊戲運行非常流暢。

同時，通過進一步統計，該遊戲的CPU效能超過了64%的同裝置（紅米Note2）上測試的其他遊戲，其能耗更是低於86%的同裝置測試遊戲。由於目前國內的MOBA遊戲較少，所以上述排名並不是在MOBA類型中的排名，而是在所有類型遊戲中的排名。對於一款超重度的MOBA移動遊戲來說，該CPU效能和能耗排名可以說是相當出色。

其整體CPU效能的優秀表現與其各個模組的合理使用是分不開的。下面，我們就詳細講解其CPU效能方面的亮點之處。

1、渲染模組

通過UWA效能測評報告，我們可以看到該遊戲詳盡的渲染模組效能開銷。該遊戲在紅米Note2裝置上運行時的渲染模組CPU開銷如下圖所示。通過統計，半透明物體渲染的CPU消耗均值為1.7 ms，主要集中在0.8~3.0 ms範圍內（5%~95%）。不透明物體渲染的CPU消耗均值為1.0 ms，主要集中在0.2~1.7 ms範圍內（5%~95%）。可以看出，在整個5V5戰鬥過程中，無論是移動、Farm、Gank還是團戰，甚至上高地時，其渲染耗時都穩定在一個較低的耗時區間。這得益於研發團隊對於情境模型、蒙皮網格和UI的控制十分得當。

Draw Call峰值為167，且主要集中在 45~130範圍內（5%~95%），渲染三角形面片單幀峰值為64900，以上數值均處於合理範圍之內。

2、UI模組

該遊戲在紅米Note2裝置上運行時的UI模組CPU開銷如下圖所示。該遊戲使用UGUI作為UI介面的解決方案。經過統計，UI模組總體的CPU佔用均值為1.5 ms，主要集中在0.1~3.5 ms（5%~95%），屬於合理範圍之內。堆記憶體累積分配為16000幀 2.4MB，平均每幀分配堆記憶體155.4B，這說明該遊戲UI介面的製作及UI重建的影響範圍非常合理。目前，UWA推薦UGUI模組中，平均每幀堆記憶體配置儘可能控制在200B以下。

戰鬥情境中，UI系統的效能耗時主要是由UI元素的狀態變化而導致的，比如血條、飄字等HUD的移動、消隱等。這種操作稍不注意，就會帶來較高的UI網格重建開銷。所以，UI介面的研發看似直觀、簡單，但是其對於製作時的層層考究和運行時的耐心調優，則是一款產品是否“匠心”的試金石。以下則為《小米超神》這款產品在經過幾輪最佳化後的UI效能對比圖。

3、動畫模組

在UWA測評報告中，該遊戲運行時的動畫模組CPU開銷如下圖所示。可以看出，除進入情境時出現CPU高值外，其在戰鬥副本中的CPU開銷均控制在較低水平。Animator.Update的CPU均值為2.0 ms，主要集中在0.1~4.3ms區間內，對於MOBA項目5V5情境來說，基本上每幀均有90-130個物體在進行運動（除英雄、小兵之外，還有信使寵物、野怪、塔、插眼等等），由於玩家可以隨意查看地圖上任何一個角落的特點，其每幀的動畫系統壓力要比常規的MMO遊戲大上數倍。因此，《小米超神》可以將其控制在均值2.0ms的水平線上，已經是非常優秀的資料了。

同時，經過進一步檢測發現，動畫模組的耗時主要由Animators.ProcessAnimationsJob和Animators.FireAnimationEventsAndBehaviours導致，前者主要是持續的累積耗時，而後者則是非連續的“尖刺”開銷。前者是動畫系統對於AnimationClip的讀取和計算耗時所致，其耗時大小與當前幀參與計算的骨骼節點數、動畫曲線數、動畫執行狀態和Animator Controller的具體設定相關，其具體說明可參見《Unity中動畫系統效能最佳化方案回顧》；後者則是動畫事件的具體耗時，主要是項目邏輯代碼的效能開銷，此處研發團隊可以通過效能堆棧來進一步查看其邏輯代碼的開銷是否有進一步的最佳化空間。

4、GC 調用

該研發團隊對於GC調用頻率控製得非常出眾，遊戲在運行過程中，GC調用頻率為1656幀/次，優於目前93%的行業內遊戲。一般來說，我們建議一款項目的GC調用頻率可以控制在1000幀/次以上。

該遊戲的GC調用頻率如此優秀，主要得益於研發團隊對於項目代碼堆記憶體的控制。下圖為遊戲運行20000幀的代碼堆記憶體具體分配情況，其Top10函數的堆記憶體配置總和不超過80MB，足見該團隊對於堆記憶體配置的理解非常深刻。

目前的版本的堆記憶體配置仍然有進一步下降的空間，從堆棧資訊中可以看到，其Log輸出仍然存在一定堆記憶體配置，建議研發團隊在Release版本中將非關鍵性Log進行屏蔽。

二、記憶體模組

《小米超神》在記憶體上的表現如下圖所示。總記憶體峰值達到297MB，Mono堆記憶體峰值為48.9MB。297MB的總記憶體配置相對來說略高，研發團隊可嘗試在低記憶體機器上對資源進行進一步控制，從而降低低記憶體機器上的記憶體佔用。

1、Mono堆記憶體

從下圖可知，該遊戲的總體Mono堆記憶體控製得很好，在20000幀中，Mono的堆記憶體峰值為48.9MB，該值略高（UWA建議<40MB）。從圖中看，是戰鬥最後上高地時突然出現了較高的堆記憶體配置，迫使Mono堆記憶體上漲了8MB（如下圖紅框所示），對此，研發團隊可以根據具體位置查看其堆記憶體配置，即可定位其具體的堆記憶體配置根源。

但是，從走勢上來看，其Used Mono堆記憶體佔用在5V5戰鬥結束後，並未完全回落到情境之前（如藍框所示），這一點需要引起研發團隊注意，確認其是否為部分指定容器緩衝所致，從而排查項目是否存在堆記憶體泄露的隱患。

2、資源記憶體

經過統計，該遊戲運行時的紋理資源數量峰值為1003個，記憶體佔用峰值54.8MB。研發團隊將紋理記憶體佔用控製得很低，目前僅高於30%的行業項目。經過統計，在記憶體佔用峰值處，ETC1和ETC2格式紋理佔有835個，RGBA32格式紋理共佔有89個，RGB24格式紋理佔有5個，其餘為RGBA16格式紋理。

紋理資源在項目運行期間的總體使用方式：

對於紋理資源的最佳化，一般可分為以下幾種：

（1）使用更合適的紋理格式

從上圖中可以看到，在整個遊戲一場5V5戰鬥過程中，RGBA32格式紋理的使用數量較多，其使用總量已經超過了91%的的行業項目。對此，我們建議在視覺效果可以保證的情況下，儘可能使用ETC1格式紋理（Android平台）進行替換，不僅可以達到更小的記憶體佔用，同時可以獲得更快的載入效率。而對於無法進行硬體壓縮的紋理，可以通過Dither方法嘗試將其轉換成RGBA16格式的紋理，具體做法可以參考Unity圖片最佳化神器 - Dither演算法進階方案。

（2）使用更精準的紋理解析度

一般來說，為了讓模型看上去更加精美，除Mesh模型本身以外，其對應的紋理都會選用較高的紋理尺寸，從而讓其看上去更加精緻。但是，由於渲染物體在真正的遊戲中相對於相機是有遠近之分的，其顯卡底層往往沒有（或根本不需要）使用如此高的解析度來進行渲染，從而就造成了大量的資源浪費，這在我們深度最佳化過的項目中比比皆是。因此，我們建議可以通過UWA線上測評報告中GPU效能的Mipmap功能頁面來直接查看遊戲運行時，其底層的紋理解析度使用方式，如下圖所示。

同時，在深度最佳化報告中，我們也會進行更大量的測試和幾十億像素累積分析，從而來精準指出到底哪些紋理資源的解析度製作過高，可在不影響視覺效果的前提下，將其解析度縮小4倍、16倍甚至更多。《小米超神》項目通過這種方式不斷最佳化，其5V5情境的紋理記憶體已經從之前的78MB降到了現在的52MB。

以上是紋理資源的使用方式，其他資源的記憶體佔用情況如下：

網格資源在項目運行期間的總體使用方式：

Mesh資源的記憶體佔用較高，高於60%的行業項目。對於Mesh資源記憶體的最佳化，主要有以下幾種方法：

（1）控制網格頂點屬性的使用

詳細檢測網格模型中的Color資料和Tangent資料，當不需要時切記要將其進行去除，否則會在情境模型拼合時產生大量的記憶體浪費，具體詳細說明可以參考《移動遊戲載入效能和記憶體管理全解析》。

（2）控制網格頂點的數量

詳細檢測網格模型的頂點數(或面片數）使用是否過大。這是一個說起來容易但實施起來很難的問題，其痛點在於如何定義一個Mesh網格的頂點數是否過大。在UWA測評報告中會有一個建議，即建議將Mesh網格頂點數控制在1500個以下。但實際上，這其實是一個“不科學”的規定，因為沒有任何一個理論可以證明，其網格數量大於1500就是不合格，或則小於1500就一定合格。所以，我們這一年來花了大量的時間來尋求一種更為合理、科學的判斷規則。我們認為判斷一個網格模型使用是否合規並不應該是“靜態”檢測，而應該是一種“動態”檢測，與上述紋理資源的檢測一樣，我們應該去看網格資源在底層渲染時到底佔據了多少像素，從而以一種密度統計的方式來判斷其網格使用量是否合理。因此，我們提出了一種網格模型測量標準，即“網格模型渲染密度”，其表示每單位元量（比如，1萬）像素中，其網格模型的渲染頂點數量。

下圖則為遊戲運行過程中的網格模型渲染密度統計值。可以看出，雖然第一個模型“Mod_xyc_fz1001”的頂點數僅為1168，但其在遊戲運行時平均每幀的渲染像素量僅為34.91個，也就是說平均每個像素要渲染33個網格頂點，這顯然是一種浪費。因此，通過“渲染密度”這一檢測方式，可以反映任何一個模型在遊戲運行時的使用方式。在我們來看，這是一個比單純設定1500更加合理的判斷規則。

AnimationC