CPU方面

就目前的Unity移動游戲而言碳却，CPU方面的性能開銷主要可歸結(jié)為兩大類：引擎模塊性能開銷和自身代碼性能開銷队秩。其中，引擎模塊中又可細致劃分為渲染模塊昼浦、動畫模塊馍资、物理模塊、UI模塊关噪、粒子系統(tǒng)鸟蟹、加載模塊和GC調(diào)用等等。正因如此色洞，我們在UWA測評報告中戏锹，就這些模塊進行詳細的性能分析，以方便大家快速定位項目的性能瓶頸火诸，同時锦针，根據(jù)我們的分析和建議對問題進行迅速排查和解決。

通過大量的性能測評數(shù)據(jù)置蜀，我們發(fā)現(xiàn)渲染模塊奈搜、UI模塊和加載模塊，往往占據(jù)了游戲CPU性能開銷的Top3盯荤。

一馋吗、渲染模塊

渲染模塊可以說是任何游戲中最為消耗CPU性能的引擎模塊，因為幾乎所有的游戲都離不開場景秋秤、物體和特效的渲染宏粤。對于渲染模塊的優(yōu)化，主要從以下兩個方面入手：

（1）降低Draw Call

Draw Call是渲染模塊優(yōu)化方面的重中之重灼卢，一般來說绍哎，Draw Call越高，則渲染模塊的CPU開銷越大鞋真。究其原因崇堰，要從底層Driver和GPU的渲染流程講起，限于篇幅我們不在這里做過多的介紹涩咖。有興趣的朋友可以查看這里海诲，或者自行Google相關(guān)的技術(shù)文獻。

降低Draw Call的方法則主要是減少所渲染物體的材質(zhì)種類檩互，并通過Draw Call Batching來減少其數(shù)量特幔。Unity文檔對于Draw Call Batching的原理和注意事項有非常詳細的講解，感興趣的朋友可以直接查看?Unity官方文檔盾似。

但是敬辣，需要注意的是雪标，游戲性能并非Draw Call越小越好零院。這是因為溉跃，決定渲染模塊性能的除了Draw Call之外，還有用于傳輸渲染數(shù)據(jù)的總線帶寬告抄。當(dāng)我們使用Draw Call Batching將同種材質(zhì)的網(wǎng)格模型拼合在一起時撰茎，可能會造成同一時間需要傳輸?shù)臄?shù)據(jù)（Texture、VB/IB等）大大增加打洼，以至于造成帶寬“堵塞”龄糊，在資源無法及時傳輸過去的情況下，GPU只能等待募疮，從而反倒降低了游戲的運行幀率炫惩。

Draw Call和總線帶寬是天平的兩端，我們需要做的是盡可能維持天平的平衡阿浓，任何一邊過高或過低他嚷，對性能來說都是無益的。

（2）簡化資源

簡化資源是非常行之有效的優(yōu)化手段芭毙。在大量的移動游戲中筋蓖，其渲染資源其實是“過量”的，過量的網(wǎng)格資源退敦、不合規(guī)的紋理資源等等粘咖。所以，我們在UWA測評報告中對資源的使用進行了詳細的展示（每幀渲染的三角形面片數(shù)侈百、網(wǎng)格和紋理資源的具體使用情況等）瓮下，以幫助大家快速查找和完善存在問題的資源。

關(guān)于渲染模塊在CPU方面的優(yōu)化方法還有很多钝域，比如LOD讽坏、Occlusion Culling和Culling Distance等等。我們會在后續(xù)的渲染模塊技術(shù)專題中進行更為詳細的講解网梢，敬請期待震缭。

二、UI模塊

UI模塊同樣也是幾乎所有的游戲項目中必備的模塊战虏。一個性能優(yōu)異的UI模塊可以將游戲的用戶體驗再抬高一個檔次拣宰。在目前國內(nèi)的大量項目中，NGUI作為UI解決方案的占比仍然非常高烦感。所以巡社，UWA測評報告對NGUI的性能分析進行了極大的支持，我們會根據(jù)用戶所使用的UI解決方案（UGUI或NGUI）的不同提供不同的性能分析和優(yōu)化建議手趣。

在NGUI的優(yōu)化方面晌该，UIPanel.LateUpdate為性能優(yōu)化的重中之重肥荔，它是NGUI中CPU開銷最大的函數(shù)，沒有之一朝群。UI模塊制作的難點并不在于其表現(xiàn)上燕耿，因為UI界面的表現(xiàn)力是由設(shè)計師來決定的，但兩套表現(xiàn)完全一致的UI系統(tǒng)姜胖，其底層的性能開銷則可能千差萬別誉帅。如何讓UI系統(tǒng)使用盡可能小的CPU開銷來達到設(shè)計師所設(shè)計的表現(xiàn)力，則足以考驗每一位UI開發(fā)人員的制作功底右莱。

目前蚜锨，我們在UWA測評報告中將統(tǒng)計意義上CPU開銷最為耗時的幾個函數(shù)進行展示，并將其詳細的CPU占用和堆內(nèi)存分配進行統(tǒng)計慢蜓，從而讓研發(fā)團隊對UI系統(tǒng)的性能開銷進行直接地掌握亚再，同時結(jié)合項目截圖對UI模塊何時存在較大開銷進行直觀地定位。

對于UIPanel.LateUpdate的優(yōu)化晨抡，主要著眼于UIPanel的布局氛悬，其原則如下：

盡可能將動態(tài)UI元素和靜態(tài)UI元素分離到不同的UIPanel中（UI的重建以UIPanel為單位），從而盡可能將因為變動的UI元素引起的重構(gòu)控制在較小的范圍內(nèi)凄诞；

盡可能讓動態(tài)UI元素按照同步性進行劃分圆雁，即運動頻率不同的UI元素盡可能分離放在不同的UIPanel中；

控制同一個UIPanel中動態(tài)UI元素的數(shù)量帆谍，數(shù)量越多伪朽，所創(chuàng)建的Mesh越大，從而使得重構(gòu)的開銷顯著增加汛蝙。比如烈涮，戰(zhàn)斗過程中的HUD運動血條可能會出現(xiàn)較多，此時窖剑，建議研發(fā)團隊將運動血條分離成不同的UIPanel坚洽，每組UIPanel下5~10個動態(tài)UI為宜。這種做法西土，其本質(zhì)是從概率上盡可能降低單幀中UIPanel的重建開銷讶舰。

另外，限于篇幅限制需了，我們在此僅介紹NGUI中重要性能問題跳昼，而對于UGUI系統(tǒng)以及UI系統(tǒng)自身的Draw Call問題，我們將在后續(xù)的UI模塊技術(shù)專題中進行詳細的講解肋乍，敬請期待鹅颊。

三、加載模塊

加載模塊同樣也是任何游戲項目中所不可缺少的組成成分墓造。與之前兩個模塊不同的是堪伍，加載模塊的性能開銷比較集中锚烦，主要出現(xiàn)于場景切換處，且CPU占用峰值均較高帝雇。

這里涮俄，我們先來說說場景切換時，其性能開銷的主要體現(xiàn)形式摊求。對于目前的Unity版本而言禽拔，場景切換時的主要性能開銷主要體現(xiàn)在兩個方面刘离，前一場景的場景卸載和下一場景的場景加載室叉。下面，我們就具體來說說這兩個方面的性能瓶頸：

（1）場景卸載

對于Unity引擎而言硫惕，場景卸載一般是由引擎自動完成的茧痕，即當(dāng)我們調(diào)用類似Application.LoadLevel的API時，引擎即會開始對上一場景進行處理恼除，其性能開銷主要被以下幾個部分占據(jù)：

Destroy

引擎在切換場景時會收集未標識成“DontDestoryOnLoad”的GameObject及其Component踪旷，然后進行Destroy。同時豁辉，代碼中的OnDestory被觸發(fā)執(zhí)行令野，這里的性能開銷主要取決于OnDestroy回調(diào)函數(shù)中的代碼邏輯。

Resources.UnloadUnusedAssets

一般情況下徽级，場景切換過程中气破，該API會被調(diào)用兩次，一次為引擎在切換場景時自動調(diào)用餐抢，另一次則為用戶手動調(diào)用（一般出現(xiàn)在場景加載后现使，用戶調(diào)用它來確保上一場景的資源被卸載干凈）。在我們測評過的大量項目中旷痕，該API的CPU開銷主要集中在500ms~3000ms之間碳锈。其耗時開銷主要取決于場景中Asset和Object的數(shù)量，數(shù)量越多欺抗，則耗時越慢售碳。

（2）場景加載

場景加載過程的性能開銷又可細分成以下幾個部分：

資源加載

資源加載幾乎占據(jù)了整個加載過程的90%時間以上，其加載效率主要取決于資源的加載方式（Resource.Load或AssetBundle加載）绞呈、加載量（紋理贸人、網(wǎng)格、材質(zhì)等資源數(shù)據(jù)的大斜ㄇ俊）和資源格式（紋理格式灸姊、音頻格式等）等等。不同的加載方式秉溉、不同的資源格式力惯，其加載效率可謂千差萬別碗誉，所以我們在UWA測評報告中，特別將每種資源的具體使用情況進行展示父晶，以幫助用戶可以立刻查找到問題資源并及時進行改正哮缺。

Instantiate實例化

在場景加載過程中，往往伴隨著大量的Instantiate實例化操作甲喝，比如UI界面實例化尝苇、角色/怪物實例化、場景建筑實例化等等埠胖。在Instantiate實例化時糠溜，引擎底層會查看其相關(guān)的資源是否已經(jīng)被加載，如果沒有直撤，則會先加載其相關(guān)資源非竿，再進行實例化，這其實是大家遇到的大多數(shù)“Instantiate耗時問題”的根本原因谋竖，這也是為什么我們在之前的AssetBundle文章中所提倡的資源依賴關(guān)系打包并進行預(yù)加載红柱，從而來緩解Instantiate實例化時的壓力（關(guān)于AssetBundle資源的加載，則是另一個很大的Story了蓖乘，我們會在以后的AssetBundle加載技術(shù)專題中進行詳細的講解）锤悄。

另一方面，Instantiate實例化的性能開銷還體現(xiàn)在腳本代碼的序列化上嘉抒，如果腳本中需要序列化的信息很多零聚，則Instantiate實例化時的時間亦會很長。最直接的例子就是NGUI众眨，其代碼中存在很多SerializedField標識握牧，從而在實例化時帶來了較多的代碼序列化開銷。因此娩梨，在大家為代碼增加序列化信息時沿腰，這一點是需要大家時刻關(guān)注的。

以上是游戲項目中性能開銷最大的三個模塊狈定，當(dāng)然颂龙，游戲類型的不同、設(shè)計的不同纽什，其他模塊仍然會有較大的CPU占用措嵌。比如，ARPG游戲中的動畫系統(tǒng)和物理系統(tǒng)芦缰，音樂休閑類游戲中的音頻系統(tǒng)和粒子系統(tǒng)等企巢。對此，我們會在后續(xù)的技術(shù)專題中進行詳細的講解让蕾，敬請期待。

四、代碼效率

邏輯代碼在一個較為復(fù)雜的游戲項目中往往占據(jù)較大的性能開銷轻绞。這種情況在MOBA泥彤、ARPG男韧、MMORPG等游戲類型中非常常見。

在項目優(yōu)化過程中，我們經(jīng)常會想知道，到底是哪些函數(shù)占據(jù)了大量的CPU開銷足丢。同時，絕大多數(shù)的項目中其性能開銷都遵循著“二八原則”庇配，即80%的性能開銷都集中在20%的函數(shù)上斩跌。所以，我們在UWA測評報告中將項目中代碼占用的CPU開銷進行統(tǒng)計讨永，不僅可以提供代碼的總體累積CPU占用滔驶，還可以更近一步看到函數(shù)內(nèi)部的性能分配，從而幫助大家更快地定位問題函數(shù)卿闹。

當(dāng)然，我們還希望可以為大家提供更多的代碼性能信息萝快，比如函數(shù)任何一幀中更為詳細的性能分配锻霎、更為準確的截圖信息等等。這些都是我們目前正在努力研發(fā)的功能揪漩，并在后續(xù)版本中提供給大家進行使用旋恼。