版權(quán)聲明：本文為Jumbo原創(chuàng)文章,采用[知識(shí)共享 署名-非商業(yè)性使用-禁止演繹 4.0 國(guó)際 許可協(xié)議]，轉(zhuǎn)載前請(qǐng)保證理解此協(xié)議
原文出處：http://www.reibang.com/p/e427a38e91c3
常見的Unity性能問題
VSS：Virtual Set Size音诈，虛擬耗用內(nèi)存细溅。它是一個(gè)進(jìn)程能訪問的所有內(nèi)存空間地址的大小。這個(gè)大小包含了 一些沒有駐留在RAM中的內(nèi)存誓篱，就像mallocs已經(jīng)被分配窜骄，但還沒有寫入邻遏。VSS很少用來測(cè)量程序的實(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一次開銷可長(zhǎng)可短，有時(shí)長(zhǎng)達(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)存占用情況
內(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ì)象池管理
場(chǎng)景切換時(shí)械念，主動(dòng)調(diào)用System.GC.Collect(),及時(shí)清理內(nèi)存
- Mono通過垃圾回收機(jī)制（Garbage Collect头朱，簡(jiǎn)稱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
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倍
iOS 透明使用一張RGBA PVRTC 4bits或RGBA16或兩張RGB PVRTC Alpha分離声离，盡量不要使用RGBA32位
單張圖最大不超過1024*1024
Mesh:SubMesh數(shù)量芒炼、頂點(diǎn)數(shù)量、壓縮术徊、Read/Write Mesh合并本刽、不勾選Read/Write、大型場(chǎng)景使用LOD
AnimationClip:動(dòng)畫曲線數(shù)量赠涮、Constant曲線數(shù)量子寓、Dense曲線數(shù)量、Stream曲線數(shù)量世囊、以及動(dòng)畫事件數(shù)量
動(dòng)畫壓縮:無用的曲線刪除别瞭，調(diào)整float精度
AudioClp:格式、加載方式株憾、時(shí)長(zhǎng)以及頻率 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 CountDon’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垂直同步又稱場(chǎng)同步(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)榇怪蓖降拇嬖冢拍苁沟糜螒蜻M(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)陰影 盡量使用簡(jiǎn)單的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è)場(chǎng)景里如果包含了三個(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ǎng)景中的光照信息存儲(chǔ)在一張光照紋理中，然后在運(yùn)行時(shí)刻只需要根據(jù)紋理采樣得到光照信息即可缘挽。當(dāng)你需要金屬性強(qiáng)（鏡面）的效果瞄崇，可以使用Light Probes。當(dāng)你需要一束光的時(shí)候壕曼，可以使用體積光去模擬這個(gè)效果苏研。
動(dòng)態(tài)陰影很酷，但是對(duì)于片元著色器來說是災(zāi)難腮郊，陰影計(jì)算是三角投影計(jì)算摹蘑，非常耗性能。如果想要陰影轧飞，可以使用
- 簡(jiǎn)單的使用一個(gè)帶陰影的貼圖
- 烘焙場(chǎng)景衅鹿，拿到lightmaps
- 創(chuàng)建投影生成器的方法
- 使用ShadowMap的方法
建議盡量使用Unity自帶mobile版本的(built-in)Shader，這些大大提高了頂點(diǎn)處理的性能过咬。當(dāng)然也會(huì)有一些限制大渤。
自己寫的shader請(qǐng)注意復(fù)雜操作符計(jì)算，類似pow,exp,log,cos,sin,tan等都是很耗時(shí)的計(jì)算掸绞，最多只用一次在每個(gè)像素點(diǎn)的計(jì)算泵三，還有有些除法運(yùn)算盡量該能乘法運(yùn)算等。
避免透明度測(cè)試著色器，因?yàn)檫@個(gè)非常耗時(shí)切黔，使用透明度混合的版本來代替砸脊。
浮點(diǎn)類型運(yùn)算:精度越低的浮點(diǎn)計(jì)算越快。
不要在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ù)瞳抓，看不到總體的詳情
Unity5.3及其以上
使用IL2CPP，比如iOS平臺(tái)
構(gòu)建時(shí)開啟Development Build
研發(fā)團(tuán)隊(duì)需要關(guān)注的引擎模塊
開始優(yōu)化工作
前面已經(jīng)介紹了性能相關(guān)概念以及需關(guān)注模塊伏恐，接下來該開始優(yōu)化工作孩哑，具體步驟如下：
