會(huì)頻繁更新 主要給自己看

性能優(yōu)化總結(jié):成本和分析

工具:Memory Profiler/Unity Editor Profiler/Frame Debugger/RenderDoc/ VS / ADB /Instruments / GPA /Inter VTune Profiler /Unity Bulid Report Tool

優(yōu)化大綱:

1:CPU

(1)渲染模塊

簡(jiǎn)化資源:

• Back Face Culling(把看不到的三角面剔除)
• Facing Culling(把看不到的區(qū)域剔除)
• Cull Distance Volume（基于距離的Culling）
• Landscape Culling Settings（地形剪裁Culling）
• LOD & HLOD （數(shù)據(jù)剪裁Culling）
• Streaming System（數(shù)據(jù)占用Culling）
• Precomputed Visibility Volume (離線Culling緩解實(shí)時(shí)Culling的壓力)

降低DrawCall:

• 靜/動(dòng)批處理
• 圖集:把UI的圖片打成圖集 減少DrawCall 但相應(yīng)的可能會(huì)導(dǎo)致資源都大 加載的時(shí)候可能會(huì)加載多余的資源到內(nèi)存但又不使用 解決辦法就是根據(jù)功能去分類打圖集 并且圖集要進(jìn)行合理安排 像背景這種大圖片就不需要打進(jìn)去了 盡量使得合圖盡量減少空白 并且保持合圖不會(huì)特別大
• GPU Instance技術(shù)

動(dòng)態(tài)批處理要求

• 頂點(diǎn)屬性的最大限制為900，而且未來有可能會(huì)變。不要依賴這個(gè)數(shù)據(jù)。
• 一般來說，那么所有對(duì)象都必須需要使用同一個(gè)縮放尺度（可以是(1, 1, 1)、(1, 2, 3)、(1.5, 1.4, 1.3)等等，但必須都一樣）。但如果是非統(tǒng)一縮放（即每個(gè)維度的縮放尺度不一樣，例如(1, 2, 1)），那么如果所有的物體都使用不同的非統(tǒng)一縮放也是可以批處理的。這個(gè)要求很怪異，為什么批處理會(huì)和縮放有關(guān)呢？這和Unity背后的技術(shù)有關(guān)系，有興趣的可以自行谷歌，比如這里。
• 使用lightmap的物體不會(huì)批處理。多passes的shader會(huì)中斷批處理。接受實(shí)時(shí)陰影的物體也不會(huì)批處理。

合批常遇問題解決:

• Mask影響合批 如果遮罩區(qū)域只是矩形的話直接替換成Rect2DMask 如果還是想用不規(guī)則圖片做遮罩的話直接重寫mask

(2)UI模塊

• 不需要Graphic Raycaster的關(guān)閉掉
• 動(dòng)靜分離
• 提高填充率:(1)把透明圖片按鈕用其他方式替換掉 (2)把圖片的空白透明的地方干掉
• 全屏界面時(shí)關(guān)閉3D渲染(把3D場(chǎng)景的攝像機(jī)關(guān)閉)和畫布
• 停止在界面外的UI渲染
• 變化的UI會(huì)影響合批,建議:根據(jù)更新頻率把不同的UI分布到不同的畫布上 Z軸保持一致 相同材質(zhì)和使用矩形裁剪(mask裁剪會(huì)影響合批 且因?yàn)槠涫悄０鍦y(cè)試的方式裁剪導(dǎo)致像圓形頭像這種裁剪完會(huì)有鋸齒)

(3):加載模塊

根據(jù)不同的資源特點(diǎn)使用不同的加載方式 比如:緩存 流式加載 異步加載 多線程等

• Resources會(huì)影響啟動(dòng)速度 因?yàn)槲募臉?biāo)題會(huì)變成所有資源的索引表 這個(gè)索引表會(huì)在游戲開始后載入內(nèi)存 以更有效的方式進(jìn)行資源管理和卸載 比如熱更新常用的assetbundle資源管理

(4):代碼效率

對(duì)耗時(shí)的代碼進(jìn)行優(yōu)化

• 更改參數(shù)或者替換算法來降低算法復(fù)雜度 比如:排序算法 查找算法等
• 給外部材質(zhì)傳遞參數(shù)的時(shí)候我們往往會(huì)直接根據(jù)字符串名直接傳遞 但其內(nèi)部其實(shí)是ID 頻繁調(diào)用會(huì)導(dǎo)致多次轉(zhuǎn)換 所以我們會(huì)需要先把字符串轉(zhuǎn)成ID并且緩存下來在使用
• GetComponent會(huì)遍歷對(duì)象上面的所有組件去尋找 組件越多GetComponent的成本就越高 Find會(huì)尋找遍歷當(dāng)前場(chǎng)景所有對(duì)象 對(duì)象越多成本越高 建議使用緩存的方式優(yōu)
• 通過坐標(biāo)轉(zhuǎn)換來移動(dòng)有剛體組件的對(duì)象會(huì)導(dǎo)致PhysX物理引擎整體重新計(jì)算 建議用rigidBody自帶的方法并且放到FixedUpdate去
• AddComponent會(huì)有一系列的檢查過程 為了減少這些過程 建議不要在運(yùn)行時(shí)在去AddComponent一些組件 而是預(yù)先制作好預(yù)設(shè)體
• 移除空的Unity事件函數(shù) 因?yàn)槠湟廊辉趦?nèi)部經(jīng)行一系列操作
• Awake和Start完成后才會(huì)開始游戲 初始化內(nèi)容太多會(huì)導(dǎo)致啟動(dòng)速度變慢 建議啟動(dòng)游戲時(shí)初始化內(nèi)容較少 進(jìn)入游戲在開始各種初始化過程
• 層級(jí)太深會(huì)導(dǎo)致父物體變化,所有子物體跟著變化,而且垃圾回收也需要遍歷很多次才能拿到所有對(duì)象

2:內(nèi)存優(yōu)化

資源優(yōu)化:

GC優(yōu)化(值類型的內(nèi)存是由stack分配的 引用類型的內(nèi)存是heap分配的)

(1)定期調(diào)用GC:比如場(chǎng)景切換的時(shí)候就進(jìn)行一次GC操作

(2)stack(堆棧) 包含:函數(shù)本身,函數(shù)傳的參數(shù),函數(shù)區(qū)域的變量 用完就從堆棧里面丟出去 太多會(huì)造成堆棧溢出

• 在編輯器時(shí)候才使用get/set(因?yàn)間et/set屬于方法調(diào)用 花費(fèi)在堆棧框中的時(shí)間會(huì)增加) 真機(jī)上就正常獲取數(shù)據(jù)

(3)heap(堆) 包含:類,實(shí)體,對(duì)象 用完只會(huì)標(biāo)記為未使用 需要使用垃圾回收器去回收

• 緩存:對(duì)于不會(huì)變化的對(duì)象預(yù)先緩存下來,后面可以重復(fù)使用 比如使用Scriptable Objects減少我們自己寫的類的里面的變量數(shù)據(jù)在new的時(shí)候多次生成
• 對(duì)象池:預(yù)先實(shí)例化n個(gè)對(duì)象 循環(huán)使用這幾個(gè)對(duì)象 多了就擴(kuò)容

(4)以下這些操作會(huì)造成內(nèi)存分配 用的時(shí)候要盡量避免或者用其他方法代替

• 干掉非必要的Log日志打印
• 字符串拼接，unity部分API(太多,可自查,這里不放了)，裝箱操作，協(xié)程，foreach(unity5.5之前)，函數(shù)引用，LINQ和常量表達(dá)式
• struct的結(jié)構(gòu)如果有值類型和引用類型的話 需要分開他們

public struct ItemData {public string name;public int cost;public Vector3 position; } private ItemData[] itemData; 我們可以將該struct拆分為多個(gè)數(shù)組的形式，從而減小GC的工作量： private string[] itemNames; private int[] itemCosts; private Vector3[] itemPositions;

• 遇到對(duì)象引用其他對(duì)象的可以使用標(biāo)記來代替引用

public class DialogData {private DialogData nextDialog;public DialogData GetNextDialog(){return nextDialog;} } 通過重構(gòu)代碼，我們可以返回下一個(gè)對(duì)話框?qū)嶓w的標(biāo)記，而不是對(duì)話框?qū)嶓w本身，這樣就沒有多余的object引用，從而減少GC的工作量： public class DialogData {private int nextDialogID;public int GetNextDialogID(){return nextDialogID;} }

引擎模塊自身占用:

對(duì)于WebStream和SerializedFile，你需要關(guān)注以下兩點(diǎn)：

• 是否存在AssetBundle沒有被清理干凈的情況。開發(fā)團(tuán)隊(duì)可以通過Unity Profiler直接查看其使用具體的使用情況，并確定Take Sample時(shí)AssetBundle的存在是否合理；
• 對(duì)于占用WebStream較大的AssetBundle文件（如UI Atlas相關(guān)的AssetBundle文件等），建議使用LoadFromCacheOrDownLoad或CreateFromFile來進(jìn)行替換，即將解壓后的AssetBundle數(shù)據(jù)存儲(chǔ)于本地Cache中進(jìn)行使用。這種做法非常適合于內(nèi)存特別吃緊的項(xiàng)目，即通過本地的磁盤空間來?yè)Q取內(nèi)存空間。

無(wú)效的Mono堆內(nèi)存開銷

避免或減少過多“無(wú)效堆內(nèi)存"：

• 避免一次性堆內(nèi)存的過大分配。Mono的堆內(nèi)存也是“按需”逐步進(jìn)行分配的。但如果一次性開辟過大堆內(nèi)存，比如New一個(gè)較大Container、加載一個(gè)過大配置文件等，則勢(shì)必會(huì)造成Mono的堆內(nèi)存直接沖高，所以研發(fā)團(tuán)隊(duì)對(duì)堆內(nèi)存的分配需要時(shí)刻注意；
• 避免不必要的堆內(nèi)存開銷。

資源冗余：干掉多余重復(fù)的資源

• 變體優(yōu)化:表面著色器改成vert/frag 去掉不需要的變體和Pass
• 去掉多余重復(fù)的資源

內(nèi)存泄露查詢方法:

• 檢查資源的使用情況，特別是紋理、網(wǎng)格等資源的使用
• 通過Profiler來檢測(cè)WebStream或SerializedFile的使用情況
• 通過Android PSS/iOS Instrument反饋的App線程內(nèi)存來查看

4:渲染優(yōu)化

• 方案替換(陰影 抗鋸齒 后處理等實(shí)現(xiàn)方法多種多樣,可以挑選一個(gè)最適合項(xiàng)目的)
• 加速結(jié)構(gòu)(運(yùn)用數(shù)據(jù)結(jié)構(gòu)的特性加速運(yùn)算,比如:層次包圍盒)
• 加速算法(運(yùn)用數(shù)學(xué)的特性加速運(yùn)算，比如:重要性采樣)
• 算法優(yōu)化:減少ifelse,clip使用 避免除0 符號(hào)替換(比如:除法換乘法 乘法換加法) 使用RTT代替GrabPass等
• OverDraw:相機(jī)和場(chǎng)景分開 不透明物體從后往前 Early Depth testing（提前深度測(cè)試） 增加填充率

5:資源制作過程優(yōu)化

• 移除不需要透明度的紋理的alpha通道
• 合并mesh/貼圖減少內(nèi)存和構(gòu)建時(shí)間
• 底模仿高模

6:編譯速度優(yōu)化

• 代碼固定的可制作成DLL

7:其他

• 自定義分辨率而不是使用手機(jī)自帶的(因?yàn)楝F(xiàn)在的手機(jī)分辨率越來越大,但我們其實(shí)并不需要那么大)
• 數(shù)據(jù)結(jié)構(gòu)選擇

總結(jié)

以上是生活随笔為你收集整理的unity fixedupdate_unity相关的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。