這里暫且討論使用Mac對(duì)iOS設(shè)備進(jìn)行調(diào)試的方法。至于Android平臺(tái)，會(huì)有細(xì)節(jié)但不是非常重要的不同。
為什么需要聯(lián)機(jī)Profile？
大部分情況，直接在工作機(jī)（PC、Mac）用Unity針對(duì)工程進(jìn)行Profile就能查出性能的瓶頸。
但在不同的設(shè)備會(huì)有不同的性能表現(xiàn)、甚至一些設(shè)備由于硬件設(shè)計(jì)的原因，導(dǎo)致一些性能瓶頸只有在特定設(shè)備上才會(huì)表現(xiàn)出來。
針對(duì)這些設(shè)備相關(guān)的性能問題，需要進(jìn)行聯(lián)機(jī)Profile。
Profile的手段概述
iOS設(shè)備通過USB連接Mac后，對(duì)其進(jìn)行Profile手段有三種：
-
Unity進(jìn)行Profile
unity_profile -
XCode進(jìn)行Profile
xcode_profile -
XCode在debug模式時(shí)的“GPU Report”
xcode_fps
3種Profile手段的特點(diǎn)
上面的3種Profile有以下特點(diǎn)：
- Unity或者XCode的profile能準(zhǔn)確地顯示各項(xiàng)功能/函數(shù)消耗。
- 但這兩種方式本身會(huì)引起大量的profile overhead，會(huì)引起設(shè)備上的“虛卡”，所以它倆的所描述的更多是功能/函數(shù)間的相對(duì)大小關(guān)系。
- 建議優(yōu)先使用Unity的Profile，因?yàn)樗娘@示信息比XCode的Profile更加實(shí)用。
- XCode的“GPU Report”開銷較小，數(shù)據(jù)能真實(shí)地反應(yīng)設(shè)備運(yùn)行情況，所以能收集絕對(duì)的整體消耗大小。
3中Profile手段的具體步驟
Unity進(jìn)行Profile準(zhǔn)備步驟
- 通過USB連接調(diào)試設(shè)備和Mac
在Build Settings里如下圖選擇“Development Build”和“Autoconnect Profiler”，然后點(diǎn)擊“Build”或者“Build And Run”
- 構(gòu)建中途，Unity會(huì)調(diào)用XCode自動(dòng)進(jìn)行編譯、自動(dòng)進(jìn)行運(yùn)行。
-
設(shè)備運(yùn)行我們的app了之后，在Unity打開Profiler面板，并且如下圖選擇“iOS profiler over USB”，也就開始進(jìn)行profile了。
unity_profile - Unity進(jìn)行Profile準(zhǔn)備步驟結(jié)束。
XCode進(jìn)行Profile
- 通過USB連接調(diào)試設(shè)備和Mac。
- 確保調(diào)試設(shè)備能夠進(jìn)行調(diào)試你的app
關(guān)于Apple Developer和Provisioning Profiles
* 一個(gè)apple developer有一個(gè)apple id
* 這個(gè)apple id下有不同的證書（certificates）。證書證明了這個(gè)apple id有能力進(jìn)行軟件的開發(fā)、分發(fā)。
* 這個(gè)apple id下有不同的app，每個(gè)app對(duì)應(yīng)一個(gè)app id（也稱bundle id）。表明這個(gè)apple id正在開發(fā)、分發(fā)哪些app。
* 這個(gè)apple id下有不同的設(shè)備，每個(gè)設(shè)備對(duì)應(yīng)一個(gè)設(shè)備id。表明這個(gè)apple id關(guān)聯(lián)了哪些設(shè)備。
* 這個(gè)apple id下有不同的Provisioning Profiles。一個(gè)證書id、一個(gè)app id和一個(gè)設(shè)備id列表，組成了一個(gè)Provisioning Profiles。意思是，“因?yàn)橛辛诉@個(gè)Provisioning Profiles，我可以用這些設(shè)備來調(diào)試這個(gè)app”。
所以，要成功讓XCode連上你的設(shè)備并調(diào)試你的app，你必須擁有正確的Provisioning Profile。
更多可以參考Apple Developer官網(wǎng)里的“Member Center”。
- 在Unity進(jìn)行Build了之后
-
在XCode打開相應(yīng)的工程，如下圖點(diǎn)擊Product>Profile
xcode_profile_png - XCode編譯完了之后，會(huì)打開“Instruments”正式開始Profile調(diào)試
- 可以通過“Instruments”里面的“Library“來選擇不同維度的Profile，比如“Activity Monitor”可以監(jiān)控設(shè)備的各個(gè)進(jìn)程情況、“Core Animation”可以監(jiān)控幀數(shù)、“OpenGL ES Analyzer”可以監(jiān)控圖形API層面的調(diào)度情況。
- XCode進(jìn)行Profile準(zhǔn)備步驟結(jié)束。
XCode進(jìn)行“GPU Report”
大體的準(zhǔn)備規(guī)則和上面的“XCode進(jìn)行Profile”差不多，主要差別在后面幾步：
- Unity輸出XCode工程后，在XCode打開相應(yīng)的工程，直接點(diǎn)擊“播放鍵”三角形；
-
當(dāng)設(shè)備自動(dòng)運(yùn)行app后，點(diǎn)擊下圖左部的debug_navigator
按鈕
xcode_fps - XCode進(jìn)行“GPU Report”準(zhǔn)備步驟結(jié)束。
Profile的方法論
如何找到性能瓶頸
項(xiàng)目乃至人生，都是一個(gè)選擇、試錯(cuò)、總結(jié)，再選擇、再試錯(cuò)、再總結(jié)的循環(huán)過程。這個(gè)過程并非白費(fèi)，而是提高自己的經(jīng)驗(yàn)和能力，減少之后選擇錯(cuò)誤的幾率。
通過Profile找出性能瓶頸的通用步驟如下：
- 通過功能Profile統(tǒng)計(jì)列表，找出占用CPU時(shí)間/GPU時(shí)間最多的“瓶頸功能”。注意一幀所消耗的時(shí)間=Max(CPU時(shí)間, GPU時(shí)間），而并非它們的和；
- 如果這個(gè)“瓶頸功能”是腳本函數(shù)等具體的、熟悉的功能，則已經(jīng)確切找到性能瓶頸，步驟結(jié)束。
- 如果這個(gè)“瓶頸功能”是不具體的（比如“引擎渲染透明物體”、“引擎渲染cull預(yù)處理”就是不具體的），則繼續(xù)執(zhí)行以下“廣度遍歷嘗試”步驟:
- 對(duì)游戲以不同維度進(jìn)行拆分，以達(dá)到不同功能維度之間可以不相干地切換“ON/OFF”狀態(tài)。注意，選擇哪一種維度進(jìn)行拆分是關(guān)鍵的；
- 進(jìn)行多次嘗試，每次嘗試只有一個(gè)維度在“ON”狀態(tài)、其他維度在“OFF”狀態(tài)；
- 統(tǒng)計(jì)眾多嘗試中，最影響性能的維度A；
- 將維度A進(jìn)行子劃分，重復(fù)第4步，直到找到確切性能瓶頸。
- 如果維度A優(yōu)化掉后效果依然不達(dá)標(biāo)，則重復(fù)到第1步。
找到性能瓶頸后該怎么處理
處理方法可以有以下方法：
- 無損處理：進(jìn)行優(yōu)化，讓性能瓶頸優(yōu)化成在任何情況下都不出現(xiàn)。比如算法優(yōu)化、內(nèi)存訪問優(yōu)化等。
- 有損處理：可能受限于運(yùn)行環(huán)境，無損處理不可能完成，這需要有損地進(jìn)行處理，讓性能瓶頸在特定情況下才不出現(xiàn)。比如Camera距離LOD、設(shè)備功能LOD等。
具體Profile案例（Killer Project）
2014-08-10
問題
策劃要求敵人批量刷出至少15個(gè)，但在iPhone4上，15個(gè)敵人已經(jīng)很卡。
目標(biāo)
出現(xiàn)瓶頸的設(shè)備：iPhone4。目標(biāo)幀率30fps，所以目標(biāo)幀時(shí)間為33.33ms。考慮到iPhone4是低端機(jī)型，允許偶爾降到20fps，所以允許幀時(shí)間偶爾達(dá)到50ms。
Profile步驟
使用Unity進(jìn)行聯(lián)機(jī)Profile，發(fā)現(xiàn)渲染透明物體是性能瓶頸。
嘗試過把場景里的透明物體都去掉，效果不明顯
所以依次進(jìn)行了以下“ON/OFF”的嘗試。除了尋找真正瓶頸透明渲染之外，中間還輸出了其他的結(jié)論點(diǎn)
|特性|幀數(shù)|CPU時(shí)間|GPU時(shí)間|結(jié)論|可能美術(shù)解決方案|可能程序解決方案
|--|--|--|--|
|場景OFF、15小兵|12|80ms|39.7ms|CPU瓶頸：小兵占用過多CPU；小兵刷出時(shí)依然占用較大CPU|減少小兵骨骼；減少小兵動(dòng)畫幀數(shù)；|減少小兵trigger節(jié)點(diǎn)；場景加載后進(jìn)入場景前，進(jìn)行小兵在SpawnPool里的預(yù)創(chuàng)建
|小兵OFF、場景|29|29.8ms|33.5ms|無瓶頸：madfinger的天空盒效率甚高；|無|無
|小兵OFF、場景
去除所有shadow cast|30|23ms|32ms|去除shadow cast/receive可以較好提高CPU效率|需要給mesh都去掉shaodw cast/receive|無
|場景、15小兵|6|180ms；|176ms|最初情況。場景單獨(dú)OFF沒問題、小兵單獨(dú)OFF問題不大，但他們同時(shí)出現(xiàn)卻有大問題。 |見下面比較方案 |見下面比較方案
|場景、15小兵（無陰影）|15|64ms|43ms|一當(dāng)加上場景就卡的原因是，小兵需要投影圓形陰影到場景 | 無|程序進(jìn)行設(shè)備LOD，當(dāng)是低端機(jī)的時(shí)候，需要去掉所有blob shadow projector
結(jié)論，敵人腳下的Blob shadow projector陰影是真正的透明渲染瓶頸所在，可以采取設(shè)備LOD，在iPhone4上直接去除掉這個(gè)功能。
可以發(fā)現(xiàn)盡管去掉陰影后，效率還是無法達(dá)標(biāo)，所以需要再重投進(jìn)行一次profile。
