Unity 效能優化

unity效能問題

vss：virtual set size，虛擬耗用記憶體。它是乙個程序能訪問的所有記憶體空間位址的大小。這個大小包含了 一些沒有駐留在ram中的記憶體，就像mallocs已經被分配，但還沒有寫入。vss很少用來測量程式的實際使 用記憶體。

rss：resident set size，實際使用物理記憶體。rss是乙個程序在ram中實際持有的記憶體大小。rss可能會 產生誤導，因為它包含了所有該程序使用的共享庫所占用的記憶體，乙個被載入到記憶體中的共享庫可能有很 多程序會使用它。rss不是單個程序使用記憶體量的精確表示。

pss：proportional set size，實際使用的物理記憶體，它與rss不同，它會按比例分配共享庫所占用的記憶體。 例如，如果有三個程序共享乙個佔30頁記憶體控制項的共享庫，每個程序在計算pss的時候，只會計算10頁。 pss是乙個非常有用的數值，如果系統中所有的程序的pss相加，所得和即為系統占用記憶體的總和。當乙個 程序被殺死後，它所占用的共享庫記憶體將會被其他仍然使用該共享庫的程序所分擔。在這種方式下，pss 也會帶來誤導，因為當乙個程序被殺後，pss並不代表系統**的記憶體大小。

uss：unique set size，程序獨自占用的物理記憶體。這部分記憶體完全是該程序獨享的。uss是乙個非常有用 的數值，因為它表明了執行乙個特定程序所需的真正記憶體成本。當乙個程序被殺死，uss就是所有系統回 收的記憶體。uss是用來檢查程序中是否有記憶體洩露的最好選擇。

drawcall是cpu呼叫底層圖形介面的操作。比如有上千個物體，每乙個的渲染都需要去呼叫一次底層介面，而每一次的呼叫cpu都需要做很多任務作，那麼cpu必然不堪重負。

gc是用來處理記憶體**的，但是卻增加了cpu的開銷（gc一次開銷可長可短，有時長達100ms）。因此對於gc的優化目標就是盡量少的觸發gc。

首先我們要知道所謂的gc是mono執行時的機制，而非unity3d遊戲引擎的機制，所以gc也主要是針對mono的物件來說的，而它管理的也是mono的託管堆。 明白了這一點，你也就明白了gc不是用來處理引擎的assets（貼圖，音效，模型等等）的記憶體釋放的，因為u3d引擎也有自己的記憶體堆而不是和mono一起使用所謂的託管堆。其次我們還要清楚什麼東西會被分配到託管堆上？對，就是引用型別。引用型別包括：使用者自定義的類，介面，委託，陣列，字串，object.而值型別包括：幾種基本資料型別（如：int,float,bool等），結構體，列舉，空型別。所以gc的優化也就是**的優化。

unity執行時的記憶體占用情況

mono記憶體

obja.arrints設定為null,斷絕引用關係，待gc時，進行物件**(obja本身是乙個靜態物件，是gc的 根節點，因此沒有物件引用)

android 透明使用兩張etc1壓縮(更高階一張etc1上下alpha分離)，etc2只支援opengl es3.0裝置，在不支援的裝置上會自動轉成rgba32/argb32格式，對於rgba compressed etc2 8bits紋理記憶體占用就增大4倍

ios 透明使用一張rgba pvrtc 4bits或rgba16或兩張rgb pvrtc alpha分離，盡量不要使用rgba32位

單張圖最大不超過1024*1024

etc2 的格式理論上只在opengl es 3.0 的裝置上被支援，而在不被支援的裝置上則會內部自動轉成 rgba32/argb32的格式，這對於 rgba compressed etc2 8bits 的紋理就是放大了 4 倍。因此，如果希望在 opengl es 2.0 的裝置上對透明材質進行壓縮，那麼可以嘗試使用分離 alpha 通道的方式，用兩個 etc1 來進行壓縮

gpu接收頂點資料作為輸入傳遞給頂點著色器。頂點著色器的處理單元是頂點,輸入進來的每個頂點都會呼叫一次頂點著色器。（頂點著色器本身不可以建立或銷毀任何頂點，並無法得到頂點與頂點之間的關係）。頂點著色器是完全可程式設計的，它主要完成的工作有：座標變換和逐頂點光照。 座標變換：就是對頂點的座標進行某種變換—把頂點座標從模型空間轉換到齊次裁剪空間。頂點的多少直接決定了三角形面的多少，也直接決定了gpu的渲染流水線的工作量，所以減少頂點數是乙個比較重要的優化點。那麼減少頂點怎麼操作呢，又有哪些途徑？

移動平台的最大敵人。乙個場景裡如果包含了三個逐畫素的點光源，而且使用了逐畫素的shader，那麼很有可能將draw calls提高了三倍，同時也會增加overdraws。這是因為，對於逐畫素的光源來說，被這些光源照亮的物體要被再渲染一次。更糟糕的是，無論是動態批處理還是動態批處理（其實文件中只提到了對動態批處理的影響，但不知道為什麼實驗結果對靜態批處理也沒有用），對於這種逐畫素的pass都無法進行批處理，也就是說，它們會中斷批處理。所以當你需要光照效果時，可以使用lightmaps，提前烘焙好，提前把場景中的光照資訊儲存在一張光照紋理中，然後在執行時刻只需要根據紋理取樣得到光照資訊即可。當你需要金屬性強（鏡面）的效果，可以使用light probes。當你需要一束光的時候，可以使用體積光去模擬這個效果。

動態陰影很酷，但是對於片元著色器來說是災難，陰影計算是三角投影計算，非常耗效能。如果想要陰影，可以使用

簡單的使用乙個帶陰影的貼圖

烘焙場景，拿到lightmaps

建立投影生成器的方法

使用shadowmap的方法

自己寫的shader請注意複雜操作符計算，類似pow,exp,log,cos,sin,tan等都是很耗時的計算，最多只用一次在每個畫素點的計算，還有有些除法運算盡量該能乘法運算等。

避免透明度測試著色器，因為這個非常耗時，使用透明度混合的版本來代替。

浮點型別運算:精度越低的浮點計算越快。

不要在shader中新增不必要的pass.

unity5.3及其以上

使用il2cpp，比如ios平台

構建時開啟development build

優化關注模組

優化工作

unity效能優化2

1 效能優化的是 低幀率或者高記憶體占用 通過unity profiler 我們知道誰占用cpu多少時間，遊戲如何使用記憶體 左側的是cpu使用情況，gpu，渲染，記憶體，聲音。下半部分顯示當前幀的詳細情況 1 如果遊戲執行的慢，我們首先看cpu,看誰占用了他大量的時間 a resources目錄下...

Unity效能優化 DrawCall

1.drawcall是啥？其實就是對底層圖形程式 比如 opengl es 介面的呼叫，以在螢幕上畫出東西。所以，是誰去呼叫這些介面呢？cpu。比如有上千個物體，每乙個的渲染都需要去呼叫一次底層介面，而每一次的呼叫cpu都需要做很多任務作，那麼cpu必然不堪重負。但是對於gpu來說，圖形處理的工作量...

unity效能優化 CPU

影響效能的因素 對於乙個遊戲來說，有兩種主要的計算資源 cpu和gpu，它們會互相合作，來讓我們的遊戲可以在預期的幀率和解析度下工作。cpu負責其中的幀率，gpu主要負責解析度相關的一些東西。本篇會介紹cpu的優化技巧 作用 計算。主要是在蒙皮骨骼計算，布料模擬，頂點動畫，粒子模擬等，還有在各種頂點...