拋磚引例

有別于之前家喻戶曉的暢銷大作，這次我們拿一個普通小清晰RPG游戲作為案例。在我們測試過的大量項目中，該游戲是少見的，以UI性能上位的。雖然這僅僅是第一次測試的數據，但是其在CPU耗時、堆內存分配上的表現都是甚如人意，瑕不掩瑜。

在UWA的報告中打開UI模塊性能界面，大家就能看到如上圖UI相關的詳細參數。包括：CPU峰值、CPU均值、堆內存分配總值、堆內存分配均值。這里的CPU峰值取自以下4個UI函數的耗時總和。堆內存分配總值指測試過程中，這4個UI性能函數分配的堆內存之和。

UICamera.Update()
該函數通常在點擊時出現開銷。因此，當該函數的CPU開銷較高時，通常都是因為調用了其他的較為耗時的函數引起。

UIRect.Update()
該函數通常在需要更新錨點位置時出現開銷。因此，當該函數的CPU開銷持續較高時，通常是因為當前場景中有較多的UI元素綁定了OnUpdate模式的錨點。

UIPanel.LateUpdate()
該函數為NGUI最主要的CPU開銷，包含了對所有UI界面包括其下UI元素的狀態更新、網格重建、DrawCall合并等操作。大量的UI變動或者不合理的UIPanel布局都有可能導致該函數出現較高的峰值。

UIRect.Start()
該函數主要涉及到UI元素的初始化操作，通常在UI界面被實例化時出現并產生一定的CPU開銷。

報告往下看，是各個函數的具體CPU和堆內存開銷。如果你對這些數據代表的數字是一臉懵逼的狀態，不清楚是偏高了還是偏低了，請先打開右邊的分析與建議。
如下圖，紅框內分別給出了四個函數的CPU占用詳情，包括主體范圍是多少，過高或過低。一般來說，我們建議堆內存總值控制在30MB內，如果可以，盡量再往20MB的極限靠靠。

在此，我們不妨點擊某一幀，在底部查看該幀的CPU耗時。

上圖中顯示，在第5500幀時CPU的耗時為5.4ms，若要溯本求源，我們可以再去CPU耗時詳情中定位是哪個函數引起的CPU開銷。

如上圖，我們看到這些耗時分別為：
UICamera.Update(): 1.2 ms
UIRect.Update(): 0.2 ms
UIPanel.LateUpdate(): 4.0 ms
UIRect.Start(): 0.0 ms (由于四舍五入)

通過這些具體的性能函數，以及這些函數的意義我們就可以大致做一個判斷了。接下來就需要各位程序大大結合自己的UI設計具體問題具體分析了。由于此文的目的是為了幫助大家理解UWA性能優化報告，因而并不會大篇幅講解NGUI性能優化的細則，下文先給一些比較通用的建議，可謂優化中的黃金法則！

---

優化支招

1、 盡可能將靜態UI元素和頻繁變化的動態UI元素分開，存放于不同的Panel下。同時，對于不同頻率的動態元素也建議存放于不同的Panel中。

2、對于UI元素，OnEnable和OnDisable都會進行較多的操作，因此即使不涉及到資源的加載，依然會有較大的CPU開銷，因此，對于切換非常頻繁的UI界面，我們建議更高效的做法是：
（1）改變UI的位置（以UIPanel為單位）來實現UI的隱藏和顯示，因為是位置移動，所以并不產生多余的CPU消耗，同時又可以節省Enable和Disable的CPU開銷。
（2） 通過設置相機的Culling mask 來實現 UI 界面的隱藏和顯示，同樣避免Enable/Disable操作。該做法可能會一定程度地提高內存的開銷（UIDrawCall中存儲的Mesh），因此可以根據UI切換的頻率來決定是否要進行優化。

3、UI資源進行詳細檢測，查看其分辨率、格式等是否足夠精簡和優化。

今天的分享就到這里，下一期我們會繼續講解UWA測評報告中的內存模塊，感謝各位開發者的關注。

總結

以上是生活随笔為你收集整理的如何读懂UWA性能报告？—NGUI篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。