Unity性能優化（2）-官方教程Diagnosing performance problems using the Profiler window翻譯

時間 2019-11-20

標籤 unity 性能優化官方教程 diagnosing performance problems using profiler window 翻譯欄目系統性能简体版

原文原文鏈接

本文是Unity官方教程，性能優化系列的第二篇《Diagnosing performance problems using the Profiler window》的簡單翻譯。html

簡介

若是遊戲運行緩慢，卡頓，咱們知道遊戲存在性能問題。在咱們嘗試解決問題前，須要先知道引發問題的緣由。不一樣問題須要不一樣的解決方案。若是咱們靠猜想或者其餘項目的經驗去解決問題，那麼咱們可能會浪費不少時間，甚至使得問題更嚴重。工具

這時咱們須要性能分析，性能分析程序測量遊戲運行時的各個方面性能。經過性能分析工具，咱們可以透過遊戲運行的場景表面表現，獲取深刻的信息，經過這些信息，咱們能夠追蹤引發性能問題的緣由。經過性能分析工具，當咱們修改後，咱們能夠測量咱們的修改是否有效，是否修復了性能問題。post

在本文中，咱們將會：性能

-使用Unity的內置性能分析工具Profiler去收集咱們的低性能遊戲的運行時數據。學習

-分析數據，並追蹤引發性能問題的緣由

-分享修復這些特定問題的文章的連接

使得遊戲運行快速平滑是一項平衡性的工做。在獲取咱們想要的結果前，咱們可能須要好幾輪的修改，並測量效果。知道如何使用性能分析工具分析問題意味着咱們可以確認哪裏出了問題，而且理解接下來應該怎麼樣嘗試修改。

開始以前

本文將幫助咱們追蹤定位Unity遊戲運行緩慢，卡頓的問題。若是咱們的遊戲存在其餘問題，如遊戲崩潰或者遊戲的圖形表現不如預期所想，那麼這篇文章可能不會有什麼幫助。若是遊戲存在的問題不在本文討論範圍內，請嘗試在Unity Manual, Unity Forums or Unity Answers尋求答案。

若是咱們還不熟悉Profiler Window的使用，請先閱讀Unity性能優化（1）-官方文檔簡譯。

關於遊戲性能的概要介紹

幀率Frame rate是衡量遊戲性能的基本指標。在遊戲中，一幀相似於動畫中的一幀，它是咱們遊戲繪製到屏幕上的一個靜止畫面。繪製一幀到屏幕上叫作渲染一幀。幀率，或者說幀被渲染的有多快，用FPS衡量（frames per second）。

大多數當前遊戲的目標是幀率60FPS。一般來講，幀率在30FPS以上是能夠接受的，特別是對於不須要快速反應互動的遊戲，例如休閒解密冒險遊戲等。有些項目有特殊的需求，在VR遊戲中，則至少須要90FPS。當幀率下降到30FPS如下時，一般玩家會有很差的體驗；圖形可能不穩定而且感受操做反饋不及時。儘管如此，重要的不只僅是速度，幀率必須也很是穩定。玩家一般對幀率的變化比較敏感，不穩定的幀率一般比低一些可是很穩定的幀率表現更差。

雖然幀率是一個咱們談論遊戲性能的基本標準，可是當咱們嘗試優化咱們的遊戲性能時，對於咱們來講更有用的是渲染一幀須要多少毫秒。這有兩個緣由。首先，這是一個更精確的度量。當咱們嘗試優化性能時，每一毫秒計算有助於咱們的目標。第二，幀率的相對改變在不一樣範圍意味着不一樣的變化。從60到50FPS呈現出的是額外3.3毫秒的運行時間，可是從30到20FPS呈現出的是額外的16.6毫秒的運行時間。在這個例子中，一樣是下降了10FPS，可是渲染一幀上時間的差異是很顯著的。

幀率對於咱們來講能夠用於理解爲渲染一幀必須用多少毫秒之內完成。經過公式 1000/想要達到的幀率。經過這個公式能夠獲得，遊戲要每秒渲染30幀（30FPS），那麼必須在33.3毫秒以內渲染完每一幀。一個60FPS運行的遊戲，必須在16.6毫秒內渲染完每一幀。

要渲染每一幀，Unity必須執行不少不一樣的任務。簡單的說，Unity必須更新遊戲的狀態，獲取遊戲的快照而且把快照畫到屏幕上。有一些任務是在每一幀都執行的，包括讀取用戶輸入，執行腳本，運行光照計算等。除此以外，有許多操做是在一幀執行屢次的，例如物理運算。當全部這些任務都執行的足夠快時，咱們的遊戲纔會有穩定且可接受的幀率。當這些任務執行的不夠快時，渲染一幀將花費太長的時間，而且幀率會所以降低。

知道哪些任務花費了太長的時間執行，對於咱們知道怎樣去解決性能問題是十分關鍵的。一旦咱們知道了哪些任務下降了幀率，咱們就能夠嘗試去優化遊戲的那一部分。這就是爲何性能分析工具這麼關鍵：性能分析工具告訴咱們在一幀中每一個任務花費了多長時間。

錄製分析數據

爲了調查性能問題，咱們必須首先從咱們遊戲性能差的部分錄制分析數據。爲了精確的錄製分析數據，咱們必須生成一個development build版本的遊戲，而且當遊戲在目標硬件上運行時進行分析。

若是還不熟悉怎麼生成development build版本的遊戲，並在目標硬件上運行時進行分析，請查看這篇文章Unity性能優化（1）-官方文檔簡譯。

從咱們遊戲的development build錄製數據

若是還不熟悉怎麼生成development build版本的遊戲，並在目標硬件上運行時進行分析，請查看這篇文章Unity性能優化（1）-官方文檔簡譯。

-在目標設備上生成development build。

-當咱們的遊戲運行到性能出現問題的部分時開始錄製分析。

-一旦咱們錄製的數據包含了性能問題的樣本時，點擊Profiler窗口上部的任意位置暫停遊戲，而且選擇一幀。

-在窗口上半部分，選擇展現出性能問題的那一幀。這多是忽然的低幀數，也可能僅僅是持續的日常的幀數，只是比咱們但願的幀數低。咱們可使用鍵盤的左右箭頭按鍵或者Profiler上部控制欄的先後按鈕移動幀，更好的控制選擇幀。

咱們已經收集到了遊戲性能很差的部分的性能數據，接下來讓咱們學習怎麼去分析這些數據。

分析性能數據

在咱們獲得引發遊戲性能問題的緣由以前，咱們必須先學習怎麼樣去分析顯示在Profiler窗口上的性能數據。咱們知道，當Unity沒法及時的完成渲染一幀所需的所有任務時，會發生幀率的降低。咱們能夠在Profiler窗口中看到哪些任務正在執行，執行任務花費的時間，以及任務執行的順序。這些信息將幫助咱們理解，遊戲的哪部分在渲染幀時花費了太長的時間。

最好是實踐使用Profiler，比嘗試去按照精確的順序學習要好的多。咱們可以本身理解數據的意義是頗有用的，這樣當咱們遇到新問題時就能夠本身調查。或者僅僅是知道在Unity Answers上怎麼查找，也是一個好的開始。

爲了學習怎麼去分析性能，咱們將使用CPU usage profiler做爲例子。當咱們調查幀率問題時，這個多是咱們使用的最多的Profiler了。

The CPU usage profiler

當咱們查看Profiler窗口的上部時，能夠看到完成每幀的任務花費了多少cpu時間。

咱們能夠看見花費的時間用顏色標出了分類。不一樣的顏色表示在渲染操做上花費的時間，物理運算花費的時間等等。Profiler左側代表了哪一種顏色表明哪類任務。

經過下面的截圖咱們能夠看出，這幀中主要的時間花費在渲染操做上。在窗口底部顯示了這幀中全部的cpu時間共消耗85.95毫秒。

層級視圖The Hierarchy view

咱們使用層級視圖去挖掘更深刻的信息，看看在這幀中究竟是哪些任務花費了最多的cpu時間。當咱們選中CPU usage profiler時，這一幀的詳細信息會顯示在Profiler窗口的下部。咱們能夠在Profiler的左下的下拉菜單中選擇層級視圖，這可使咱們查看cpu任務的詳細信息。

層級視圖中，能夠點擊任意的列標題，按照這列信息的值來列排序。例如，點擊Time ms能夠按照函數花費時間排序，點擊Calls能夠按照當前選中幀中函數的執行次數排序。在上面的截圖中，咱們按照時間排序，能夠看到Camera.Render花費了最多的cpu時間。

若是一個函數的名字左邊有箭頭，則能夠點擊展開，查看這個函數調用了哪些其餘函數，而且這些函數是怎樣影響性能的。Self ms表示函數自身的花費時間，Time ms表示這個函數以及它所調用的其餘函數的總時間。

在這個例子中，咱們能夠看到，在Camera.Render，最多的消耗和Shadows.RenderJob函數相關。即便咱們對這個函數還不太瞭解，咱們也已經對性能問題有了不少信息了。咱們知道了問題是和渲染相關的，而且最昂貴的任務是須要處理陰影。

在層級視圖中，另外一個好處是咱們能夠比較遊戲中的每一幀，這樣咱們就能夠理解性能是怎樣隨着時間變化的。使用CPU usage profiler，咱們能夠跟蹤一個函數從幀到幀的cpu消耗。當咱們在層級視圖中點擊函數名字時，CPU usage profiler將在Profiler窗口上部的圖形視圖中高亮顯示這個函數的信息。

舉個例子，若是在層級視圖中點擊了Gfx.WaitForPresent，則和Gfx.WaitForPresent直接相關的渲染數據將會在Profiler的圖形展現中高亮顯示。

時間線視圖The Timeline view

如今咱們使用時間線視圖來學習更多關於咱們的渲染問題的信息。時間線視圖顯示了兩件事：cpu任務的執行順序和那個線程負責哪些任務。咱們能夠Profiler的左下的下拉菜單中選擇時間線視圖（和選擇層級視圖位置相同）。

線程容許不一樣的任務同時執行。當一個線程執行一個任務時，另外的線程能夠執行另外一個徹底不一樣的任務。和Unity的渲染過程相關的線程有三種：主線程，渲染線程和工人線程（worker threads）。瞭解哪一個線程負責哪些任務是頗有用處的：一旦咱們知道了在哪一個線程上的任務執行的最慢，那麼咱們就應該集中努力優化在那個線程上的操做。

咱們能夠縮放時間線視圖，來更仔細的查看單獨的任務。被調用的函數會顯示在調用他的函數的下面。在這個例子中，咱們已經放大了去看組成Shadows.RenderJob任務的其餘獨立任務。咱們看到Shadows.RenderJob調用的函數發生在主線程，也能夠看到工人線程執行和陰影相關的任務。主線程的一個任務WaitingForJob指示出主線程正在等待工人線程完成任務。從這裏，咱們能夠推斷出和陰影相關的渲染操做，在主線程和工人線程，花費了太多的時間。如今和問題相關的信息咱們已經瞭解不少了。

其餘的Profiler

當追蹤幀率相關的性能問題時，儘管CPU usage profiler是最經常使用的Profiler，可是其餘的Profiler也是十分有用的。熟悉他們提供的信息是很好的主意。

請嘗試按照上面的步驟使用其餘的Profiler，使用不一樣的視圖，學習他們每幀提供的信息。例如，嘗試使用渲染Profiler查看渲染數據是怎麼逐幀變化的。

肯定性能問題的緣由

如今咱們已經熟悉怎麼在Profiler窗口中讀取和分析性能數據了，咱們能夠開始查找引發性能問題的緣由了。

排除垂直同步的影響

垂直同步（VSync）用來同步遊戲的幀率和屏幕的刷新率。垂直同步會影響遊戲的幀率，在Profiler窗口中能夠看到影響。若是咱們不是特別肯定問題所在，垂直同步的影響可能看起來像性能問題，因此，在繼續查找問題以前，應該學習怎麼排除垂直同步的影響。

在CPU usage profiler中隱藏垂直同步信息

咱們能夠選擇要在CPU usage profiler中隱藏的信息，這容許咱們和忽略當前問題無關的信息。

按以下步驟在CPU usage profiler中隱藏垂直同步信息：

-選中CPU usage profiler。

-在CPU usage profiler窗口中左側點擊黃色的方框，標記着垂直同步，就能夠隱藏信息。

不理會層級視圖中的垂直同步信息

在CPU usage profile的層級視圖中沒法隱藏垂直同步信息，可是咱們能夠學習他表現出什麼樣子，這樣咱們就能不理會他。

當咱們在層級視圖中看見一個名爲WaitForTargetFPS的函數時，這意味着咱們的遊戲在等待着垂直同步，咱們無須調查這個函數，並安全的忽略他。

關閉垂直同步

垂直同步不是在全部的平臺均可以關閉，許多平臺（例如iOS）是強制開啓的。當咱們在不強制開啓垂直同步的平開上開發時，當咱們分析性能時，能夠爲整個項目關閉垂直同步。經過菜單Edit **> **Project Settings >Quality打開質量設置，在VSync Count的下拉菜單中選擇Don’t Sync。

分析渲染

渲染是常見的引發性能問題的緣由。當咱們嘗試修復一個渲染性能問題以前，很重要的是確認咱們的遊戲是CPU受限仍是GPU受限，由於他們須要用不一樣的方法去解決。

簡單的說，CPU負責決定什麼東西須要被渲染，而GPU負責渲染它。當渲染性能問題是由於CPU花費了太長時間去渲染一幀時，是CPU受限。當渲染性能問題是由於GPU花費了太長時間去渲染一幀時，是GPU受限。

識別遊戲是不是GPU受限

識別是不是GPU受限的最快的方法是使用GPU usage profiler。不幸的是，並非全部的設備和驅動都支持這個Profiler。在判斷是不是GPU受限前，咱們須要先檢查GPU usage profiler在咱們遊戲的目標設備上是否可用。

檢查GPU usage profiler是否可用，遵循下面的步驟：

-在Profiler窗口的左上角點擊Add profiler。

-在下拉菜單中選擇GPU。

若是目標設備不支持，咱們能夠看到右側顯示信息「不支持GPU分析」。

若是沒有看到這個信息，意味着GPU usage profiler支持咱們的目標設備。在咱們的例子中，若是GPU usage profiler可用，則能夠按照以下步驟快速簡單的肯定遊戲是不是GPU受限。

-選中GPU usage profiler。

-查看區域下方中間部分的cpu時間和gpu時間，這裏顯示的是當前選擇的幀的信息。

若是GPU時間大於CPU時間，咱們能夠肯定在遊戲運行的這一幀中是GPU受限。

若是GPU usage profiler不可用，咱們仍然有辦法確認遊戲是不是GPU受限。咱們能夠經過CPU佔用去確認。若是咱們看到CPU在等待GPU完成任務，那麼意味着GPU受限。咱們能夠經過如下步驟：

-選擇CPU usage profiler。

-在窗口下部查看選擇幀的詳細信息。

-選擇層級視圖

-選擇按Time ms列排序

若是函數Gfx.WaitForPresent在CPU usage profiler中消耗的時間最長，這代表cpu在等待gpu。也就是說GPU受限。

解決GPU受限時的渲染問題

若是咱們已經肯定了是GPU受限，那麼請閱讀this article學習解決方案。

識別遊戲是不是CPU受限

若是到這裏尚未識別出遊戲性能問題的緣由，讓咱們如今調查cpu相關的渲染問題。

-選擇CPU usage profiler。

-在Profiler窗口的上部，檢查表明渲染的顏色的數據。咱們能夠點擊顏色方塊隱藏或顯示不一樣種類的信息。

在慢的幀中，若是一大部分時間都花費在渲染上，那麼表示渲染引發了問題。咱們能夠按照下面的步驟進一步挖掘性能信息：

-選擇CPU usage profiler。

-檢查窗口下方選中幀的詳細信息。

-選擇層級視圖。

-點擊Time ms列，把函數按消耗時間排序。

-點擊列表中最上方的函數。

若是選中的函數是一個渲染函數，那麼CPU profiler會高亮渲染部分。若是是這個緣由，那麼意味着是渲染相關的操做引發了遊戲的性能表現，而且在這一幀是CPU受限的。注意函數名和函數是在哪一個線程執行的，這些信息當咱們嘗試修復問題時十分有用。

解決CPU受限時的渲染問題

若是咱們已經肯定了是CPU受限，那麼請閱讀this article學習解決方案。

垃圾回收性能分析

接下來，咱們檢查是不是垃圾回收引發的性能瓶頸。垃圾回收是和unity自動內存管理相關的功能，這多是一個慢的操做。

-點擊選擇CPU usage profiler

-在Profiler窗口，CPU usage profiler左側，能夠點擊有顏色的下方快，控制顯示或者隱藏相關的信息，也能夠拖動他，按照本身的意願排序。在下面的截圖中，咱們隱藏了垃圾回收器意外的全部其餘信息，而且把垃圾回收器拖動到了最上方。

若是在一個慢的幀中，一大部分時間被垃圾回收消耗，這指示着咱們可能存在着垃圾回收過多的問題。咱們能夠更加深刻的分析數據來確認。

-選中CPU usage profiler，查看下方窗口顯示的關於當前選中幀的詳細信息。

-選擇層級視圖

-選擇按照Time ms排序

若是函數GC.Collect()出如今最上方，而且花費了過多的cpu時間，那麼咱們能夠確認垃圾回收是咱們遊戲的問題所在。

解決垃圾回收問題

若是咱們肯定了遊戲存在垃圾回收的問題，請閱讀this article學習解決方案。

物理性能分析

到此爲止，若是咱們排除了渲染問題和垃圾回收問題，那麼讓咱們查看複雜的物理運算是否是問題所在。

-點擊選擇CPU Usage profiler

-在Profiler窗口，CPU usage profiler左側，能夠點擊有顏色的下方快，控制顯示或者隱藏相關的信息，咱們關注物理信息（橙色）

若是在一個慢的幀中，一大部分時間被物理運算消耗，這指示着物理運算可能引發了性能問題。咱們能夠更加深刻的分析數據來確認。

-選中CPU usage profiler，查看下方窗口顯示的關於當前選中幀的詳細信息。

-選擇層級視圖

-選擇按照Time ms排序

-點擊信息列表的最上方，並選中

若是是物理函數，那麼在Profiler上方會高亮物理運算的部分。若是是這種狀況，說明遊戲的性能問題是和物理運算相關的。

解決物理問題

若是肯定了性能問題是物理運算引發的，那麼下面幾個資源將有助於解決問題：

-This page of the Unity Manual,雖然是寫給iOS開發者的，可是其中一些物理優化的提示是對全部Unity遊戲都適用的。

-This tutorial on optimising physics in a Unity game，包含一些有幫助的提示。

-Unite 2012 talk on optimization中講物理的一節，包含了一些常見的物理問題的有用的總結。

腳本運行慢的問題

如今讓咱們檢查，慢或者過於複雜的腳本是不是引發性能問題的緣由。腳本，在這裏，指的是非Unity引擎的代碼。這一般意味着咱們本身寫的腳本，或者是一些咱們在項目中使用的插件的代碼。

-點擊選擇CPU Usage profiler

-在Profiler窗口，CPU usage profiler左側，能夠點擊有顏色的下方快，控制顯示或者隱藏相關的信息，咱們關注腳本信息

若是在一個慢的幀中，一大部分時間被腳本運行消耗，這指示着這些慢的用戶腳本可能引發了性能問題。咱們能夠更加深刻的分析數據來確認。

-選中CPU usage profiler，查看下方窗口顯示的關於當前選中幀的詳細信息。

-選擇層級視圖

-選擇按照Time ms排序

-點擊信息列表的最上方，並選中

若是是用戶腳本的函數，那麼在Profiler上方會高亮腳本的部分。若是是這種狀況，說明遊戲的性能問題是和用戶腳本相關的。

請注意，這裏有一個意外狀況：若是咱們遊戲包含和渲染相關的代碼，例如屏幕後期效果腳本或者OnWillRenderObject 或者 OnPreCull函數中的代碼，Profiler上方可能會高亮渲染數據，而不是腳本數據。

儘管這可能會最初會形成一點困惑，可是在層級視圖和時間線視圖中，一般咱們能夠追蹤到負責任的代碼。

解決腳本慢的問題

若是咱們確認了是腳本引發的性能問題，這裏有一些能夠改進性能的技巧，推薦幾個腳本優化的資源以下：

-This page in the Unity Manual 聚焦移動平臺的腳本優化，可是其中的建議對全部的開發者都是有用的。

-This page in the Unity Manual 包含了一些如何在用戶腳本中避免昂貴的函數調用的建議。

-Unite 2012 talk on optimization 包含一些常見腳本問題的有用的總結。

其餘引發性能問題的緣由

儘管咱們已經討論了四種最多見的引發性能問題的緣由，咱們的遊戲仍然有可能遇到和這些方面不相關的問題。若是是這種狀況，咱們應該遵循上面的方法解決問題：收集數據，使用CPU usage profiler調查信息，找到引發問題的函數。一旦咱們知道了引發問題函數的名字，咱們能夠在Unity Manual, Unity Forums or Unity Answers中查找函數的相關信息，這也許會節省您花費的時間。