您遊戲中的幀頻率是不是太低？ 您瞭解為什麼會發生這種現象嗎？ 這是不是由於您同時生成了太多敵人？還是由於某個特定敵人過於消耗系統資源？ 是由於您設定了過多的視覺特效，還是由於您所設計的戰鬥系統所造成的？

放鬆一下，不要一下子就得出結論！

嘗試修復任何效能問題的第一步是收集資訊，這樣您可以做出明智的決策，以確定下一步該怎麼做。 有些人會很自然地說這樣的話“當然慢啦！ 這個關卡有100,000個actor耶！”，但如果您沒有收集適當的資料，您可能就會嘗試在關卡中花費大量時間來降低actor的數量，而沒有嘗試修復真正造成效能表現瓶頸的問題，這些問題可能是完全無關的問題，而且修復起來要容易得多。

明白！ 可是從哪裡開始著手呢？

您要採集的第一份資料是需要了解，您的效能瓶頸到底是出現在遊戲執行緒中、在渲染（描畫）執行緒中、還是出現在GPU中。 要了解具體原因，您需要以非除錯版本來啟用遊戲，然後輸入控制檯命令“stat unit”，從而顯示完成各項任務需要花費多少時間。

您的幀時間指的是生成遊戲中每一幀所需要花費的總體時間。 由於在完成一幀前會同時同步遊戲和描畫執行緒，幀時間常常接近於這些執行緒中的時間。 GPU時間衡量的是顯示卡需要多長時間來渲染場景。 由於GPU時間與幀同步，它的值很可能也類似於幀時間。

如果幀時間非常接近於遊戲時間，那麼您的瓶頸是遊戲執行緒。 如果幀時間非常接近於描畫時間，那麼您的瓶頸是渲染執行緒。 如果兩者都與GPU

本文中，我們僅僅討論如何處理遊戲執行緒中的問題。

哇！現在我知道遊戲的瓶頸是遊戲執行緒啦、 接下來怎麼做？

檢視遊戲執行緒的效能表現的最佳工具是使用統計資料分析程式。 您可以在控制檯輸入“stat startfile”來啟用分析，您可以按下鍵盤上的波浪鍵 (~)來開啟控制檯。 讓我們至少執行10秒左右，這樣可以獲得許多幀間的良好平均值。 更長的分析時間也很好，而且我們可以使用它們來檢測間隙時間較長的問題，但一般不推薦讓分析時間超過30分鐘，因為這樣檔案就太大了。 當您獲得良好的時間樣本後，您可以輸入“stat stopfile”來終止分析。 在路徑Saved/Profiling/UnrealStats下，會有關於您專案資料夾的ue4stats檔案。

好的，我進行了分析。 我該如何開啟這個分析檔案？

如果需要開啟您捕獲的分析檔案，您必須使用UnrealFrontend（虛幻前端），它和UE4Editor位於同一個資料夾，或者您也可以開啟視窗選單中的編輯器的Session Frontend（會話前端）選項卡。 當您打開了會話前端選項卡後，您需要切換到Profiler(分析程式)的小選項卡。 在該處，您可以選擇載入您最近捕獲的ue4stats分析檔案。

我現在打開了分析檔案，我現在應該檢視哪些資料?

很重要的資訊就是位於底部的功能樹。 展開GameThread(遊戲執行緒)專案，然後往下拉，直到您看到超過幾毫秒的“Inc Time”（包含時間）條目，而且其不包含許多子項或不包含任何子項。 同時關注一下“Calls”（呼叫）數列，它顯示了每幀呼叫的統計資料的平均次數。 不要被“CPU Stall”（CPU停滯時間）專案弄糊塗了。 它們顯示的是執行緒等待處理其他內容時所花費的時間，所以不是主要資料，而且僅僅會在幀頻率受限或者遊戲程序不為瓶頸時才會顯示出來。 在下方的分析資料中，我們發現了存在問題的字型緩衝時間。

這是本週在Fortnite中發現的真正問題！ 在本例中，我們顯示了基於相機和重要遊戲物件間距離而變換大小的許多文字。 由於我們在每一幀都對文字調整大小，所以在Slate和虛幻引擎使用者介面系統中的字型快取中充滿了上百個相同的字串。 修復的方法是停止基於距離來動態縮放文字，也可以根據特定間距的閥值來分別變更文字大小。

這個方法對於Fortnite很好用，但我出現的問題不是“字型快取”。

您需要關注一些固定的需要注意的資料。

其中一個重要的專案是FTickFunctionTask。 此專案下是正在更新的每個actor和元件。 一般來說，降低每幀更新的actor和元件的數量都可以很好地加速遊戲。

如果您的遊戲中存在著應永不更新的actor並且您正在使用C++程式碼，您可以將其放置在actor的建構函式中，以完全防止其更新：

PrimaryActorTick.bCanEverTick = false;

如果actor僅在某些時候進行更新，您可以轉而將其放置在建構函式中:

PrimaryActorTick.bCanEverTick = true;

PrimaryActorTick.bStartWithTickEnabled = false;

然後您可以使用SetActorTickEnabled函式來啟用和禁用更新。

另一個要關注的是BlueprintTime（藍圖時間）。 找到這個值的最佳方法是切換到包含（合併）檢視並在列表中找到它。 這樣就可以把所有的BlueprintTime（藍圖時間）條目組合到單一行中。 如果您選擇BlueprintTime（藍圖時間），然後切換回層次檢視，則其會選擇所有藍圖程式碼被執行的位置，這樣能讓您很好地瞭解花費時間進行處理的位置及其位於哪個藍圖中。

另一個常見的問題位置是TickWidgets（更新控制元件）。 如果這個統計資料值很高，這表示您可能同時顯示了太多控制元件，或者這些控制元件上的屬性代理過於複雜。 一些slate屬性，比如可見性，可能會在每幀被呼叫好幾次，這樣它們的值必須要小而且能及時返回。

您是不是在遊戲中有很多骨架網格物體？ SkinnedMeshComp更新時間有時也會消耗很多系統資源。 請嘗試降低顯示在分析檔案中的骨架中的骨骼數量，或者降低動畫藍圖的複雜度。 如果您不需要在無法看到骨架網格物體時更新動畫，請考慮將骨架網格物體元件上的MeshComponentUpdateFlag（網格物體元件更新標識）正確設定為OnlyTickPoseWhenRendered（僅在渲染時更新姿勢）。 請注意，將此標識設定為AnimNotifies（動畫通知）將使得這些網格物體不被渲染時不再對其進行觸發。

實際上，我正在查詢為何遊戲不斷地產生卡頓。

最好的方法是尋找時間軸中出現的頓卡，選擇其周圍的幀，然後將檢視變更為“最大“，而不是“平均“。 這樣會變更所有數字，從而在選擇的幀數範圍中顯示峰值，而不是顯示平均值。

謝謝！