UPA深度性能報告解讀

做者：張濤，騰訊互娛測試工程師
商業轉載請聯繫騰訊WeTest得到受權，非商業轉載請註明出處。
原文連接：http://wetest.qq.com/lab/view/403.html

WeTest 導讀

UPA做爲騰訊WeTest與Unity官方聯合打造的客戶端性能分析工具，爲開發者提供了極大的便利和效能提高。產出的分析報告內容詳盡，但您是否真的讀懂了報告？是否瞭解每項數據的含義？這次就讓咱們的大咖來爲您詳細解讀UPA的性能報告，讓您瞬間秒懂。

---

測試概況

通常作完數據收集後，查看upa深度性能報告，最早看到的就是測試概況頁面。

上面的數據大體能夠分紅這幾個方面來看:

1）平均幀率既和CPU耗時有關（點擊下方的經過/未經過按鈕可跳轉到CPU模塊），也和GPU耗時有關。

2）ReservedMono內存能夠理解爲遊戲中腳本分配的內存，進一步定位能夠藉助upa的mono內存測試（詳見附錄）。

3）紋理、網格、動畫、音頻等能夠理解爲資源內存，進一步定位能夠藉助upa的資源內存測試（詳見附錄）。

4）drawcall和Tris和GPU耗時有關，進一步定位能夠藉助針對GPU分析的工具（詳見附錄）。

5）pss內存通常用於定位多局戰鬥、場景跳轉、打開關閉UI中是否有內存泄漏，能夠藉助wetest助手中的通用性能測試獲取。

經過概況頁面能夠大體看出遊戲存在的性能問題，upa也給出了問題和優化建議：

CPU

cpu模塊提供了CPU耗時相關的詳細數據。

cpu性能佔用這一頁籤的概述給出了各模塊的總體耗時：

frameTime：當前幀總耗時；

RenderingTime：當前幀渲染耗時；drawcall越高，這部分開銷越大。能夠經過減小所渲染物體的材質種類（內存頁簽下的材質資源），下降drawcall。

ScriptTime：當前幀函數耗時。

PhysicsTime：當前幀物理耗時。

從上圖中能夠看出函數和渲染耗時比較多，能夠看下概況頁面下的耗時排名top10的模塊：

針對耗時較高的幀，能夠查看詳細的模塊耗時狀況：

好比上圖選取的第1401幀耗時較大（場景加載），能夠展開模塊耗時，查看具體模塊具體函數的耗時、時間佔比以及每一幀的GC Alloc。

Loading.UpdatePreloading，主要負責卸載當前場景的資源，而且加載下一場景中的相關資源等。下一場景中，自身所擁有的GameObject和資源越多，其加載開銷越大。

內存

內存模塊反映了遊戲各方面的內存佔用狀況。

上圖中的total_reserved是unity引擎在內存方面的整體分配量，total_used是unity引擎在內存方面的整體使用量，unused_total是空閒的內存。這裏的引擎分配內存和空閒內存都比較多。

total_reserved內存=unity_reserved內存+GFX內存+FMOD內存+Mono內存+Profiler內存

下面分別展開說明：

unity reserved：這部分主要包括資源內存。能夠針對紋理、網格、動畫、材質、音頻資源優化。好比FBX模型導入時，"Read/Write Enable"是默認開啓的，mesh數據會保留一份在unity reserved中，關閉能夠減小該模型在unity reserved中佔用內存一半的大小。

mono reserved：分配的mono內存（綠線部分），只升不降，須要嚴格控制。mono內存表示遊戲中腳本分配的內存，雖然mono自己提供了垃圾回收機制，但仍是可能出現內存泄漏。若是須要進一步定位，須要藉助upa的mono內存測試（詳見附錄）。

gfxdriver_reserved表示渲染模塊的內存，若是比較高須要對紋理資源和Shader進行優化。

fmod_reserved表示音頻模塊的內存，若是比較高須要對音頻資源進行優化。

profiler_reserved表示unity profiler分配的內存，無需關注。

圖形

圖形模塊和GPU耗時相關。

圖像概況頁籤的幾個指標：

1）SetPassCalls：

渲染Pass的數目，每一個Pass都會消耗對應的一個drawcall，在知足渲染效果的狀況下儘量的減小Pass的數量。

Shader 「ShaderLab Tutorials/TestShader"{

SubShader{

Pass

{

//...

}

}}

2）drawcalls：

cpu發送給gpu的渲染請求數，請求中包括渲染對象全部的頂點、三角面、索引值、圖元個數等。

3）verts：

攝像機視野內渲染的頂點總數。

4）tris：

攝像機視野內渲染的三角面總數。

5）VRAM usage：

顯存的使用狀況，它的總大小取決於顯卡的顯存。

6）VBO Total：

渲染過程當中上傳到圖形卡的網格的數量。

這是合批頁籤中的概述，表示在標識區域中開啓動態合批後平均節省下3.24個drawcall。

這是模塊耗時頁籤中的概述，Camera.Render表示相機渲染準備工做的cpu耗時；Shader.Parse表示資源加入後untiy引擎對shader的解析耗時。Shader.CreateGPUProgram表示GPU對加載進來的新shader針對目標平臺編譯的耗時。

附錄

一、mono內存測試

條件：手機已root，且系統非android 7.0及以上。

測試方式：在合適的時間點打2次以上的內存快照，進行對比（獲取保留和新增的資源類型、對象堆棧、引用次數）。好比主城反覆跳轉的場景發現mono內存一直在增加，就能夠在場景跳轉前打一個snapshot1，在場景跳轉後打一個snapshot2，最後在場景跳轉回原主城再打一個snapshot3。

二、資源內存測試

條件：手機已root，且系統非android 7.0以機上。

資源結論：

資源重複是指內存中同一時刻，存在兩份或以上相同的紋理、網格、動畫、音頻等資源。通常是相同的一份資源被打包到多個AB包中，若是這些AB都被加載進內存，內存中就會存在多份相同的資源。這個比率是按重複資源的大小除以總資源的大小來算的。

若是資源重複率超標，通常是優先處理資源較大、重複數量較多的紋理或網格。

紋理資源超標，通常優化的方向：

1）紋理用於UI，禁用mipmaps；

2）儘量下降紋理分辨率，不要超過2048*2048；

3）android儘可能使用ETC格式，ios使用PVRTC格式；

4）低配機目前通常不支持openGL3.0，故使用ETC2時會自動轉換成RGBA32，紋理佔用大概是中高配機的4倍。解決方法是統一改爲全部機型都支持的ETC1,一張RGB，一張alpha，渲染時再合併。

網格資源超標，通常優化的方向：

1）減小頂點和三角面數。Simple LOD插件能夠用來簡化網格資源；

2）若是網格資源數據不進行讀寫操做，須要將Read/Write Enable關閉。

動畫資源超標，通常優化的方向：

1）在不影響表現的前提下，減小Animation的幀數；

2）開啓"Optimize GameObject"；

3）按需加載，好比在戰鬥中會有角色站立、死亡、攻擊等動畫剪輯，這些不用在戰鬥的每一幀所有加載。

音頻資源通常不多超標。

三、Adreno Profiler

比較經常使用的針對GPU分析的工具備Mali、PowerVR、Adreno Profiler等，比較方便使用的仍是高通的顯卡分析工具Adreno Profiler。（P.S. 目前adreno profiler不更新了，若是抓取不了遊戲單幀，推薦使用intel GPA+模擬器的組合）

使用條件：查看手機是否高通芯片，PC上裝有adb環境。

首先手機上打開遊戲，運行到須要抓取的界面，而後在PC端打開Adreno Profiler，點左上角的Connect。

雙擊鏈接以後，點擊Scrubber GL彈出抓取界面，而後點擊Caputure Frame等待便可。

Frame states下查看渲染相關參數：

好比Miscellaneous選項下Total Texture Usages爲紋理顯存使用總量：

好比Texture Formats選項下爲紋理格式分佈：

好比Render Calls可視爲draw call統計：

左邊是抓取到的當前幀的全部繪製指令，鼠標在listview中從上到下點擊，能夠還原當前幀的繪製過程。

這個是紋理瀏覽器，是捕獲幀加載進來的紋理資源。從上面的截圖能夠看出來這個圖集（將許多單個的紋理合併到一個較大的紋理上）填充的不飽和，能夠拆分紅1024*512的圖集。

也能夠發現有如出一轍的紋理且重複多個：

這個是shader瀏覽器，能夠針對一些消耗性能比較大的shader作優化。

vertex shader：頂點着色器，逐頂點計算，計算次數等於頂點數。

fragment shader：像素着色器，逐像素計算，計算次數等於像素數。

通常對於shader優化的建議：

1）在不影響效果輸出的狀況下減小變量的精度；避免數據類型的轉換。

2）減小或避免使用冪函數、指數函數、三角函數等複雜的函數運算，使用近似方程替代。

怎樣查看shader優化後，性能是否提高了呢？

這裏要使用Grapher->App Metris Graph裏的一些監測指標進行優化先後的對比：

EGL（FPS）

GPU General（%Busy）

GPU Shader Processing（%Shaders Busy，%Time Shading Fragment/Vertices）

另外還有一些能夠進行覆蓋測試，好比fps均值比較低，那究竟是CPU仍是GPU形成的瓶頸呢？將DisableDrawElements替換爲false，看FPS和GPU General（%Busy），若是有較大變化則是GPU形成的瓶頸。

最後對GPU瓶頸識別作個總結：

---

歡迎使用WeTest UPA，無需ROOT或接入SDK，認證用戶即享60分鐘使用時長，點擊:http://wetest.qq.com/product/cube 便可下載。

若是使用當中有任何疑問，歡迎聯繫騰訊WeTest企業QQ：2852350015