Unity 資源優化方法及移動設備上優化

1、光照烘焙(Baked Lighting)

關閉實時陰影，得到實時陰影的物體將無法被批處理，導致大量的額外繪制調用的開銷。在PC上，你僅能通過單一的即時方向光來得到不錯的動態陰影，但在移動端請用烘焙好的光照，不要用實時陰影。

2、紋理集合(Texture Atlasing)

每個不同材質都會至少導致一個新的繪制調用，你可能會以為一個木頭門和鐵椅子必須使用不同的材質，畢竟它們使用了不同的紋理。但是如果它們能使用同樣的著色器，你可以使用紋理集合來創建一個材質，同時兼容這兩個物體。

一個紋理集合其實就是一個大紋理貼圖，里面包含了各種各樣的小紋理。你可以讓某個材質加載幾個紋理而非讓一堆材質加載一堆紋理，每個物體都能通過不同的紋理映射來加載這個紋理集合上的不同坐標位置的一小片紋理。你也可以在繪制管線中手動生成紋理集，Juan Sebastian的Pro Draw Call Optimizer工具非常有用，它可以生成紋理集，并且在替換新對象時不會搞混資源。

3、動態批處理(Dynamic Batching)

移動非靜態物品也能被動態批處理為單一繪制調用，這對于CPU來說開銷較大，每幀都經過計算，但就優化最終結果來說還是不錯的。不過要注意的是這只對低于900個頂點并有著同樣材質的物體才有用，使用紋理集合來為你的動態物體創建一個單一材質，然后你就能得到簡單的動態批處理了。

4、多細節層次(Level Of Details)

多細節層次組也是一個提升表現的簡單方式。使用多個細節層次的Assets并讓離鏡頭遠的物體采取低細節的幾何圖形進行渲染，Unity能自動在攝像頭和物體之間的距離發生改變時過渡到不同的細節層次。

5、關卡設計(Level Design)

如果你的游戲是讓玩家從一個房間(地區)到另一個房間(地區)，那基本的方式就是讓整個游戲只在一個關卡中，但這樣會導致過高的內存開銷，每一個房間內的物體和材質都會被加載到內存里，即便在當前場景中是不可見的。所以，要將房間放到不同的關卡里，通過代碼設計來分開加載。

6、異步加載(Asynchronous Loading)

當玩家快要接近到加載下一關的關門時，不要同時使用Application.LoadLevel()/現在的版本是SceneManager.LoadScene(),，,這會導致游戲暫停卡頓，即便頭部跟蹤只停了一小會兒，也會讓玩家非常的不適。因此，要采取Application.LoadLevelAsync(),，，

7、靜態批處理(Static Batching)

在一個場景里，可能有一堆靜態幾何圖形，比如墻、椅子、燈光和各種靜止網格(Mesh)，你可以在編輯器里把它們標成靜態，確保將他們標記成靜態光源映射來得到烘焙好的光照貼圖紋理。被標記成靜態的物品會被組成一個網格，而非每繪制一次物品就產生調用。

但靜態批處理有一個關鍵的要求：所有物品必須都有同樣的材質。如果你有木頭材質的靜態墻壁和一個鋼鐵材質的靜態椅子，所有墻壁會被組合成一個網格，消耗一個繪制調用，而椅子則也會有一個網格，占用另一個繪制調用。

8，更新不透明貼圖的壓縮格式為ETC 4bit，因為android市場的手機中的GPU有多種，

每家的GPU支持不同的壓縮格式，但他們都兼容ETC格式，

對于透明貼圖，我們只能選擇RGBA 16bit 或者RGBA 32bit。

9，減少FPS，在ProjectSetting-> Quality中的

VSync Count 參數會影響你的FPS，EveryVBlank相當于FPS=60，EverySecondVBlank = 30；

這兩種情況都不符合游戲的FPS的話，我們需要手動調整FPS，首先關閉垂直同步這個功能，然后在代碼的Awake方法里手動設置FPS（Application.targetFrameRate = 45;）

降低FPS的好處：

1）省電，減少手機發熱的情況；

2）能都穩定游戲FPS，減少出現卡頓的情況。

10，當我們設置了FPS后，再調整下Fixed timestep這個參數，

這個參數在ProjectSetting->Time中，目的是減少物理計算的次數，來提高游戲性能。

11， 盡量少使用Update LateUpdate FixedUpdate，這樣也可以提升性能和節省電量。

多使用事件（不用SendMessage，使用自己寫的，或者C#中的事件委托）。

12， 待機時，調整游戲的FPS為1，節省電量。

13，Instantiate實例化操作

一般情況下，我們不建議項目在運行過程中頻繁地調用 Instantiate 和 Destroy 來創建和銷毀一個GameObject。這種做法不僅可能會造成頻繁且較高的CPU占用，更重要的是，它將造成大量的內存碎片，從而造成越來越多的堆內存分配，進而加速系統垃圾回收操作（Garbage Collection）的到來

14，Draw Call數量、Triangle數量 和 可見蒙皮網格數量

一般來說，Draw Call 數量、Triangle 數量 和 可見蒙皮網格數量 的推薦值需根據平臺的不同而不同。對于 Mobile 低端移動設備來說，建議 Draw Call 數量的主要范圍在 [0,200] 區間內，Triangle 數量保持在 10萬 以下，可見蒙皮網格數量保持在 50 以下。

15，Contacts 數量、Rigidbody 數量 和 碰撞體數量

Contacts 數量為碰撞對（Contact Pair）數量。所謂“碰撞對”，是指當前空間中發生碰撞的物體之間的接觸點，每個 “碰撞對” 均連接兩個相互產生碰撞的物體。一般來說，Contacts 數量越大，則表明碰撞物體的數量越多，即物理系統的CPU開銷越大。

Rigidibody數量 和 碰撞體數量， 其標準值需因運行平臺的不同而不同。對于Mobile移動設備來說，建議 Rigidibody數量 控制在 50 以下，碰撞體數量（靜態碰撞體和動態碰撞體） 控制在 100 以下。

UNITY3d在移動設備上的一些優化資源的方法

1.使用assetbundle，實現資源分離和共享，將內存控制到200m之內，同時也可以實現資源的在線更新

2.頂點數對渲染無論是cpu還是gpu都是壓力最大的貢獻者，降低頂點數到8萬以下，fps穩定到了30幀左右

3.只使用一盞動態光，不是用陰影，不使用光照探頭

粒子系統是cpu上的大頭

4.剪裁粒子系統

5.合并同時出現的粒子系統

6.自己實現輕量級的粒子系統

animator也是一個效率奇差的地方

7.把不需要跟骨骼動畫和動作過渡的地方全部使用animation，控制骨骼數量在30根以下

8.animator出視野不更新

9.刪除無意義的animator

10.animator的初始化很耗時（粒子上能不能盡量不用animator）

11.除主角外都不要跟骨骼運動apply root motion

12.絕對禁止掉那些不帶剛體帶包圍盒的物體（static collider ）運動

NUGI的代碼效率很差，基本上runtime的時候對cpu的貢獻和render不相上下

13每幀遞歸的計算finalalpha改為只有初始化和變動時計算

14去掉法線計算

15不要每幀計算viewsize 和windowsize

16filldrawcall時構建頂點緩存使用array.copy

17.代碼剪裁：使用strip level ，使用.net2.0 subset

18.盡量減少smooth group

19.給美術定一個嚴格的經過科學驗證的美術標準，并在U3D里面配以相應的檢查工具

5G游戲 unity

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。