原文鏈接：https://unity3d.com/cn/learn/tutorials/temas/best-practices/unity-ui-profiling-tools?playlist=30089

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? UGUI性能分析工具

? ? ? ? 有很多用于分析UGUI性能的工具。一些關鍵的工具是：

? ? ? ? 1.Unity Profiler

? ? ? ? 2.Unity Frame Debugger

? ? ? ? 3.XCode的Instrument或者Intel的VTune

? ? ? ? 4.XCode的Frame Debugger或者Intel GPA

? ? ? ? 外部工具提供了對CPU毫秒級（或更高精度的）性能分析方法，同時對shader和drawcall詳細分析。對上述工具設置和使用的說明超出了本指南的范圍。請注意，XCode Frame Debugger和Instrument僅適用于Apple平臺的IL2CPP版本，因此目前只能用于iOS平臺的性能分析。

Unity Profiler

? ? ? ? Unity Profiler的主要用途是執(zhí)行性能比較分析：當Unity Profiler運行的時候進行enabling和disabling的操作，它可以迅速的縮小定位到性能問題最大的UI層級。

? ? ? ? 要分析這個，請查看profiler輸出結(jié)果中的“Canvas.BuildBatch”和“Canvas.SendWillRenderCanvases”。

? ? ? ? 如上文所述，Canvas.BuildBatch是執(zhí)行Canvas的Batch build過程的底層代碼計算量。

? ? ? ? Canvas.SendWillRenderCanvases包含了C#腳本對Canvas組件的willRenderCanvases事件的訂閱的調(diào)用。UGUI的CanvasUpdateRegistry類接收這個事件并且通過它來執(zhí)行前文所描述的rebuild過程。預計所有被標dirty的UI組件都會在這個時候更新他們的Canvas Renderer。

? ? ? ? 注意：為了更容易地看到UI性能的差異，通常建議禁用除了Rendering和Scripts以外所有trace category。這可以通過點擊CPU Usage profiler左側(cè)的名叫trace category旁邊的彩色方塊來完成。

? ? ? ? 還要注意，category可以在CPU profiler中重新排列，可以點擊或者拖拽category向上或者向下來對他們進行重新排列。

Unity Frame Debugger

? ? ? ? Unity Frame Debugger是一個減少UGUI的draw call的實用工具。這個內(nèi)置的工具可以通過Unity Editor中的Window菜單來訪問。當它運行的時候，它將顯示包括UGUI在內(nèi)的所有Unity產(chǎn)生的draw call。

? ? ? ? 特別要注意的是，Unity Frame Debugger在Unity Editor界面就可以更新游戲視口產(chǎn)生的draw call信息，因此可以用來嘗試不同的UI配置而無需進入游戲模式。

? ? ? ? UGUI的drawcall產(chǎn)生的位置取決于Canvas組件上被設置的渲染模式：

? ? ? ? 1.Screen Space – Overlay將出現(xiàn)在Canvas.RenderOverlays組中。

? ? ? ? 2.Screen Space – Camera將出現(xiàn)在Render.TransparentGeometry子項，所選渲染相機的Camera.Render組中。

? ? ? ? 3.World Space將出現(xiàn)在Render.TransparentGeometry子項，每個可以看見Canvas的World Space的攝像機中。

? ? ? ? 如果UI的shader沒有被自定義的shader替換的話，那么所有UI都可以被 “Shader: UI/Default”識別，列出在哪個組和drawcall的細節(jié)。在下圖中請看高亮紅框標注的地方。（圖片見原網(wǎng)頁）

? ? ? ? 在調(diào)整UI的時候觀察Unity Frame Debugger所顯示的信息，這就相對比較簡單的使Canvas中的UI元素最優(yōu)的合成batch。最常見的與設計相關的打斷批次的原因是UI元素間不小心造成的重疊。

? ? ? ? 所有的UGUI組件將它們的幾何體生成成一系列的 quad。然而，很多sprite和text只占用用于顯示它們的 quad的一小部分，留下了大量的剩余空間。這樣的結(jié)果就是，UI開發(fā)者無意中使多個不同的 quad互相覆蓋，它們的texture來自不同的material，不能合成batch。

? ? ? ? 由于UGUI的操作完全在透明隊列中，任何有不能合batch的quad在它上邊的quad必須在不能合batch的quad之前繪制，因此它不能與放在不能合batch的quad上的quad合batch。（翻譯這段我盡力了，但是估計還是不清楚。我講一下大意：就是兩個能合batch的quad中間夾了一個不能合batch的quad，造成這兩個quad也不能合batch了）

? ? ? ? 考慮一個情景，有三個quadA、B、C。假設這三個quad彼此覆蓋，并且A和C使用了相同的Material，B使用了單獨的Material。B不能和A、C合成batch。

? ? ? ? 如果在層級結(jié)構中從上到下的是A、B、C，那么A、C也不能合batch，因為B必須繪制在A的上面，C的下面。然而，如果B被放在可被合batch的quad前面或者后面，那么可以被合batch的quad就能構成batch。B只需要在batch的quad之前或者之后繪制，而不會介入其中。

? ? ? ? 關于這個問題更深入的探討，請看Canvas章節(jié)的Child order部分。

Instruments & VTune

? ? ? ? XCode的Instruments和Intel的VTune各自可以非常深入的分析UGUI的rebuild和Canvas的batch計算在Apple設備和Intel CPU上的性能。方法名稱幾乎和我們之前介紹過的Unity Profiler的標簽完全相同。它們是：

? ? ? ? Canvas::SendWillRenderCanvases是一個C++父類調(diào)用C#中的Canvas.SendWillRenderCanvases方法，并控制 Unity Profiler中該行顯示。它包含了用于進行rebuild過程的代碼，這已經(jīng)在上一章節(jié)詳細介紹了。

? ? ? ? Canvas::UpdateBatches幾乎和Canvas.BuildBatch完全相同，但是增加了Unity Profiler頁面并不包括的代碼引用。它運行上文描述的Canvas的batch建立的實際過程。

? ? ? ? 當通過IL2CPP構建一個Unity APP時，這些工具可以被用于更深入的查看C#中Canvas::SendWillRenderCanvases的編譯。（注意：編譯的方法的名字是近似的。）

? ? ? ? IndexedSet_Sort和CanvasUpdateRegistry_SortLayoutList是用于排序顯示在標為dirty的Layout組件被重新計算之前的一個列表。如上文所述，這包括了計算每個Layout組件的父transform數(shù)量。

? ? ? ? ClipperRegistry.Cull調(diào)用所有IClipRegion接口注冊的實現(xiàn)者。內(nèi)置的實現(xiàn)者包括使用IClipRegion接口的RectMask2D組件。當ClipperRegistry.Cull被調(diào)用時，RectMask2D組件將遍歷在它層級下的所有要被裁剪的UI元素，更新他們的剔除信息。

? ? ? ? 所有可嵌套元素，并要求它們更新其剔除信息。

? ? ? ? Graphic_Rebuild包含所有要顯示的Image，Text或其他Graphic派生的組件所需要的網(wǎng)格的實際計算性能開銷。在這之下有其他一些方法，如Graphic_UpdateGeometry，最值得注意的是Text_OnPopulateMesh。

? ? ? ? -當Best Fit勾選時，Text_OnPopulateMesh通常是一個熱點。這將在本指南后面詳細討論。

? ? ? ? -網(wǎng)格修飾符，比如Shadow_ModifyMesh和Outline_ModifyMesh也在這里運行。通過這些方法可以看到shadow, ? ? ? outline和其他特殊效果組件的計算性能開銷。

Xcode Frame Debugger和Intel GPA

? ? ? ? 底層的Frame Debugger對監(jiān)測UI不同獨立部分的batch性能開銷和UI過度繪制開銷非常重要。在后面章節(jié)我們將詳細的對UI過度繪制進行討論。

Xcode Frame Debugger的使用

? ? ? ? 為了測試一個給定的UI是否過度榨取GPU資源，可以使用Xcode內(nèi)置的GPU診斷工具。首先將項目配置為使用Metal或OpenGLES3，然后進行構建并打開生成的Xcode項目工程。如果Unity在OpenGLES 2下運行，則Xcode不能對Unity進行分析，因此這些技術不能用于較舊的設備。

? ? ? ? 注意：在某些版本的Xcode中，為了使圖形分析器工作，有必要在Build Scheme中選擇適當?shù)腉raphics API。為此，請轉(zhuǎn)到Xcode中的Product菜單，展開Scheme菜單項，然后選擇Edit Scheme ....選擇Run target并轉(zhuǎn)到Options頁面。更改GPU Frame Capture選項來使API適配您的工程。假設Unity工程設置了自動選擇圖形API，則大多數(shù)新一代的iPad將默認選擇Metal。如果有疑問，請啟動項目并查看Xcode中的調(diào)試日志，前面的幾行應該會指出哪個渲染路徑（Metal，GLES3或GLES2）正在被初始化。

? ? ? ? 注意：上述調(diào)整在Xcode 7.4中應該不是必需的，但在Xcode 7.3.1和更舊的版本中仍然偶爾會被發(fā)現(xiàn)是必須的。

? ? ? ? 在iOS設備上構建并運行項目。GPU profiler顯示在Xcode的Navigator邊欄中，點擊FPS條目。（圖請參見原網(wǎng)頁）

? ? ? ? GPU分析器中第一個重要的是屏幕中的三個條目：“Tiler”、“Renderer”、“Device”。這些表示：

? ? ? ? “Tiler”是對GPU生成幾何體（包括在頂點著色器中的花費時間）過程中壓力的衡量。

? ? ? ? ? ? ? ? ——一般來講，“Tiler”值高表明頂點著色器計算過慢或者是繪制的頂點過多。

? ? ? ? “Renderer”是對GPU的像素流水線壓力的衡量。

? ? ? ? ? ? ? ? ——一般來講，“Renderer”值高表明應用程序超過了GPU的最大填充率，或是片段著色器效率低下。

? ? ? ? “Device” 是GPU使用的綜合衡量標準，包括“Tiler”和“Renderer”的性能分析。它通?？梢员缓雎?，因為它大體上跟蹤監(jiān)測“Tiler”和“Renderer”的較高者。

? ? ? ? 有關Xcode GPU? Profiler的更多信息，請參閱此文檔(鏈接見原網(wǎng)頁)。

? ? ? ? Xcode’s Frame Debugger可以通過點擊隱藏在GPU Profiler底部的小“相機”圖標來打開。在下面的屏幕截圖中，通過箭頭和紅色框突出顯示。（截圖見原網(wǎng)頁）

? ? ? ? 暫停一下之后，F(xiàn)rame Debugger的摘要視圖就會出現(xiàn)，如下所示（截圖見原網(wǎng)頁）：

? ? ? ? 在使用默認UI著色器時，假設默認UI著色器沒有被自定義著色器替換，那么由UGUI系統(tǒng)生成的渲染幾何圖形的開銷將顯示在“UI / Default”著色器通道下。在上面的截圖中可以看到這個渲染管線的默認的UI著色器是“UI / Default”。

? ? ? ? UGUI只產(chǎn)生quad，所以頂點著色器不太可能給GPU Tiler流水線產(chǎn)生壓力。出現(xiàn)在這個著色器中的任何問題都應歸結(jié)于填充率問題。

分析分析器結(jié)果

? ? ? ? 在收集分析數(shù)據(jù)之后，可以得出幾個結(jié)論：

? ? ? ? 如果Canvas.BuildBatch或Canvas :: UpdateBatches占用了過多的CPU時間，則可能的問題是單個Canvas上的Canvas Renderer組件數(shù)量過多。請參閱“Canvas”一章的“Splitting Canvases”章節(jié)。

? ? ? ? 如果GPU過度的時間花費在繪制UI上，并且frame debugger表明片段著色器流水線是瓶頸，那么應該是UI的像素填充率超過了GPU的能力，最可能的原因是UI的過渡繪制。請參考Fill-rate, Canvases and input章節(jié)的Remediating fill-rate issues部分。

? ? ? ? 如果Graphic的rebuild占用了過多的CPU，如在Canvas.SendWillRenderCanvases或者Canvas::SendWillRenderCanvases中看到了大量的CPU時間占用，那么就需要進行深層分析，應該與Graphic的rebuil過程中的一些部分有關。

? ? ? ? 如果是大量的WillRenderCanvas花費在IndexedSet_Sort或是CanvasUpdateRegistry_SortLayoutList上，時間花費在對dirty的layout組件列表進行排序，那么就要考慮減少Canvas中的Layout組件數(shù)量。請在Replacing layouts with RectTransforms和Splitting Canvases部分中也許會找到補救措施。

? ? ? ? 如果過多的時間花在Text_OnPopulateMesh上，那么Text網(wǎng)格的生成就是罪魁禍首。請參閱Best Fit和 Disabling Canvas Renderers部分，也許會找到補救措施。并考慮Splitting Canvases中的建議，如果正在重建的大部分文本實際上并未更改其基礎字符串數(shù)據(jù)，text大量rebuild實際上并沒有改變其基礎的字符串數(shù)據(jù)。

? ? ? ? 如果時間花在內(nèi)置的Shadow_ModifyMesh或Outline_ModifyMesh（或任何其他使用的ModifyMesh），則問題在于花費在計算修飾性網(wǎng)格過多的時間。考慮刪除這些組件，并通過靜態(tài)圖像實現(xiàn)其視覺效果。

? ? ? ? 如果Canvas.SendWillRenderCanvas中沒有特定的熱點，或者它看起來每幀都在運行，那么問題可能是動態(tài)元素與靜態(tài)元素混合在一起，致使整個Canvas過于頻繁地重建。參見Splitting Canvases部分。