Unity Profiler性能分析全解析

Profiler概述

打開Unity Profiler

1. Window->Analysis->Profiler。

2. Profiler可以確定需要在應用程序中優化什麼，並確認優化產生了您期望的結果。默認情況下，Unity記錄300幀遊戲數據並呈現每一幀的詳細信息。

Profiler Window Layout

• A：Profiler模塊。這是可以在應用程序中配置的所有模塊的列表。使用該區域頂部的下拉菜單從窗口中添加和刪除模塊。

• B：Profiler控件。使用這些控件來設置從哪個設備進行配置，以及應該執行哪種類型的配置Unity，在幀之間導航，並開始記錄數據。
• C: 幀圖表。這個區域包含了每個模塊的圖表。
• D：細節面板模塊。窗口這個區域的信息會根據您選擇的模塊而變化。

Profiler Controls

各個控件功能：

1. AttachToPlay：

• 選擇要對應用程序進行概要分析的目標。
• 默認情況下，這個設置爲Playmode。還可以選擇編輯器來配置Unity編輯器，並顯示編輯器當前使用的資源。
• Unity還可以自動檢測任何運行在網絡上或通過USB連接的設備，並在下拉菜單中顯示它們。在下拉列表中單擊Enter IP，手動輸入要對應用程序進行概要分析的設備的IP地址；

2. Record：

• 啓用此設置以在運行應用程序時記錄活動模塊的分析信息。

• 如果沒有啓用此按鈕，則分析器在運行應用程序時不會收集任何數據。

3. Back Arrow：向後導航一幀。

4. Forward Arrow: 向前導航一幀。

5. Current: 

• 跳轉到最後記錄的幀，使分析器實時顯示收集到的數據。

6. Frame Number：指示當前在分析器中查看的幀號。

7. Clear：清除Profiler窗口中的所有數據。

8. Clear On Play：

• 當下次在“Player Windows”中單擊“播放”或連接到新目標設備時，啓用此設置可從“分析器”窗口中刪除所有數據。

9. Deep Profile：

• 啓用此設置來配置所有c#方法。
• 當啓用此設置時，Unity將檢測添加到所有mono調用中，這樣就可以對的腳本進行更詳細的調查。

10. Call Stack：

• 若要記錄用於腳本化內存分配的調用堆棧，需要單擊此切換。

• 啓用此選項時分析器記錄的幀在GC中有信息。

• 在完整調用堆棧上的Alloc示例將導致託管腳本分配，即使在Deep Profile沒有激活時也是如此。

11. Load：

• 將保存的分析器數據加載到分析器窗口。
• 也可以通過分析器加載Player通過Profiler.logFile API寫出的已經寫出到文件的數據。
• 按住Shift鍵，然後單擊Load按鈕，可以將文件內容附加到當前Profile 幀序列中。

12. Context Menu：

(1) ColorBindMode：啓用此設置可使分析器在其圖形中使用更高的對比度顏色。這增強了紅綠色盲用戶的可見性。

(2) Show Stat for "Current Frame" : 在記錄過程中一直顯示當前幀的對應的圖表上的數據。

(3) Preference：

• 打開Preferences菜單以調整特定於分析器的屬性。

爲了保持較低的開銷，Unity只會每隔五幀重繪一次編輯器UI，這將導致一個稍微有些不太平滑的更新。

Deep Profilling

1. 通常，分析器只分析在profilermarker中顯式包裝的Code Timings。這包括從引擎的本地代碼到腳本代碼的第一次調用堆棧深度，例如MonoBehaviour的啓動、Update或類似的方法。

2. 如果沒有向您自己的代碼中添加更顯式的ProfilerMarker插裝，那麼只能看到作爲腳本代碼子樣例的其他樣例是那些回調到Unity的API(如果該API已插裝)的樣例。大多數帶有性能開銷的API調用都是插裝的Instumented。例如：通過Camera.main API獲取主相機作爲“FindMainCamera”Sample。

3. 當啓用Deep Profile設置，Profiler會剖析腳本代碼的每一部分並且記錄所有的函數調用，包括至少第一次調用堆棧到任何UnityAPI的深度。Unity將分析器工具注入到你所有的腳本方法中來記錄所有的函數調用。這對於理解應用程序代碼在什麼地方花費的時間最多很有用。

4. 深度剖析是資源密集型的，並且會使用大量的內存。因此，在進行概要分析時，應用程序的運行速度會明顯變慢。深度剖析更適合使用簡單腳本的小型遊戲。如果正在使用複雜的腳本代碼，應用程序可能根本無法使用深度剖析，而對於許多較大的應用程序，深度剖析可能會使Unity耗盡內存。

5. 要增加Profiler環緩衝區的大小，可以調整分析器。可以調整正在分析的播放器的maxUsedMemory屬性。如果Deep Profile導致應用程序的幀率下降到無法運行的程度，那麼可以手動地剖析腳本代碼塊，這比深度剖析的開銷要小。

• 使用profilermarker手動添加標記腳本塊所需的工具。
• 標記內容將出現在CPU使用率分析器模塊中。

6. 如果想找出哪些調用堆棧會導致GC。沒有深度剖析的Alloc示例，可以打開分配調用堆棧的集合。在Profiler控件中啓用調用堆棧設置，然後可以選擇GC。在時間軸視圖中Alloc樣例，或者使用Hierarchy視圖中的Show Related Objects面板來查找這些樣例的調用堆棧。

Profiler Modules

各個模塊功能和含義

1. CPU Usage:

• 顯示應用程序在物理、腳本、動畫和垃圾收集等領域花費最多時間的概述。
• 此模塊包含關於應用程序的廣泛概要信息，您可以使用它來決定使用哪些模塊來進一步研究應用程序中更具體的問題。
• 此模塊始終處於活動狀態，即使您關閉它。

2.GPU Usage:

• GPU Usage顯示與圖形處理相關的信息。

• 默認情況下，這個模塊沒有被激活，因爲它有很高的開銷。

3. Rendering:

• 顯示Unity在應用程序中渲染圖形的信息，包括靜態和動態批處理、SetPass和Draw調用、三角形和頂點。

4. Memory：

• 顯示有關Unity如何在應用程序中分配內存的信息。
• 這對於瞭解腳本分配(GC.Alloc)如何導致垃圾收集，或者瞭解應用程序的Asset內存使用隨時間的變化趨勢特別有用。

5. Audio：

• 顯示與應用程序中的音頻相關的信息，例如什麼時候播放多少音頻源，音頻系統需要多少CPU佔用，以及分配給它多少內存。

6. Video:顯示應用程序中與視頻相關的信息。

7. Physics/Physics 2D：顯示物理引擎處理過的應用程序中的物理信息。

8. Network Message，Network Operation兩個模塊已經被棄用。

9. UI：

• 顯示關於Unity如何處理應用程序的UI批處理的信息，包括爲什麼以及如何批處理項目。

10. UI Details：

• 與UI模塊類似，此模塊的圖表添加了有關批處理和頂點計數的數據，以及包含觸發UI更改的用戶輸入事件信息的標記。

11. Global Illumination：

• 顯示關於Unity在應用程序中的全局照明子系統上花費了多少CPU資源的信息。

Profiler Module Overhead分析器模塊開銷

1. 一些分析器模塊有很大的數據收集開銷，比如GPU、UI和音頻分析器模塊。爲了防止這些模塊影響應用程序的性能，可以通過在Profiler模塊下拉菜單中取消對它們的選擇來禁用它們。這將從窗口中刪除模塊，停止分析器收集模塊的數據，並降低分析器的開銷。

2. 這不適用於CPU使用模塊，因爲其他模塊依賴於CPU使用模塊，所以CPU使用模塊即使在不活動時也會收集數據。

3. 若要添加模塊，選擇Profiler模塊下拉菜單並選擇要激活的Profiler。當您從下拉菜單中選擇Profiler模塊時，它將開始收集數據，但是不會顯示它不活動期間的任何數據。

4. 爲了避免GPU Profiler模塊的開銷，它在默認情況下是不活動的。圖形分析器模塊必須在應用程序啓動時激活，以連接到圖形驅動程序。如果你稍後添加它，它對大多數平臺沒有影響，並且剖析器顯示消息“圖形卡驅動程序不支持GPU剖析(或它被禁用，因爲驅動程序bug)”。

5. 如果指示分析器收集數據並通過分析器將數據發送到磁盤。可以通過Profiler. setareaenabled()關閉Profiler模塊，而不是通過Profiler窗口。

6. 一些通過外部IDE調試腳本的設置也可能產生開銷。爲了避免這種開銷和獲得更準確的測量，禁用編輯器附加設置(Edit->首選項->外部工具)。類似地，在配置構建播放器時，打開構建設置並禁用腳本調試以避免這種開銷。

Command Line Arguments

1. 如果從命令行（例如Windows上的命令提示符，MacOS上的終端，LinuxShell或者Android adb）啓動構建的播放器或Unity編輯器，可以傳遞命令行參數來配置一些Profile設置。

Profile Application

構建

1. 構建時必須選中：Development Build以及AutoconnectProfiler，其他選項可選。

2. Deep Profiling Support對於深入分析應用程序的啓動時間非常有用，這將爲構建增加少量開銷。

連接

1. IOS和Android都支持通過網絡的遠端profiling。如果使用了防火牆，需要在出站規則中打開端口：54998-55511。

iOS遠端Profiling

Android遠端Profiling

重新連接

1. 當選擇“Build & Run”時，Unity Editor自動爲應用程序創建了一個ADB通道。如果想要分析另外的應用，或者重啓Adb服務，需要手動配置此通道。

2. 配置方式：打開終端並輸入如下內容。

3. 爲了開啓Android中Deep Profile，需要如下配置：

(1) 開啓Mono Scripting後端。Edit->ProjectSettings->Player->Android->OtherSetting。

(2) 輸入如下命令行：

Audio Profiler module

音頻四個模塊

1. 音頻主模塊分類：

2. 音頻主模塊各個部分的含義：

Simple細節面板

Simple細節面板顯示：

注：AudioClip是一個聲音片段，如：按鈕點擊，相當於是一首音樂；AudioSource是一個源，包含AudioClip，還有其它一些屬性，如：是否靜音等，相當於是一個音樂播放器。

Simple細節面板各個參數含義：

1. TotalAudioSources：場景中AudioSource的數量。

2. PlayingAudioSources：場景中正在破防的Audio Source的數量。

3. PausedAudioSources：場景中暫停播放的Audio Source的數量。

4. Audio Clip Count：場景中Audio Clips的總數量。

5. Audio Voices：項目中使用的Audio Channels（FMOD Channels）的數量。

6. Total Audio CPU：Audio使用的CPU的數量（百分比）。

7. DSP CPU：

• （數字信號處理）項目中通過Mixing, Audio Effects，解壓縮非流送的在內存中壓縮類型的聲音使用的CPU的數量（百分比）。
• 這並不包含CPU所需的Unity在背後解碼的加載類型是解壓並且有負載在背景標誌中檢查的聲音。

8. Streaming CPU：應用中CPU在項目中使用流送Audio的耗費的百分比。

9. Other CPU：不被上面CPU包含的一般的CPU耗費（百分比）。

10. Total Audio Memory：在應用中使用的Audio的內存數量（M）。

11. Streaming File Memory：

• 加載類型爲流式的音頻文件在從磁盤逐步讀取壓縮音頻數據時用於短期緩衝的內存數量。

12. Streaming Decode Memory:

• 加載類型爲流送的Audio文件用來緩存解碼後的採樣流耗費的內存的數量。

13. Sample Sound Memory：

• 加載類型爲解壓加載的音頻文件用於解壓採樣數據的內存量。

• Unity會把音頻系統分配的內存集中起來，並且它會一直增長，直到應用程序的運行時間達到飽和。

• 音頻系統在內部重用分配的內存，這些內存在運行時無法壓縮。

14. Other Memory：音頻系統中各子系統引起的內存開銷。 

Audio Clip的LoadType

1. Decompress On Load：

• 音頻文件將在加載後立即解壓縮。

• 將此選項用於較小的壓縮聲音，以避免動態解壓縮的性能開銷。

• 將vorbis編碼的聲音解壓到負載上要比壓縮它們多佔用大約10倍的內存(對於ADPCM編碼，大約是3.5倍)，因此不要將此選項用於大型文件。

2. Compressed In Memory：

• 保持聲音壓縮在內存中，當播放時才解壓。

• 這個選項有輕微的性能開銷(特別是對於Ogg/Vorbis壓縮文件)，所以只在較大的文件中使用它，因爲在加載時解壓縮會佔用大量的內存。

• 解壓是發生在mixer線程，可以在“DSP CPU”部分的音頻窗格的剖析器窗口中監視。

3. Streaming：

• 動態解碼聲音。該方法使用最少的內存來緩衝從磁盤中增量讀取並動態解碼的壓縮數據。
• 注意：解壓發生在單獨的流線程上，可以在profiler窗口的音頻窗格的“ Steaming CPU”部分監視它的CPU使用情況。
• Streaming clips即使沒有加載音頻數據也有一個大約200KB的重載。

Dtaile View：

詳細視圖包含簡單視圖中的所有信息，另外還包含音頻事件的每幀詳細日誌記錄。

組視圖與通道和組視圖

1. Group顯示了音頻mixer中總線的層次結構。

2. 通道和組視圖將顯示此信息以及有關播放聲音的信息。

3. Reset Play Count On Play：在下次單擊Player窗口中的play或連接到新目標設備時重置plays列中的數字。

細節面板中各個屬性值含義

1. Object：包含AudioSource播放Audio的GameObject。

2. Asset:  對應的GameObject中Audio Source正在播放的音頻Asset。

3. Volume：Audio Source應用到Audio上的音量。這是它整體音量特徵和動態音量特徵的的結合。動態音量適用於與距離相關的衰減曲線。

4. Audibility：Audio播放的實際級別。這是Audio Source的音頻和另外的mixer通道對其施加的其他衰減的總和。

5. Players：Unity播放此音頻的數量。這個信息對調試邏輯錯誤可能很有用，因爲Unity可能不會使用一些音頻文件。

6. 3D： 如果Audio使用動態距離想啊滾衰減和方向平移，則顯示Yes。

6. Paused：如果音頻在此幀中是暫停的，則顯示YES。

7. Muted：如果音頻在此幀中是靜音的，則顯示YES。

8. Virtual:

• 如果Audio由於Max Real Voice Count被掛起，則顯示爲YES。可以在Project Settings中的Audio中進行設置。
• Max Real Voice Count設置Unity同時播放的最大AudioSources的數量。
• 如果這顯示爲True，則Unity有優先級更高的或Audibility的Audio在這一幀被播放。

9. OneShot：

• 如果AudioSource.PlayOneShot()播放這個音頻，則顯示YES。
• 其中第一個參數爲AudioClip，第二個參數爲音量縮放值（0-1）。

10. Looped：如果AudioSource.Play()播放音頻，則顯示YES。

11. Distance：AudioSource到AudioListener之間的距離。

12. MinDist：

• 在AudioSource曲線編輯器上定義的最小距離。

• 這定義了音頻周圍的一個球形區域，小於其值時音量保持在一個恆定的水平。

13. MaxDist：

• 音頻源曲線編輯器上定義的最大距離。
• 這定義了音頻周圍的一個球形區域，大於其值時音量保持在一個恆定的水平。

14. Time：Audio回放的當前相關時間，當音頻回放暫停時，時間不會往前走。

15. Duration：Audio以秒爲單位的長度。

 

CPU Usege Module

圖表類別

1. CPU使用情況探查器模塊的圖表跟蹤在應用程序主線程上花費的時間。

 

CPU Usege圖表中各個模塊及含義

類別	描述
Rendering	應用程序花費多少時間來渲染圖形。
Scripts	應用程序在運行腳本上花費了多少時間。
Physics	應用程序在物理引擎上花費了多少時間。
Animation	應用程序花了多少時間來動畫SkinnedMeshRenderers，GameObject和其他組件。這還包括花在計算Animation和Animator組件的系統上使用的時間
GarbageCollector	應用程序花了多少時間運行垃圾回收器。
VSync垂直同步	應用程序每幀花費多少時間等待targetFrameRate或下一個VBlank與之同步。這取決於QualitySetting.vSyncCount值，目標幀速率或VSync設置，該設置是運行應用程序的平臺的默認或強制最大值。
Global Illunimation	應用程序在光照上花費了多少時間。
UI	應用程序花費多少時間來顯示其UI。
Other	應用程序花在不屬於任何其他類別的代碼上的時間。這包括整個EditorLoop或在Profile中配置播放模式時的性能分析開銷等區域。

模塊詳細信息窗格

當選擇“ CPU Usage”模塊時，其下方的詳細信息窗格將顯示應用程序在選定框架中花費時間的細分。可以將時序數據顯示爲時間軸或層次表；要更改顯示，使用詳細信息窗格中的左上方下拉菜單（默認設置爲時間軸）。可用的三個視圖是：

視圖	功能
TimeLine	顯示特定幀的時間細分，以及該幀長度的時間軸。這是唯一可用於查看除主線程以外的線程上的時序並關聯各個線程之間的時序的視圖模式。
Hierarchy	按時序數據的內部層次結構對其進行分組。此選項以降序列表格顯示應用程序調用的元素，默認情況下，這些元素按花費的時間排序。您還可以按分配的腳本內存量（GC Alloc）或調用次數來排序信息。要更改排序表的列，請單擊表列的標題。
RawHierarchy	以類似於發生計時的調用堆棧的分層結構顯示計時數據。Unity在這種模式下單獨列出每個調用堆棧，而不是像在“ 層次結構”視圖中那樣合併它們。

TimeLine視圖

1. 時間軸視圖是用於CPU Usage模塊的默認視圖。它概述了應用程序中的時間以及時間之間的關係。

2. TimeLine視圖在其各自的子段中沿同一時間軸顯示所有線程的概要分析數據。這與Hierarchy視圖不同，後者僅顯示來自主線程的概要分析數據。

3. 可以使用時間軸視圖來查看不同線程上的活動在並行執行中如何相互關聯。可以查看正在使用不同線程的多少，例如JobSystem的工作線程，如何對這些線程進行排隊，是否有任何線程處於空閒狀態或正在等待另一個線程或一個Job來完成（Wait for X Sample）。

導航和選擇條目

1. 使用鼠標上的滾輪或者Alt+鼠標右鍵來縮放時間軸上的區域。

2. 使用“A”鍵來重置縮放，這樣整個幀時間都可以看到。

3. 使用鼠標中鍵或者Alt+鼠標左鍵來平移時間軸上的區域。

4. 在下面窗口中選中timeline上某個小項，Profiler將會突出顯示其對CPU圖表的貢獻，使得其餘部分變暗；若要取消該條目，直接點擊視圖中其餘地方即可。另外，按F鍵將聚焦選擇的當前樣本。

5. 單擊並水平拖動到任何地方，以在時間軸的某個部分上顯示覆蓋，時間標尺在頂部顯示的時間所涵蓋的覆蓋。

Hierarchy and 和Hierarchy view

1. Hierarchy視圖列出了分析的所有樣本，並根據它們的共享調用堆棧和profilermarker的層次結構將它們分組在一起。

2. 原始的Hierarchy視圖沒有將樣本分組在一起，這使得它非常適合在粒度級別上查看樣本。

3. 還可以使用Thread下拉菜單選擇一個特定的線程，如MainThread或RenderThread，以便在這些視圖中進行檢查。

4. 這兩個視圖都在每一行旁邊顯示了層次結構中每個項目的以下詳細信息:

(1) Total：

• Unity在一個特定函數上花費的總時間，以百分比表示。

(2) Self：

• Unity在一個特定函數上花費的總時間百分比，不包括Unity調用子函數的時間。

(3) Calls：

• 在這一幀中對這個函數的調用次數。

• 在Raw層次結構視圖中，此列中的值始終爲1，因爲分析器不會合並樣本的層次結構。

(4) GC Alloc:

• 當前幀中分配了多少腳本堆內存?
• 腳本堆內存由垃圾收集器管理。
• 每當Unity調用GC.Collect()或者有一個腳本堆內存分配不適合當前堆內存的大小，垃圾收集器將會被觸發，它標記所有的不再引用它們的分配並收集它們。
• 當在堆上分配更多內存時，Unity會更頻繁地運行垃圾收集器。隨着託管堆的增長，Unity需要更長的時間來標記和收集內存。因此，在應用程序運行時，應該將GC Alloc值保持爲0，以防止垃圾收集器影響幀速率，並保持總體堆大小較小。

(5) Time(ms)：

• Unity花費在一個特定函數上的時間。
• 如果應用程序使用作業系統或者多線程呈現，則此消息可能會導致誤導，因爲它只包含Unity花費在當前選擇的線程上的時間。
• 如果要更改線程，選擇“層次結構”窗格頂部的“Thread”下拉列表。

(6) Self(ms)：

• Unity花費在一個特定函數上的總時間(以毫秒爲單位)，不包括Unity調用子函數的時間。

(7) Warning：

• 由警告圖標指示，這將顯示應用程序在當前幀中觸發警告的次數。

5. 要獲取關於應用程序在何處調用和使用pfofilerd函數，選擇“模塊詳細信息”窗格右上角的“詳細信息”下拉菜單，然後選擇“顯示相關對象”或“顯示調用視圖”。

Show Related Objects面板

 

Show Calls panel

1. Show Calls 視圖顯示所選擇的Samples是從哪裏被調用的，以及它調用的其他函數。

2. 另外，可以在詳細信息模塊右上角頂部啓用或者禁用Collapse Editor Only Samples。這個Collapses All Samples在Player循環中僅僅在安全檢查時發生。當Samples被摺疊時，它們的GC.Alloc值對附加的Samples的GC.Alloc值沒有影響。

Common samples

除了腳本代碼生成的樣例之外，Unity還提供了大量的樣例，這些樣例可以瞭解應用程序中哪些部分佔用了時間。下表解釋了一些更常見的樣例的作用。

1. Main thread基本樣例：主線程基本示例明確區分了花在應用程序上的時間和花在編輯器和分析器活動上的時間。記錄器還可以使用這些樣本來獲取主線程上幀的計時。

(1) PlayerLoop：

• 來自應用程序主循環的任何示例的根。

• 當玩家在編輯器中以活動播放模式運行時，目標是編輯器而不是Playmode，此示例將嵌套在EditorLoop下。

(2) EditorLoop：

• 來自編輯器主循環的任何示例的根。
• 這僅在編輯器中配置一個播放器時出現。
• 當使用剖析器定位Playmode時，這個例子顯示了渲染和運行包含播放器的編輯器花費了多少幀時間。
• 如果希望看到編輯器在這段時間內做了什麼，將目標切換到編輯器。

(3) Profiler.CollectEditorStats

• 與爲不同的活動分析器模塊收集統計信息相關的任何示例的根。
• 要關閉特定模塊，請關閉它們的圖表或調用Profiler.SetAreaEnabled()

2. Script update示例：除非使用的是作業系統，否則大部分腳本代碼是嵌套在下面的示例中:

Sample	Function
Update.ScriptRunBehaviourUpdate	This sample includes calls to MonoBehaviour.Update and processing of coroutines.
BehaviourUpdate	This sample processes all Update() methods.
CoroutinesDelayedCalls	Contains coroutine samples after their first yield.
PreLateUpdate.ScriptRunBehaviourLateUpdate	This sample processes all LateUpdate() methods.
FixedBehaviourUpdate	This sample processes all FixedUpdate() methods.

3. Rendering and VSync 示例：

這些示例顯示了CPU在哪些地方花費時間爲GPU處理數據，或者它可能在哪些地方等待GPU完成。如果GPU分析器不可用，或者它增加了太多的開銷，工具欄不會顯示這些信息。這些示例可以讓您瞭解應用程序是cpu受限還是GPU受限。

Sample	Function
WaitForTargetFPS	The time your application spends waiting for the targeted FPS that Application.targetFrameRate specifies. If this sample is a sub-sample of Gfx.WaitForPresent, it represents the amount of time your application spends waiting for the VSync configured in QualitySettings.vSyncCount. Note: The Editor doesn’t VSync on the GPU and instead uses WaitForTargetFPS to simulate the delay for VSync. Some platforms, in particular Android and iOS, enforce VSync or have a default frame rate cap of 30 or 60.
Gfx.ProcessCommands	Contains all processing of the rendering commands on the render thread. Some of that time might be spent waiting for VSync or new commands from the main thread, which you can see from it’s child sample Gfx.WaitForPresent.
Gfx.WaitForCommands	Indicates that the render thread is ready for new commands and might indicate a bottle neck on the main thread.
Gfx.PresentFrame	Indicates the time your application spends waiting for the GPU to render and present the frame, which might include waiting for VSync. A WaitForTargetFPS sample on the main thread shows how much of that time is spent waiting for VSync.
Gfx.WaitForPresent	Indicates that the main thread is ready to start rendering the next frame, but the render thread has not finished waiting on the GPU to present the frame. This might indicate that your application is GPU-bound. To see what the render thread is simultaneously spending time on, check the Timeline view. If the render thread spends time in Camera.Render, your application is CPU-bound and might be spending too much time sending draw calls or textures to the GPU. If the render thread spends time in Gfx.PresentFrame, your game is GPU-bound or it might be waiting for VSync on the GPU. A WaitForTargetFPS sub-sample of GFX.WaitForPresent indicates the portion of the Present phase that your application spends waiting for VSync. The Present phase is the portion of time between Unity instructing the graphics API to swap the buffers, to the time that this operation is completed
Gfx.WaitForRenderThread	Indicates that the main thread is waiting for the render thread to process all the commands currently in its command stream. This sample only occurs in multithreaded rendering.

4. Multi threading示例：

These samples do not consume CPU cycles but instead highlight information that relates to threading and the JobSystem. When you see these samples, use the Timeline view to check what’s happening on other threads at the same time.

Sample	Function
Idle	Any time that the JobSystem does not utilize a Worker Thread, it emits an Idle sample. Small gaps between Idle samples usually happen when the JobSystem wakes them up, for example to schedule new Jobs. Longer gaps indicate a native Job that has not been instrumented.
Semaphore.WaitForSignal	This thread is waiting for something to finish on another thread. To find the thread it is waiting for, check the Timeline view for any samples that ended shortly before this one.
WaitForJobGroupID	A Sync Fence on a JobHandle was triggered. This might lead to work stealing, which happens when a worker finishes its work and then looks at other workers’ jobs to complete. These show up as job samples executed under this sample. Jobs that were “stolen” are not necessarily the jobs that were being waited on.

5. Physics示例：

The following table outlines some of the high-level physics Profiler samples. FixedUpdate() calls all of these samples.

Sample		Function
Physics.Simulate		Updates the state of the current physics by instructing the physics engine to run its simulation.
Physics.Processing		Processes all non-cloth physics jobs. Expand this sample to show the low-level detail of the work done internally in the physics engine.
Physics.ProcessingCloth		Processes all cloth physics jobs. Expand this sample to show the low-level detail of the work done internally in the physics engine.
Physics.FetchResults		Collects the results of the physics simulation from the physics engine.
Physics.UpdateBodies		Updates all the physics bodies’ positions and rotations. This sample also contains messages that communicate when these updates are sent.
Physics.ProcessReports		Runs once the physics FixedUpdate ends. Processes the various stages of responding to the results of the simulation. Contacts, joint  breaks and triggers update and message in this sample. There are four distinct sub stages:
	Physics.TriggerEnterExits	Processes OnTriggerEnter and OnTriggerExit events.
	Physics.TriggerStays	Processes OnTriggerStay events.
	Physics.Contacts	Processes OnCollisionEnter, OnCollisionExit, and OnCollisionStay events.
	Physics.JointBreaks	Processes updates and messages relating to broken joints.
Physics.UpdateCloth		Contains updates relating to cloth and their Skinned Meshes.
Physics.Interpolation		Manages the interpolation of positions and rotations for all the physics objects.

Show Related Objects面板

 

1. ShowRelatedObjects視圖顯示與Profiler示例中相關的UnityEngine.Objects的列表。

2. 如果在編輯器中Profile，Unity將會通過實例ID報告這些對象，並在Profiler窗口將他們解析爲一個名稱。當配置一個已構建的播放器，或從磁盤加載捕獲時，這些名稱不會出現，而是顯示爲“N/A”。

3. 對於GC.Alloc示例中，顯示了一個“N/A”項列表，如果在選擇GC時，在啓用調用堆棧設置的編輯器中配置應用程序,在這個視圖中，將顯示選擇的已分配腳本對象的調用堆棧，即使沒有啓用深度分析設置。

Performance warnings

 

Profiler可以檢測一些在性能關鍵的上下文中應該避免的特定調用：

• Rigidbody.SetKinematic: 爲供給重建非凸網格對撞機。
• Animation.DestroyAnimationClip: 觸發重建內部狀態。
• Animation.AddClip: triggers RebuildInternalState
• Animation.RemoveClip: triggers RebuildInternalState
• Animation.Clone: triggers RebuildInternalState
• Animation.Deactivate: triggers RebuildInternalState

Allocation call stacks

1. 默認情況下，在GC.Alloc Samples上分配調用堆棧是禁用的，因爲他們會導致多幀延遲擾亂應用程序。

2. 啓用方法：導航到Profiler窗口的工具欄，並選擇Call stack按鈕。

3. 無論是在編輯器中配置文件還是在正在運行的播放器中配置文件，都可以使用此功能。在打開這個選項後的幀中，GC.Alloc Samples包含它們的callstack。在層次結構視圖和時間軸視圖中，每個腳本堆分配都顯示爲一個GC.Alloc Samples。在時間軸視圖中，它的顏色爲明亮的洋紅色。

4. 或者，可以在層次結構或原始層次結構視圖中查看調用堆棧。設置Details視圖以顯示相關對象。因爲GC.Alloc樣本沒有名字，它們在這個面板中顯示爲N/A。當您選擇一個N/A對象時，分析器會在details視圖的下半部分顯示調用堆棧。

Editor only samples

一些Samples只有在編輯器中進行概要分析時纔會出現。這包括安全檢查，校驗一致性，驗證對象設置，銷燬檢查和Prefab-related激活，所有上述這些Samples都不存在於播放器中。

默認情況下，只編輯的示例在Hierarchy視圖中摺疊，並命名爲EditorOnly [SampleName]。雖然它們可能會導致垃圾收集分配，但如果他們被摺疊，將不會對GC.Alloc造成影響。

要更改默認行爲，單擊“模塊詳細信息”窗格右上角的上下文菜單，並禁用“Collapse EditorOnly樣例”設置。當您這樣做時，您可以擴展Samples並貢獻它的GC.Alloc值。

Global Illumination

圖表分類：

細節面板

GPU Usage Profiler

1. 模塊顯示應用程序在GPU中花費的時間。你只能在播放模式中使用GPU分析器，或者在應用程序的構建中使用。不能使用它來配置編輯器。

GPU Profiler支持列表

圖表分類

模塊細節面板

Momory Profiler Module

1. 有兩種內存分析方法：

(1) Memory Profiler Module：

• 這是Profiler窗口中的一個內置模塊，它爲您提供關於應用程序在何處使用內存的基本信息。

(2) Memory Profiler Package：

• 這是一個單獨的包，可以將其添加到項目中。
• 它爲Unity編輯器增加了一個額外的內存分析器窗口，你可以用它來更詳細地分析你的應用程序的內存使用情況。
• 可以存儲和比較快照來更容易地找到內存泄漏，或者查看內存佈局來找到內存碎片問題。
• https://docs.unity3d.com/Packages/[email protected]/manual/index.html

Momory Profiler概述

1. 內存分析器模塊可視化表示應用程序中分配的總內存的計數器。可以使用內存模塊查看諸如加載對象的數量以及它們在每個類別中佔用的總內存等信息。還可以看到每個Profiler幀的GC分配數量。

2. 要獲得更精確的數字和應用程序的內存使用情況，請通過“附加到播放器”菜單將分析器連接到正在運行的播放器。這允許您查看目標設備上的實際使用情況。

圖表分類

Module details pane

Simple view

Simple View顯示了在每一幀上Unity實時有多少內存被使用的概述。Unity爲分配預留了內存池，以避免過於頻繁地向操作系統請求內存。這將顯示爲一個保留的數量，以及它使用的數量。

1. Total：下面區域的所有累計值。

2. Unity:

• Unity本地代碼中的內存分配量
• 由本地內存管理器系統跟蹤，並根據它們的類型、源和平臺特定的分配模式在內存池中分配。

3. Mono：

• 託管代碼使用的總堆大小和使用的堆大小。這個內存被垃圾回收。

3. Gfx Driver：

• 驅動程序在紋理、渲染目標、着色器和網格數據上使用的估計內存量。

4. Audio：音頻系統的估計內存使用量

5. Video：視頻系統的估計內存使用量

6. Profiler：分析器使用的總內存

7. 分析器還列出了一些最常見的Assets和遊戲對象類型的內存統計信息。這些統計數據包括計數(在正斜槓之前)和使用的內存。在這個列表中，Total Object Count顯示應用程序創建的本地遊戲對象的總數。如果這個數字隨着時間的推移而增加，你的應用程序將創建遊戲對象，而不會銷燬它們。

Detail View

可以使用詳細視圖獲取應用程序當前狀態的快照。單擊Take Sample按鈕以捕獲當前目標的詳細內存使用情況。分析器需要花費大量的時間來獲取這些數據，因此詳細視圖不會提供實時的詳細信息。Profiler獲取樣本後，Profiler窗口將顯示一個樹視圖，可以在其中更詳細地查看應用程序的內存使用情況。

1. 開啓“Gather Object references”設置將會手機關於在快照時引用對象的內容的信息，信息顯示在窗口的右側窗格中。

2. 在樹視圖中，使用內存的對象分爲以下幾類：

• Other: Objects that are neither assets, GameObjects, or components. Information such as used memory Unity uses for different systems can be found here.
• Not Saved: Objects marked as DontSave
• Builtin Resources: Unity Editor resources or Unity default resources, such as Shaders you have added to the Always Included Shaders list of the Graphics settings.
• Assets: Assets referenced from user or native code
• SceneMemory: Objects and attached components

Note: In the Other category, memory reported under System.ExecutableAndDlls is read-only memory. The operating system might discard these pages as needed and later reload them from the file system. This generates lower memory usage, and usually does not directly contribute to the operating system’s decision to close your application if it uses too much memory. Some of these pages might also be shared with other applications that are using the same frameworks.

Rendering Profiler

1. 渲染分析器顯示渲染統計數據。

2. 與Game創口的Static數據很相近。

Video Profiler Module

1. Video Profiler模塊顯示關於應用程序中視頻使用的資源的信息，如內存、緩衝和視頻剪輯的數量。可以使用它來確定應用程序在選定平臺上回放和緩衝視頻的效率。也可以使用CPU使用率分析器模塊來評估Unity在視頻上花費的時間。

圖表種類：

模塊細節面板

UI And UI Details Profiler

1. UI和UI Detail模塊提供關於Unity花費多少時間和資源在應用程序中佈局和呈現用戶界面的信息。

2. 可以使用這個模塊理解Unity如何處理應用程序中的UI批處理，包括爲什麼以及如何批處理對象。

3. 還可以使用此模塊來查找UI的哪個部分導致了緩慢的性能，或者在清除時間軸時預覽UI。

圖表分類

Module Details Pane

1. Object：應用程序在分析期間使用的UI畫布列表。雙擊一行以突出顯示場景中匹配的對象。

2. Self Batch Count：Unity爲canvas生成了多個個batches。

3. Cumulative Batch Count：累積的Batch數目。Unity爲Canves和所有它嵌套的Canvase生成了多少個Batches。

4. Self Vertex Count：Canvas渲染了多少個頂點。

5. Cumulative Batch Count：Canvas樂基渲染了多少個頂點。

6. Batch Breaking Reason：

• 爲什麼Unity割裂批處理batch。有些時候Unity可能無法將對象批處理在一起。常見原因如下：
• 沒有與Canvas共面。批處理需要對象的rect變換和Canvas共面。
• CanvasInjectionIndex：存在一個CanvasGroup組件，並強制執行一個新的批處理，比如在其他的組件上顯示一個組合框的下拉列表。
• 不同的材質實例，矩形裁剪，紋理或A8TexrtureUsage。其中Unity只能批量使用相同的材質，masking，紋理和紋理通道使用的對象。

7. GameObjectCount：Batch中有多少個GameObject。

7. GameObjects：批處理中的GameObject列表。當您從列表中選擇一個UI對象時，它的預覽將出現在窗格的右側。在預覽上方，工具欄中有以下選項：

(1) Detach：選擇此按鈕可在單獨的窗口中打開UI畫布。要重新安裝窗口，請關閉它。

(2) Preview Background：使用下拉菜單改變預覽背景的顏色。你可以從棋盤格、黑色或白色中選擇。如果你的UI有一個特別亮或暗的配色方案，這是非常有用的。

(3) 預覽類型：使用下拉菜單從標準、透支或複合透支中進行選擇。

Physics Profiler Module

圖表分類

1. Active Dynamic：

• 激活的非運動學剛體部件的數量。一個激活的剛體是不休眠的。

2. Active Kinematic：

• 激活的動力學剛體組件的的數量

• 當在一幀中調用MovePosition或MoveRotation時，運動學剛體處於激活狀態，並在下一幀中保持活動狀態。

• Unity可能每幀處理具有joints的運動學剛體組件多次，這有助於值的呈現。

3. Static Colliders：

• 沒有剛體組件附加到的GameObject或者它們的父GameObject的GameObject上面的Collider組件的數量。
• 具有Rigidbody組件的GameObjects或parent GameObjects上的碰撞器組件不算作靜態碰撞器。這些被稱爲複合碰撞器。
• 複合碰撞器以一種方便的方式來安排一個物體的多個碰撞器，而不是將所有的碰撞器都放在與剛體組件相同的GameObject上。

4. Rigidbody：

• 由物理引擎處理的剛體組件的數量，與組件的休眠狀態無關。

5. Trigger Overlaps：

• 重疊觸發器的數量(成對計數)。

6. Active Constraints：

• 物理引擎處理的原始約束的數量。約束被用作關節和碰撞響應的構件。

• 例如，限制一個可配置關節的線性或旋轉自由度涉及到每個約束的基本約束。

7. Contacts：

• 場景中所有碰撞器之間的接觸對的總數，包括觸發重疊對的數量。

• 觸點是一對相互接觸或重疊的碰撞體。

• 當它們之間的距離低於某個用戶可配置的限制時，Unity爲每一對碰撞器創建接觸對。因此，您可能會看到爲剛體組件生成的接觸，這些組件還沒有接觸或重疊。

注意：剖析器中顯示的數字可能與場景中包含物理組件的GameObjects的確切數量不一致。這是因爲Unity以不同的速率處理一些物理組件，這取決於其他組件對它的影響(例如，一個附加的聯合組件)。要計算帶有特定物理組件的GameObjects的確切數量，必須使用FindObjectsOfType函數編寫一個自定義腳本。物理分析器模塊不顯示睡眠剛體組件的數量。這些組件不參與物理引擎，因此不被分析器處理。

使用物理分析器來理解性能問題

1. 物理模擬運行在從主邏輯更新循環的一個獨立的固定評率更新週期，並只能通過Time.fixedDeltaTime每次調用來向前。這和Update和FixedUpdate之間的不同很相似。

2D Physics Profiler Module

圖表種類：

模塊細節面板