🎬 博客主頁:https://xiaoy.blog.csdn.net
🎥 本文由 呆呆敲代碼的小Y 原創,首發于 CSDN🙉
🎄 學習專欄推薦:👑Unity系統學習專欄👑
🌲 游戲制作專欄推薦:👑游戲制作👑
🏅 歡迎點贊 👍 收藏 ?留言 📝 如有錯誤敬請指正!
📆 未來很長,值得我們全力奔赴更美好的生活?
------------------??分割線??-------------------------

- 📢前言
- 🎬Unity 中的 優化
- 🎥Unity性能分析工具
- 📒不同的平臺連接 Unity Profiler 的方法,
- 1??1.連接到Android設備
- 2??2.連接到iOS設備
- 3??3.連接到WebGLS實體
- 📒Profiler視窗決議
- 1??1.Profiler控制元件
- 2??2.時間軸視圖
- 3??3.細分視圖控制元件欄
- 4??4.細分視圖
- 👑性能分析的方法
- 🏳??🌈驗證目標腳本是否出現在場景中
- 🏳??🌈驗證腳本在場景中出現的次數是否正確
- 🏳??🌈驗證事件的正確順序
- 🏳??🌈最小化正在進行的代碼更改
- 🏳??🌈盡量減少內部干擾
- 🏳??🌈盡量減少外部干擾
- 💬總結
- 🚀往期優質文章分享
- 【游戲開發愛好者社區】活動進行中,每周打卡送書籍等禮品,期待你的加入

📢前言
- 談及
優化,作為一個程式員來說,應該都知道是怎么一回事, - 程式優化是指對解決同一問題的幾個不同的程式,進行比較、修改、調整或重新撰寫程式
- 把一般程式變換為陳述句最少、占用記憶體量少、處理速度最快、外部設備分時使用效率最高的最優程式
- 我覺得
優化和性價比其實很像, - 我們在生活中使用最少的錢去買最實用的物品是性價比最高的,
- 同理,如何讓程式在最省性能的情況下去完美執行同一個功能 就可以理解成 優化,
那本篇文章就來簡單講一講Unity中 優化 的概念,
🎬Unity 中的 優化
一般來說,要實作某個功能,我們可以有N種做法,就跟一個數學題有很多種題解一樣,
我們要做的 就是以一種 最優解 的方式用編程做出這道題!
Unity中的優化有很多個方面,包括但不限于:
腳本代碼優化策略、UI常規優化邏輯、物理引擎優化、記憶體管理優化、藝術類資源優化、批處理 和 圖形渲染優化 等
優化前需要問自己的幾個問題:為什么要優化 、優化的目標是什么、哪些部分才需要優化、能夠接受由此帶來的可能的資源消耗(人力、維護、空間等)嗎?
所以在進行相關的優化操作之前,我們首先要學會 性能分析,
🎥Unity性能分析工具
在Unity中有一款自帶的性能分析工具 Unity Profiler
我們可以從選單欄打開查看 Window -> Profiler
也可以按快捷鍵 Ctrl +7 打開


使用這個工具可以讓我們在程式運行時,實時便捷的觀察一些性能所需要的資料,
Unity Profiler內置在Unity編輯器中,在程式運行的時候可以為大量的Unity3D子系統生成使用情況和統計報告
這可以縮小我們為性能瓶頸的搜索范圍提供很大的幫助,
Profiler 可以收集的資料如下:
- CPU消耗量(每個主要子系統)
- 基本和詳細的渲染和GPU資訊
- 運行時記憶體分配和總消耗量
- 音頻源/資料的使用情況
- 物理引擎(2D和3D)的使用情況
- 網路資訊傳遞和活動情況
- 視頻回放的使用情況
- 基本和詳細的用戶界面性能
- 全域光照統計資料
通常有兩種使用Profiler工具的方法:指令注入 和 基準分析
指令注入:
- 通過觀察目標函式呼叫的行為,分配了多少記憶體,來觀察應用程式的內部作業情況,這通常會得到當前執行情況的精準影像,并可能找到問題的根源,
但是,這通常不是一種發現性能問題的高效方法,因為任何的應用程式的性能分析都會代碼額外的性能損耗!
基準分析:
- 我們在分析應用程式中的具體每行代碼之前,應該要對應用程式進行一次系統全面的實際體驗,
- 最好是在應用運行的期間收集一些基本的資料,也可以理解成測驗,
- 這個測驗用例可以是 簡單對應用的玩法試玩幾秒、不同場景的切換等,
- 該操作的主要意義是讓我們體驗到一個大致的感覺,在性能明顯變差的時候能夠及時關注重點,在進一步分析,
我們在進行基準分析的時候通常會對渲染幀率(FPS)、總體記憶體消耗、CPU活動 和 CPU/GPU溫度比較感興趣,
這些指標的手機方式都相對簡單,可以作為性能分析的首先方式,
在進行基本分析之后在進行指令注入才是最好的分析方式,
但是如果想得到真實的資料樣本,則應該在實際的平臺上測驗進行基準分析,
我們不應該通過在Editor上獲取的資料作為真正的游戲資料去處理,
因為在Editor上可能會有一個額外的性能開銷 或者 隱藏某些在真實應用程式中潛在的競爭條件,
有時候在Editor進行分析的時候會比實際應用程式快的多
這是因為在進行序列化資料(音頻、預制體)的時候編輯器早就已經快取過了,所以能比實際應用程式更快的訪問這些資料
所以我們應該將性能分析工具掛載到實際的應用程式中以獲取真實的資料樣本!
通過在Profiler視窗的Connected Player選項,可以選擇分析基于Editor的實體(通過在Editor的Play模式運行) 還是獨立的實體(在編輯器外獨立構建并運行)

不同版本的Unity,這個選項的位置和名稱可能有所不同,不過都在這一塊的選單欄里,仔細找一下就好,
下面來說一下不同的平臺連接 Unity Profiler 的方法,
📒不同的平臺連接 Unity Profiler 的方法,
1??1.連接到Android設備
連接到Android設備的方法有兩種,分別是通過WiFi連接 和 通過ADB工具連接,
第一種:通過WiFi連接到Android設備的方法:
- 確保當前構建應用程式時啟用了Development Build 和Autoconnect Profiler標志
- 將Android 和 電腦 連接到本地WiFi網路
- 通過USB資料線將Android連接到電腦
- 同之前一樣通過Build & Run 選項構建應用程式
- 在Unity編輯器中打開Profiler,在Connected Player 下選擇設備
接下來等待一會之后,應用構建應用程式并通過USB連接推送到Android設備,而Profiler會通過WiFi對Android設備進行連接,
之后就可以看到Profiler視窗正在收集Android設備的分析資料(真是的資料樣本),
第二種:使用ADB工具連接:
- 確保自己的電腦安裝了Unity所需的Android SDK/NDK,沒有的 可以去下載安裝
- 通過USB資料線將Android連接到電腦
- 確保當前構建應用程式時啟用了Development Build 和Autoconnect Profiler標志
- 同之前一樣通過Build & Run 選項構建應用程式
- 在Unity編輯器中打開Profiler,并在Connencted Player 下選擇設備
然后就可以看到Profiler視窗正在收集Android設備的分析資料,
2??2.連接到iOS設備
Profiler也可以連接到運行在iOS設備上的應用實體,可以通過共享WiFi來實作,
不過,還是僅僅當Unity運行在Apple Mac設備上時,才能通過遠程連接到 ios 設備上才可行!
- 確保當前構建應用程式時啟用了Development Build 和Autoconnect Profiler標志
- 將iOS和Mac設備連接到本地WiFi網路,或者連接到專用的WiFi網路
- 通過USB資料線將iOS連接到Mac上
- 同之前一樣通過Build & Run 選項構建應用程式
- 在Unity編輯器中打開Profiler,并在Connencted Player 下選擇設備
然后就可以通過Profiler視窗來收集iOS設備上的資料并分析了!
3??3.連接到WebGLS實體
Profiler可以連接到Unity WebGL實體,
為此,可以在構建WebGL應用程式并從編輯器中運行它時,確保當前構建應用程式時啟用了Development Build 和Autoconnect Profiler標志,
應用程式會通過作業系統默認的瀏覽器運行,我們也可以通過不停的更改默認瀏覽器來達到應用程式在不同瀏覽器中的表現結果,
但是Profiler 連接只能在應用程式首次從Editor中啟動時建立,
之前的Profiler不能連接到已經在瀏覽器中運行的獨立WebGL實體上,
這限制了基準分析WebGL的準確性,因為他有Editor上的一些額外開銷,
📒Profiler視窗決議
接下來介紹一下Profile視窗的一些基本特性,
由于不同版本的Unity這個視窗都會略微有些不同所以本篇文章中使用的是Unity2019版本
后續沒什么大問題的話也都是基于這個版本做的教程介紹,不過問題不大,不同版本核心功能都沒太大的變化,

這是Unity2019的Profiler視窗視圖,暫且分為四個部分進行介紹,
- Profiler控制元件
- 時間軸視圖
- 細分視圖控制元件欄
- 細分視圖
1??1.Profiler控制元件
頂部的選項欄包括多個下拉和開關按鈕,他們可決定要分析什么資料,以及在每個子系統手機資料的深度,
Profiler Modules
默認情況下,Profiler將會對加幾個不同的子系統收集資料,這些子系統覆寫了Unity引擎在時間軸視圖中的大部分子系統,
這些子系統被組織成包含相關資料的各個區域,可以通過Profiler Modules來 添加 或者 移除 額外的區域,
有些Unity的版本也被叫做:Add Profiler

Playmode
Playmode下拉框提供了許多選項,從中可以選擇要分析的目標Unity實體,
可以是當前的編輯器應用程式,也可以是本地獨立運行的應用程式實體,或者遠程設備上的應用程式實體,

Frame
顯示所在幀數/總幀數,
Clear
Clear按鈕清除時間軸視圖中所有的分析資料,
Clear on Play
播放時清除,跟Clear作用一致
Deep Profile
深度分析,普通的分析只記錄常見的Unity回呼方法(如Awake()、Start()、Update())所但會的時間和記憶體分配資訊,
啟用Deep Profile 選項可以用更深層次的指令重新編譯腳本,允許它統計每個呼叫的方法,
這往往會導致運行時的指令注入成本比正常情況下藥大得多,并使用大量的記憶體,因為在運行時收集的是整個呼叫堆疊的資料,
所以說這個選項一般不會開啟,當默認的分析選項無法提供足夠的詳情以指出問題根源時,最好保留這個選項!
Call Stacks
呼叫堆疊,設定這個可以在模塊詳細資訊或者timeline視圖觀察GC的完整堆疊
Load
讀取先前保存的資料,在按下shift按鈕時單擊“Load”,則檔案內容將附加到記憶體中的當前組態檔幀,
Save
將錄制的幀寫入檔案,以(.data)為后綴名,
Save按鈕將當前顯示在時間軸視圖上的所有Profiler資料保存到檔案中,
這種方法一次只能保存300幀資料,要保存更多的資料,需要手動創建新檔案,
2??2.時間軸視圖
時間軸視圖 就是現實運行期間收集的分析資料,將其組織到一系列區域中,
每個區域關注Unity中不同的子系統分析的資料,每個區域都有兩部分,
右邊是分析資料的圖形展示,左邊是一系列用于 啟用/禁用 不同 行為/資料型別 的復選框,
這些復選框可以切換,以改變圖形部分內對應資料型別的可見性,
我們可以在任何時刻惦記時間軸的圖形部分視圖,查看給定幀的更多資訊,
3??3.細分視圖控制元件欄
根據時間軸上選定的區域,細分視圖控制元件欄內將顯示不同 的下拉框和切換按鈕選項,
不同區域提供不同的控制元件,這些選項宣告了什么資訊是可見的 以及如何呈現在細分視圖上,
4??4.細分視圖
根據當前選擇的區域以及細分視圖控制元件欄中選擇的選項,細分視圖中顯示的資訊會有很大的不同,
接下來就來介紹下每個區域以及細分視圖中可用的不同型別的資訊和選項,
CPU使用情況 區域

這個區域顯示CPU所有使用情況和統計資料,
包括Unity大量的子系統,比如 MonoBehaviour組件、攝像機、一些渲染和物理處理、用戶界面、音頻處理、Profiler等,
在細分視圖中,顯示CPU使用情況資料有3種不同的模式:
- Hierarchy 模式
- Raw Hierarchy 模式
- Timeline 模式
Hierarchy 模式顯示大部分呼叫堆疊的呼叫,還會合并類似的資料元素和Unity的全域函式呼叫,
Raw Hierarchy 模式 和 Hierarchy 模式很相似,但是前者會將全域Unity函式呼叫隔離到單獨的條目中,而不是合并到一個大條目中,
Timeline 模式將細分視圖垂直組織到不同的部分,代表運行時的不同執行緒,
例如主執行緒、渲染執行緒和各種后臺作業執行緒,成為Unity Job System,用于加載諸如場景和其他資源等活動,
Timeline 模式提供了一種非常清晰的方式,以明確呼叫堆疊中的哪個方法消耗的時間最多,以及處理時間如何與同一幀中呼叫的其他方法進行比較,
通常 CPU使用情況區域 對于檢測問題最有效果,
GPU使用情況 區域

GPU使用情況 區域 和 CPU使用情況 區域類似,但前者展示的是發生在GPU上的方法呼叫和處理時間,
這個區域中的相關Unity方法呼叫與攝像機、繪制、不同名的和透明的幾何圖形、光照和陰影等有關,
GPU使用情況 區域提供了類似 CPU使用情況 區域的層級資訊,并估計呼叫各種渲染函式所花費的時間,
渲染 區域

渲染 區域 提供了一些常用的渲染統計資料,
細分視圖 中提供了有用的資訊,諸如SetPass呼叫的數量(Draw Call)、渲染到場景的批次總數、通過動態批處理和靜態批處理節省的批次數量和他們的生成方式,以及紋理的記憶體消耗,
記憶體區域

記憶體區域允許在細分視圖時以兩種模式檢視應用程式的記憶體使用情況:
- Simple 模式
- Detailed 模式
Simple 模式只提供子系統記憶體消耗的高層次概覽,
包括Unity底層引擎、Mono框架(由垃圾回收管理的整個堆的大小)、圖形資源、音瞥澩、緩沖區 和 保存Profile收集的資料的記憶體,
Detailed 模式顯示每個GameObject和MonoBehaviours為其Native和Managed表示所消耗的記憶體,
音頻區域

音頻區域是音頻統計資料的預覽,他也可以用于估量音頻系統的CPU消耗,以及音頻和音頻剪輯的總記憶體消耗,
細分視圖中可以洞悉音頻系統的運行方式,以及各種音頻通道和組的用法,
Physics 3D 和 Physics 2D 區域

物理區域有兩個,一個是3D物理,另一個則是2D物理,
這個區域提供不同的物理統計資料,例如Rigidbody、Collider和Contact技術,
網路資訊 和 網路操作 區域

這兩個區域提供了Unity網路系統的資訊,所顯示的資訊取決于應用程式是否使用Unity提供的高級API(HLAPI)或傳輸層API(TLAPI),
HLAPI是一個更易用的系統,用于管理Player和GameObject自動網路同步
而TLAPI知識套接字層級上操作的一個博層,它允許Unity開發者構建自己的網路系統,
視頻區域

如果應用程式使用Unity的VideoPlayer API,那么這個區域對于分析視頻回放行為很有效果,
UI 和 UI詳情 區域

這些區域用于洞察使用Unity內建UI系統的應用程式,
如果使用的是NGUI或者其他第三方的UI系統,那這個區域則無關緊要了,
優化差的UI通常會影響CPU或GPU,因為UI是我們工程首先要面對的第一個子系統,
在很多專案里面UI占得比重還是很大的,所以UI優化也是一個很重要的點,后面會詳細介紹,
全域光照區域

全域光照區域為Unity的全域光照系統提供了大量的優秀細節,
如果應用程式使用GI,就應該參考這個區域,已驗證應用程式是否正常執行,
👑性能分析的方法
上面說了Unity中的性能分析工具Profiler,那就再來說一下進行性能分析的最佳方法,
因為我們在專案中很難的去直接找到需要優化的某個地方,所以就要合理的進行性能分析以得到最佳的結果,
所以說一份合理的任務清單可以讓我們可以更高效率的去檢查出相關問題,
下面是參考 《Unity游戲優化第2版》 這本書中總結的一些適用于絕大多數Unity專案的幾個方法:
- 驗證目標腳本是否出現在場景中
- 驗證腳本在場景中出現的次數是否正確
- 驗證事件的正確順序
- 最小化正在進行的代碼更改
- 盡量減少內部干擾
- 盡量減少外部干擾
下面來簡單介紹一下這幾個方法,方便我們進行排查的時候使用,
🏳??🌈驗證目標腳本是否出現在場景中
這種情況適用于我們期待看到某種效果,但是這種效果卻沒有看到的時候,
出現上面這種情況就很大可能是腳本未出現在場景中,所以我們需要手動排查一下,
可以在 Hierarchy視窗 的文本框中輸入以下內容:
t:<script name>
這樣就可以快速檢索場景中掛載該腳本的GameObject游戲物件,
如果未檢測到我們的腳本,那么很大可能就是未將腳本掛載到場景中,
當然也要注意游戲物件的激活狀態,如果游戲物件是處于非激活狀態的話,腳本還是沒法正常運行的!
🏳??🌈驗證腳本在場景中出現的次數是否正確
如果在 Profiler 查看資料時,觀測到某個 MonoBehaviour 方法執行的次數比預期的多,
或者執行的時間比預期的長,就可能需要再次檢查他在場景中出現的次數是否與預期的一樣多,
同理,如果場景中期望出現的特定數量的組件,但是在段串列中顯示的組件數比這更多(或更少),
那么就需要我們去檢查一下了,最好是撰寫一些 初始化代碼 來防止這種情況再次發生,
🏳??🌈驗證事件的正確順序
Unity 應用主要執行從本地代碼到托管代碼的一系列回呼,
例如我們都知道的 Awake()、Start()、Update() 等,都是最常用的一些回呼方法,
但是有時候我們腳本有很多,我們在某個腳本的 Awake() 中定義了一些東西,做了一些功能,
在另一個腳本中的 Awake() 方法中呼叫了上面那個 Awake() 中定義的某些東西,這樣就會出現一些未知的變化,
原因是我們不能對呼叫的相同型別事件的順序進行細粒度控制,所以有時候就會出現事件順序的問題從而導致專案出現問題,
我們可以在前期盡可能的使用 Awake() 方法來執行某些初始化的方法,在程式運行第一幀就執行,
后期處理的時候就可以在MonoBehaviour組件的 Start() 回呼中進行,因為他總是在所有的 Awake() 執行之后,第一個 Update() 之前被呼叫,
同理,后期更新的時候也可以使用 LateUpdate() 來進行,某些特定情況下除外,
如果很難確定某些事件的執行順序就使用 Debug.Log() 列印的方式去選擇,
🏳??🌈最小化正在進行的代碼更改
為了查找性能問題在專案中進行代碼更改最好謹慎的進行,因為隨著時間的推移,我們進行的更改很容易忘記,
尤其是我們在專案中添加的一些除錯日志等等,后期都要記得及時洗掉哦,
因為Unity的除錯控制臺視窗日志記錄在CPU和記憶體中都很昂貴,會消耗一些不必要的運行開銷,
🏳??🌈盡量減少內部干擾
這里說的 內部干擾,是指Unity引擎的干擾,比如某些功能設定,垂直同步等等,
🏳??🌈盡量減少外部干擾
外部干擾 則是指在運行我們的應用程式時,設備有沒有在后臺運行其他的非常消耗CPU周期或者占用大量記憶體的程式,
從而導致可用記憶體不足干擾測驗,因為它會導致更多的快取丟失,
如果運行效果比預期效果要差很多,則需要仔細檢查系統后臺有沒有進行其它的十分消耗性能的程式,
💬總結
- 本文整理了 Unity中的優化概念 和 Profiler工具的使用方法 以及 性能分析方法,
- 也是將本篇文章作為【Unity優化篇】專欄的第一篇,
- 為以后的 Unity性能優化文章做一個開頭,寫的內容還是很豐富的,
- 后面也會輸出更多的系列學習文章,希望大家多多捧場呀!
🚀往期優質文章分享
- ??Unity零基礎到入門 | 游戲引擎 Unity 從0到1的 系統學習 路線【全面總結-建議收藏】!
- 🧡花一天時間做一個高質量飛機大戰游戲,過萬字Unity完整教程!漂亮學妹看了直呼666!
- 💛通宵一晚做出來的一款類似CS的第一人稱射擊游戲Demo!原來做游戲也不是很難
- 💚重回童年的經典系列??|【貪吃蛇小游戲】近兩萬字完整制作程序+決議+原始碼 【建議收藏學習】
- 🤍重回童年的經典系列??| 【皇室戰爭 】 的 即時戰斗類 復刻游戲Demo!兩萬多字游戲制作程序+決議!
- 💙重回童年的經典系列??| 【橫版街機格斗游戲】類似“恐龍快打” 該如何制作? | 一起來學習 順便送原始碼【建議收藏學習】
- 💜重回童年的經典系列??|【炸彈人小游戲】制作程序+決議 | 收藏起來跟曾經的小伙伴一起夢回童年!
| 🚀 優質專欄分享 🚀 |
- 🎄如果感覺文章看完了不過癮,可以來我的其他 專欄 看一下哦~
- 🎄比如以下幾個專欄:Unity基礎知識學習專欄、Unity游戲制作專欄、Unity實戰類專案 和 演算法學習專欄
- 🎄可以學習更多的關于Unity引擎的相關內容哦!直接點擊下面顏色字體就可以跳轉啦!
【游戲開發愛好者社區】活動進行中,每周打卡送書籍等禮品,期待你的加入
| 🚀 社區活動,重磅來襲 🚀 |
【游戲開發愛好者社區】在本周重磅新推出【每日打卡】活動
🎁 新玩法,獎勵升級!游戲開發愛好者社區:https://bbs.csdn.net/forums/unitygame
社區中心思想:今天你學到了什么?
在社區你可以做些什么: 每日強化知識點,白嫖書籍禮品!
一個人可以走的很快,一群人才能走的更遠!🔥爆C站的游戲開發愛好者社區歡迎您的加入!
更多白嫖活動詳情:https://bbs.csdn.net/forums/unitygame?typeId=19603
溫馨提示: 點擊下面卡片可以獲取更多編程知識,包括各種語言學習資料,上千套PPT模板和各種游戲原始碼素材等等資料,更多內容可自行查看哦!

轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/398521.html
標籤:其他
下一篇:Android修行手冊之Kotlin-【變數和常量】、【基礎型別】、【字串】、【型別轉換】、【函式定義】、【匿名函式】和【可變引數】
