版權(quán)聲明：本文為Jumbo原創(chuàng)文章,采用[知識(shí)共享 署名-非商業(yè)性使用-禁止演繹 4.0 國際 許可協(xié)議]，轉(zhuǎn)載前請(qǐng)保證理解此協(xié)議
原文出處：http://www.itdecent.cn/p/e427a38e91c3

常見的Unity性能問題

Unity性能問題

VSS：Virtual Set Size，虛擬耗用內(nèi)存。它是一個(gè)進(jìn)程能訪問的所有內(nèi)存空間地址的大小。這個(gè)大小包含了 一些沒有駐留在RAM中的內(nèi)存，就像mallocs已經(jīng)被分配，但還沒有寫入。VSS很少用來測量程序的實(shí)際使 用內(nèi)存。

RSS：Resident Set Size，實(shí)際使用物理內(nèi)存。RSS是一個(gè)進(jìn)程在RAM中實(shí)際持有的內(nèi)存大小。RSS可能會(huì) 產(chǎn)生誤導(dǎo)，因?yàn)樗怂性撨M(jìn)程使用的共享庫所占用的內(nèi)存，一個(gè)被加載到內(nèi)存中的共享庫可能有很 多進(jìn)程會(huì)使用它。RSS不是單個(gè)進(jìn)程使用內(nèi)存量的精確表示。

PSS：Proportional Set Size，實(shí)際使用的物理內(nèi)存，它與RSS不同，它會(huì)按比例分配共享庫所占用的內(nèi)存。 例如，如果有三個(gè)進(jìn)程共享一個(gè)占30頁內(nèi)存控件的共享庫，每個(gè)進(jìn)程在計(jì)算PSS的時(shí)候，只會(huì)計(jì)算10頁。 PSS是一個(gè)非常有用的數(shù)值，如果系統(tǒng)中所有的進(jìn)程的PSS相加，所得和即為系統(tǒng)占用內(nèi)存的總和。當(dāng)一個(gè) 進(jìn)程被殺死后，它所占用的共享庫內(nèi)存將會(huì)被其他仍然使用該共享庫的進(jìn)程所分擔(dān)。在這種方式下，PSS 也會(huì)帶來誤導(dǎo)，因?yàn)楫?dāng)一個(gè)進(jìn)程被殺后，PSS并不代表系統(tǒng)回收的內(nèi)存大小。

USS：Unique Set Size，進(jìn)程獨(dú)自占用的物理內(nèi)存。這部分內(nèi)存完全是該進(jìn)程獨(dú)享的。USS是一個(gè)非常有用 的數(shù)值，因?yàn)樗砻髁诉\(yùn)行一個(gè)特定進(jìn)程所需的真正內(nèi)存成本。當(dāng)一個(gè)進(jìn)程被殺死，USS就是所有系統(tǒng)回 收的內(nèi)存。USS是用來檢查進(jìn)程中是否有內(nèi)存泄露的最好選擇。

DrawCall是CPU調(diào)用底層圖形接口的操作。比如有上千個(gè)物體，每一個(gè)的渲染都需要去調(diào)用一次底層接口，而每一次的調(diào)用CPU都需要做很多工作，那么CPU必然不堪重負(fù)。

GC是用來處理內(nèi)存回收的，但是卻增加了CPU的開銷（GC一次開銷可長可短，有時(shí)長達(dá)100ms）。因此對(duì)于GC的優(yōu)化目標(biāo)就是盡量少的觸發(fā)GC。

首先我們要知道所謂的GC是Mono運(yùn)行時(shí)的機(jī)制，而非Unity3D游戲引擎的機(jī)制，所以GC也主要是針對(duì)Mono的對(duì)象來說的，而它管理的也是Mono的托管堆。 明白了這一點(diǎn)，你也就明白了GC不是用來處理引擎的Assets（貼圖，音效，模型等等）的內(nèi)存釋放的，因?yàn)閁3D引擎也有自己的內(nèi)存堆而不是和Mono一起使用所謂的托管堆。其次我們還要清楚什么東西會(huì)被分配到托管堆上？對(duì)，就是引用類型。引用類型包括：用戶自定義的類，接口，委托，數(shù)組，字符串，Object.而值類型包括：幾種基本數(shù)據(jù)類型（如：int,float,bool等），結(jié)構(gòu)體，枚舉，空類型。所以GC的優(yōu)化也就是代碼的優(yōu)化。

Unity運(yùn)行時(shí)的內(nèi)存占用情況

Unity運(yùn)行時(shí)的內(nèi)存占用情況

內(nèi)存標(biāo)準(zhǔn)

• 限定內(nèi)存占用不超過200M(iPhone4接近容易Crash,低端機(jī)型)

• 項(xiàng)目中Reserved Total(總體分配)內(nèi)存盡量控制在150M以內(nèi)，如下 Texture 50M Mesh 20M AnimationClip 15M AudioClip 15M Mono堆內(nèi)存 40M 字體等 10M

• 項(xiàng)目中盡量嚴(yán)格控制，即使在中高端機(jī)型可較大內(nèi)存運(yùn)行。

Mono內(nèi)存管理策略

• 字符串連接處理，建議StringBuilder

• 盡量不使用foreach，Unity5.4以上解決了GC問題

• 不要頻繁實(shí)例化和銷毀對(duì)象，建議對(duì)象池管理

• 場景切換時(shí)，主動(dòng)調(diào)用System.GC.Collect(),及時(shí)清理內(nèi)存

Mono內(nèi)存

• Mono通過垃圾回收機(jī)制（Garbage Collect，簡稱GC）對(duì)內(nèi)存進(jìn)行管理。Mono內(nèi)存分為兩部分，已用內(nèi)存（used）和堆內(nèi)存（heap），已用內(nèi)存指的是mono實(shí)際需要使用的內(nèi)存，堆內(nèi)存指的是mono向操作系統(tǒng)申請(qǐng)的內(nèi)存，兩者的差值就是mono的空閑內(nèi)存。當(dāng)mono需要分配內(nèi)存時(shí)，會(huì)先查看空閑內(nèi)存是否足夠，如果足夠的話，直接在空閑內(nèi)存中分配，否則mono會(huì)進(jìn)行一次GC以釋放更多的空閑內(nèi)存，如果GC之后仍然沒有足夠的空閑內(nèi)存，則mono會(huì)向操作系統(tǒng)申請(qǐng)內(nèi)存。

Mono內(nèi)存泄漏分析

• Mono通過引用關(guān)系，判斷哪些內(nèi)存不再使用

• 【Mono內(nèi)存泄漏】對(duì)象已經(jīng)不再使用，卻未被GC回收

• Mono內(nèi)存泄漏使空閑內(nèi)存減少，GC頻繁，mono堆不斷擴(kuò)大，最終導(dǎo)致游戲內(nèi)存占用的增大

• 大部分mono內(nèi)存泄漏的情況都是由于靜態(tài)對(duì)象的引用引起

• 不再需要的對(duì)象將其引用設(shè)置為null，使其可以被GC及時(shí)回收

解決方法

objA.arrInts設(shè)置為null,斷絕引用關(guān)系，待GC時(shí)，進(jìn)行對(duì)象回收(objA本身是一個(gè)靜態(tài)對(duì)象，是GC的 根節(jié)點(diǎn)，因此沒有對(duì)象引用)

資源優(yōu)化

• Texture:分辨率大小、格式、Mipmap、Read/Write

1. Android 透明使用兩張ETC1壓縮(更高級(jí)一張ETC1上下Alpha分離)，ETC2只支持OpenGL ES3.0設(shè)備，在不支持的設(shè)備上會(huì)自動(dòng)轉(zhuǎn)成RGBA32/ARGB32格式，對(duì)于RGBA Compressed ETC2 8bits紋理內(nèi)存占用就增大4倍

2. iOS 透明使用一張RGBA PVRTC 4bits或RGBA16或兩張RGB PVRTC Alpha分離，盡量不要使用RGBA32位

3. 單張圖最大不超過1024*1024

• Mesh:SubMesh數(shù)量、頂點(diǎn)數(shù)量、壓縮、Read/Write Mesh合并、不勾選Read/Write、大型場景使用LOD

• AnimationClip:動(dòng)畫曲線數(shù)量、Constant曲線數(shù)量、Dense曲線數(shù)量、Stream曲線數(shù)量、以及動(dòng)畫事件數(shù)量

• 動(dòng)畫壓縮:無用的曲線刪除，調(diào)整float精度

• AudioClp:格式、加載方式、時(shí)長以及頻率 BGM背景音:ogg SFX聲音特效:wav (有些項(xiàng)目BGM\SFX都用mp3)

• Material:關(guān)聯(lián)的Shader和Texture

• Shader盡量使用mobile速配的

ETC2 的格式理論上只在OpenGL ES 3.0 的設(shè)備上被支持，而在不被支持的設(shè)備上則會(huì)內(nèi)部自動(dòng)轉(zhuǎn)成 RGBA32/ARGB32的格式，這對(duì)于 RGBA Compressed ETC2 8bits 的紋理就是放大了 4 倍。因此，如果希望在 OpenGL ES 2.0 的設(shè)備上對(duì)透明材質(zhì)進(jìn)行壓縮，那么可以嘗試使用分離 Alpha 通道的方式，用兩個(gè) ETC1 來進(jìn)行壓縮

DrawCall優(yōu)化

• 先了解下DrawCall相關(guān)概念，便于優(yōu)化

  DrawCall是CPU調(diào)用底層圖形接口的操作

  DrawCall_Num = 25K * CPU_Frame * CPU_Percentage / FPS

  DrawCall_Num ： DrawCall數(shù)量（最大支持）

  CPU_Frame : CPU 工作頻率（GHz單位）

  CPU_Percentage：CPU 分配在DrawCall這件事情上的時(shí)間率 （百分比） ? FPS：希望的游戲幀率

• DrawCall Batching(DC批處理)

  Dynamic Batching（動(dòng)態(tài)批處理）

  Static Batching（靜態(tài)批處理）

• Bus總線帶寬

  CPU完成一次DrawCall，除了需要調(diào)用一次DrawCall的命令之外，還需要把內(nèi)存中頂點(diǎn)數(shù)據(jù)、紋理貼圖、shader參數(shù)通過bus總線拷貝到內(nèi)存分配給GPU的顯存之中，注意這是拷貝，不是指針傳遞，速度不快。項(xiàng)目中不會(huì)同時(shí)出現(xiàn)的資源不要打包到一起，保證單張合并紋理不大于1024*1024一般就不會(huì)有問題了。

CPU優(yōu)化最直接的方法

• VSync（垂直同步）是CPU優(yōu)化最直接的方式(發(fā)熱、耗電原因之一)

• 打開Edit-Project Settings-Quality找到V Sync Count

  V Sync Count

  Don’t Sync 不同步

  Every V Blank 每一個(gè)垂直同步

  Every Second V Blank 每一秒垂直同步

  通常我們選擇Don’t Sync,同時(shí)Application.targetFrameRate設(shè)置目標(biāo)FPS，讓性能保持一個(gè)好的狀態(tài)。注意選擇其他項(xiàng),Application.targetFrameRate設(shè)置不生效。

  科普：VSync垂直同步又稱場同步(Vertical Hold)，垂直同步信號(hào)決定了CRT從屏幕頂部畫到底部，再返回原始位置的時(shí)間。從CRT顯示器的顯示原理來看，單個(gè)像素組成了水平掃描線，水平掃描線在垂直方向的堆積形成了完整的畫面。顯示器的刷新率受顯卡DAC控制，顯卡DAC完成一幀的掃描后就會(huì)產(chǎn)生一個(gè)垂直同步信號(hào)（決定于屏幕的刷新率）。我們平時(shí)所說的打開垂直同步指的是將該信號(hào)送入顯卡3D圖形處理部分，從而讓顯卡在生成3D圖形時(shí)受垂直同步信號(hào)的制約（注意是制約）。如果我們選擇等待垂直同步信號(hào)（也就是我們平時(shí)所說的垂直同步打開），那么在游戲中或許強(qiáng)勁的顯卡迅速的繪制完一屏的圖像，但是沒有垂直同步信號(hào)的到達(dá)，顯卡無法繪制下一屏，只有等垂直同步的信號(hào)到達(dá)，才可以繪制。這樣FPS自然要受到操作系統(tǒng)刷新率運(yùn)行值的制約。而如果我們選擇不等待垂直同步信號(hào)（也就是我們平時(shí)所說的關(guān)閉垂直同步），那么游戲中作完一屏畫面，顯卡和顯示器無需等待垂直同步信號(hào)就可以開始下一屏圖像的繪制，自然可以完全發(fā)揮顯卡的實(shí)力。但是不要忘記，正是因?yàn)榇怪蓖降拇嬖?，才能使得游戲進(jìn)程和顯示器刷新率同步，使得畫面更加平滑和穩(wěn)定。取消了垂直同步信號(hào)，固然可以換來更快的幀率，但是在圖像的連續(xù)性上勢(shì)必打折扣。

GPU優(yōu)化

渲染流程

GPU接收頂點(diǎn)數(shù)據(jù)作為輸入傳遞給頂點(diǎn)著色器。頂點(diǎn)著色器的處理單元是頂點(diǎn),輸入進(jìn)來的每個(gè)頂點(diǎn)都會(huì)調(diào)用一次頂點(diǎn)著色器。（頂點(diǎn)著色器本身不可以創(chuàng)建或銷毀任何頂點(diǎn)，并無法得到頂點(diǎn)與頂點(diǎn)之間的關(guān)系）。頂點(diǎn)著色器是完全可編程的，它主要完成的工作有：坐標(biāo)變換和逐頂點(diǎn)光照。 坐標(biāo)變換：就是對(duì)頂點(diǎn)的坐標(biāo)進(jìn)行某種變換—把頂點(diǎn)坐標(biāo)從模型空間轉(zhuǎn)換到齊次裁剪空間。頂點(diǎn)的多少直接決定了三角形面的多少，也直接決定了GPU的渲染流水線的工作量，所以減少頂點(diǎn)數(shù)是一個(gè)比較重要的優(yōu)化點(diǎn)。那么減少頂點(diǎn)怎么操作呢，又有哪些途徑？

• 頂點(diǎn)著色器 優(yōu)化基本幾何體(模型減面減頂點(diǎn)) 使用LOD（Level of detail）技術(shù) 使用遮擋剔除（Occlusion culling）技術(shù)

• 中間操作 曲面細(xì)分著色器：是一個(gè)可選的著色器，主要用于細(xì)分圖元 幾何著色器：是一個(gè)可選的著色器，可用于執(zhí)行逐圖元的著色操作，或者被用于產(chǎn)生更多的圖元。 裁剪：這一階段是可配置的。目的是把那些不在視野內(nèi)的頂點(diǎn)裁剪掉，并剔除某些三角形圖元的面片。部分在視野內(nèi)的圖元需要做裁剪處理，在裁剪邊緣產(chǎn)生新的頂點(diǎn)和三角形進(jìn)行處理。 屏幕映射：這一階段是可配置和編程的，負(fù)責(zé)把每個(gè)圖元的坐標(biāo)（三維坐標(biāo)系）轉(zhuǎn)換成屏幕坐標(biāo)（二維坐標(biāo)系）。

• 三角形設(shè)置：開始進(jìn)入光柵化階段，不再是數(shù)學(xué)上點(diǎn)了，而會(huì)把所有的點(diǎn)都映射到屏幕的具體像素坐標(biāo)上，計(jì)算每條邊上的像素坐標(biāo)而得到三角形邊界的表示方式即為三角形設(shè)置。 三角形遍歷：這一階段會(huì)檢查每個(gè)像素是否被一個(gè)三角風(fēng)格所覆蓋。如果覆蓋的話，就會(huì)生成一個(gè)片元（一個(gè)片元并不是真正意義上的像素，而是包含了很多狀態(tài)的集合，這些狀態(tài)用于計(jì)算每個(gè)像素的最終顏色。這些狀態(tài)包括了屏幕坐標(biāo)、深度信息，及從幾何階段輸出的頂點(diǎn)信息，如法線和紋理坐標(biāo)等。），這樣一個(gè)查找哪些像素被三角形覆蓋的過程就是三角形遍歷。

• 片元著色器 盡量減少overdraw 減少實(shí)時(shí)光照 不要使用動(dòng)態(tài)陰影 盡量使用簡單的shader

片元著色器的輸入就是上一階段對(duì)頂點(diǎn)信息插值得到的結(jié)果，更具體點(diǎn)說，是根據(jù)從頂點(diǎn)著色器中輸出的數(shù)據(jù)插值得到的。而這一階段的輸出是一個(gè)或者多個(gè)顏色值。這一階段可以完成很多重要的渲染技術(shù)，如紋理采樣，但是它的局限在于，它僅可以影響單個(gè)片元。片元著色器是比較花時(shí)間的，因?yàn)樗亲罱K顏色的計(jì)算者，在某些情況下，例如復(fù)雜燈光環(huán)境下，片元著色器會(huì)出現(xiàn)GPU流水線主要的拖后腿的存在。為了讓片元著色器的計(jì)算更加快，我們需要從很多方面進(jìn)行提前的優(yōu)化：片元著色器最容易拖后腿的情況就是，overdraw！和Android app的開發(fā)一樣，就是同一個(gè)像素點(diǎn)繪制了多次，某些情況會(huì)造成計(jì)算力的浪費(fèi)，增加耗電量。前面提到的遮擋剔除有減少overdraw非常有用。在PC上，資源無限，為了得到最準(zhǔn)確的渲染結(jié)果，繪制順序可能是從后往前繪制不透明物體，然后再繪制透明物體進(jìn)行混合。但是在移動(dòng)平臺(tái)上，對(duì)于不透明物體，我們可以設(shè)置從前往后繪制，對(duì)于有透明通道的物體（很多UI紋理就是含有透明通道的），再設(shè)置從后往前繪制。unity中shader設(shè)置為“Geometry” 隊(duì)列的對(duì)象總是從前往后繪制的，而其他固定隊(duì)列（如“Transparent”“Overla”等）的物體，則都是從后往前繪制的。這意味這，我們可以盡量把物體的隊(duì)列設(shè)置為“Geometry” 。對(duì)于GUI，尤其要注意和設(shè)計(jì)師商量，能用不透明的設(shè)計(jì)就用不透明的，對(duì)于粒子效果，也要注意不要引入透明值，多半情況下，移動(dòng)平臺(tái)的粒子效果透明值沒有作用。

移動(dòng)平臺(tái)的最大敵人。一個(gè)場景里如果包含了三個(gè)逐像素的點(diǎn)光源，而且使用了逐像素的shader，那么很有可能將Draw Calls提高了三倍，同時(shí)也會(huì)增加overdraws。這是因?yàn)?，?duì)于逐像素的光源來說，被這些光源照亮的物體要被再渲染一次。更糟糕的是，無論是動(dòng)態(tài)批處理還是動(dòng)態(tài)批處理（其實(shí)文檔中只提到了對(duì)動(dòng)態(tài)批處理的影響，但不知道為什么實(shí)驗(yàn)結(jié)果對(duì)靜態(tài)批處理也沒有用），對(duì)于這種逐像素的pass都無法進(jìn)行批處理，也就是說，它們會(huì)中斷批處理。所以當(dāng)你需要光照效果時(shí)，可以使用Lightmaps，提前烘焙好，提前把場景中的光照信息存儲(chǔ)在一張光照紋理中，然后在運(yùn)行時(shí)刻只需要根據(jù)紋理采樣得到光照信息即可。當(dāng)你需要金屬性強(qiáng)（鏡面）的效果，可以使用Light Probes。當(dāng)你需要一束光的時(shí)候，可以使用體積光去模擬這個(gè)效果。

動(dòng)態(tài)陰影很酷，但是對(duì)于片元著色器來說是災(zāi)難，陰影計(jì)算是三角投影計(jì)算，非常耗性能。如果想要陰影，可以使用

1. 簡單的使用一個(gè)帶陰影的貼圖

2. 烘焙場景，拿到lightmaps

3. 創(chuàng)建投影生成器的方法

4. 使用ShadowMap的方法

1. 建議盡量使用Unity自帶mobile版本的(built-in)Shader，這些大大提高了頂點(diǎn)處理的性能。當(dāng)然也會(huì)有一些限制。

2. 自己寫的shader請(qǐng)注意復(fù)雜操作符計(jì)算，類似pow,exp,log,cos,sin,tan等都是很耗時(shí)的計(jì)算，最多只用一次在每個(gè)像素點(diǎn)的計(jì)算，還有有些除法運(yùn)算盡量該能乘法運(yùn)算等。

3. 避免透明度測試著色器，因?yàn)檫@個(gè)非常耗時(shí)，使用透明度混合的版本來代替。

4. 浮點(diǎn)類型運(yùn)算:精度越低的浮點(diǎn)計(jì)算越快。

5. 不要在Shader中添加不必要的Pass.

Unity優(yōu)化工具

• MAT（Memory Analyzer Tool） 需要導(dǎo)入HPROF文件再分析 只能查看java層的內(nèi)存情況，看不到native堆的詳情

• Xcode Instrument工具 只能用于Mac,iOS 只能查看C++ 或 object C 的情況，看不到mono堆的詳情

• Unity自帶Profiler 需要單獨(dú)編譯develop版本 在PC上執(zhí)行，沒法捕獲真機(jī)數(shù)據(jù) 內(nèi)存數(shù)據(jù)跟實(shí)際真機(jī)的數(shù)據(jù)差異很大、多的時(shí)候有幾十M差距 只能看到最近一段時(shí)間的數(shù)據(jù)，看不到總體的詳情

• 官方開源Memory Profiler

1. Unity5.3及其以上

2. 使用IL2CPP，比如iOS平臺(tái)

3. 構(gòu)建時(shí)開啟Development Build

• UWA（推薦）

• 騰訊WeTest（推薦）

研發(fā)團(tuán)隊(duì)需要關(guān)注的引擎模塊

優(yōu)化關(guān)注模塊

開始優(yōu)化工作

前面已經(jīng)介紹了性能相關(guān)概念以及需關(guān)注模塊，接下來該開始優(yōu)化工作，具體步驟如下：

優(yōu)化工作