手機游戲為什么要做性能優(yōu)化？

數(shù)碼筆記

性能話題應(yīng)該是近兩年手游圈里最熱門的話題之一了。
1 性能優(yōu)化概念

隨著手機游戲開發(fā)管線的不斷成熟，越來越多的事情開始需要專業(yè)化和精細(xì)化，比如幾年前的TA?，F(xiàn)在，手游的性能優(yōu)化逐漸也開始成為一個獨立的崗位，甚至可以和TA、圖形程序員待遇相當(dāng)。這導(dǎo)致的影響就是游戲程序員的分支路線開始呈現(xiàn)多元化。

登錄/注冊后可看大圖

而對于絕大多數(shù)的程序員可能只能走前兩條路線了。相對而言下面這個方向都需要有一定的橫向能力，尤其是管理崗位，對于交際和溝通有著相當(dāng)大的要求。
TA和引擎有一些共同點，都需要豐富的圖形知識，但不同的是TA現(xiàn)在是歸屬在美術(shù)組的，這個崗位是一個偏業(yè)務(wù)向的也就是解決實際項目問題的崗位，另外因為歸屬于美術(shù)組，所以一定程度上TA還偏設(shè)計向。也就是說，一些表現(xiàn)方案應(yīng)該是由Ta進(jìn)行技術(shù)和原型驗證，沒問題之后再由前端程序進(jìn)行接入整合。
而引擎程序員則偏向于架構(gòu)向的。也就是說這些圖程會制定渲染管線，搭建渲染架構(gòu)，這些內(nèi)容往往會脫離具體業(yè)務(wù)，而成為公司/行業(yè)標(biāo)準(zhǔn)的一個部分。
如果要舉個例子的話，可以認(rèn)為圖形程序員是編寫photoShop的崗位，而TA是使用PS做海報和設(shè)計的崗位。最后前端程序員會拿著TA做的海報，根據(jù)實際的張貼需求，打印不同的大小，甚至裁剪其中的一些部分。
當(dāng)然這個比喻不一定恰當(dāng)，但基本可以描述圖程和TA的關(guān)系。
那么接下來就是現(xiàn)階段最火的崗位，性能優(yōu)化了。個人覺得催化這個崗位的主要原因還是因為商業(yè)引擎越來越成熟，手游開發(fā)客戶端的門檻越來越低導(dǎo)致的。當(dāng)然另外一個原因還是因為當(dāng)前國內(nèi)的游戲市場的版號限制，導(dǎo)致越來越多的公司要做出海計劃。既然要出海，那就不能只考慮歐美國家，像東南亞，印度，巴西等比較落后和貧窮的國家也是需要考慮的，甚至很多時候是優(yōu)先考慮的（主要原因還是推廣成本低，導(dǎo)量便宜）。
門檻低導(dǎo)致越來越多的Game Play程序員無法理解商業(yè)引擎的實現(xiàn)原理，甚至培訓(xùn)幾個月就來上崗，寫出來的代碼幾乎是屬于災(zāi)難性的。而出海貧窮地區(qū)則因為手機設(shè)備的落后，低端導(dǎo)致游戲必須要嚴(yán)控性能才有可能在落后國內(nèi)5年的硬件上跑起來。
這個時候必須要有一個人能夠挑起性能這個大梁，達(dá)成一夫當(dāng)關(guān)萬夫莫開的氣勢。所有有性能問題的設(shè)計、代碼或者實現(xiàn)統(tǒng)統(tǒng)在這里被擋回去。但這說的很容易，夠資格勝任的人卻很少。和TA、圖程的專業(yè)知識不一樣，性能崗位需要精通的是引擎和實現(xiàn)。
這就要求：
1 需要對引擎使用有較高的熟練度。這就隱性的要求該崗位人員的從業(yè)和引擎使用年限、項目經(jīng)歷、解決方案和見識、引擎的各種設(shè)置和實現(xiàn)原理等。
2 扎實的基礎(chǔ)和基本功。引擎再好也需要自己寫代碼。如果不了解自己語言的特性、設(shè)計模式、數(shù)據(jù)結(jié)構(gòu)等就沒有辦法檢查除別人代碼里的深層次原因。
有人可能會好奇，難道主程不能做嗎？一般能當(dāng)主程的技術(shù)肯定都還行啊。額，我的結(jié)論是，哪怕主程合格能cover，他也不應(yīng)該去做。因為管理崗和技術(shù)崗是獨立區(qū)分的崗位，它們有不同的崗位職責(zé)。對于主程而言，更多的工作是怎么分配協(xié)調(diào)任務(wù)，怎么保障進(jìn)度，怎么做技術(shù)沉淀和人員梯隊。有機會我們可以專門聊聊主程應(yīng)該做什么。但現(xiàn)在要理解的話，可以打一個簡單的比方，主程好比是班主任/輔導(dǎo)員，班主任首先自己是個老師，當(dāng)然也會教自己擅長的科目，但更多的精力還是放在怎么提高班級整體水平上。
說回性能優(yōu)化這個崗位，我們組里的崗位我設(shè)定的職責(zé)為，不做具體開發(fā)業(yè)務(wù)，只負(fù)責(zé)規(guī)劃、查找、解決項目中的性能問題。也就是什么都不做，又什么都要做。
好了，累死我了，終于能說，什么是性能問題了。
2 性能問題

所有的性能問題都可以歸結(jié)于一句話：硬件受委屈了。
1 它們承擔(dān)了它們這個級別不應(yīng)該有的壓力。 例如，CPU計算壓力過大，GPU的繪制壓力過大，CPU和GPU數(shù)據(jù)交互過大，過頻繁，內(nèi)存消耗太大等等。
但是造成這些硬件委屈的原因則有很多很多種情況。比如，CPU的委屈可能來自于，不合理的代碼循環(huán)，不必要的邏輯運算，頻繁的內(nèi)存申請導(dǎo)致的GC，過多的蒙皮動作，大量的粒子計算，超多的物理模擬，超多、超大的文件加載等等。

登錄/注冊后可看大圖

一核有難，九核圍觀

內(nèi)存的原因可能來自，過大的紋理、資源、文件、數(shù)據(jù)，過多的托管內(nèi)存申請，不恰當(dāng)?shù)膬?nèi)存管理和釋放機制，不恰當(dāng)?shù)木彺婀芾恚^多的SDK和工具引入，冗余的三方代碼和庫，沒有做變體剝離的Shader等等。

登錄/注冊后可看大圖

各個平臺上，內(nèi)存泄露的問題都比較嚴(yán)重

GPU的問題則可能來自于，過多的頂點和三角面，過多的OverDraw，過大的紋理，過復(fù)雜的Shader計算，過多的紋理采樣，復(fù)雜的后處理效果等等。

登錄/注冊后可看大圖

（Upr的GPU頁簽，關(guān)于GPU的一些常用參數(shù)）
2 它們沒有受到應(yīng)有的尊重。 也就是說，本來我可以做的更好，但是由于你不懂我，或者你的失誤，導(dǎo)致我的能力沒有得到最佳發(fā)揮（喂，不是這么用的！）。
最典型的就是DrawCall。大部分都知道DC越高，性能越差，卻有很多人無法真正回答正確DC高為什么會有性能問題（至少我面試過的人里占一大半），實際上它最大的原因是因為GPU需要等待，也就是處于空閑狀態(tài)。
另外一個就是不同類型的GPU紋理格式壓縮，大家或許都知道，要把紋理設(shè)置成ETC1，ETC2，ASTC，PVRTC，卻很少人（我面試過的人中）知道為什么。
還有對于Mono內(nèi)存的申請機制不了解，就不知道為什么要先申請大內(nèi)存的，然后再申請小內(nèi)存等等。
3 性能問題的具體表現(xiàn)

知道了性能問題的根源，也知道造成性能問題的原因，那么怎么樣把它們和具體的表現(xiàn)掛上鉤，從而能夠快速排查性能問題呢？或者說，有關(guān)于性能問題的具體表現(xiàn)是啥，怎么樣才知道項目遇到了性能問題？
這里我把性能問題的具體表現(xiàn)總結(jié)為兩個方面， 卡和慢 。
卡表現(xiàn)在那些地方？當(dāng)你打開某個界面的時候，界面是一頓一頓的從邊緣滑動進(jìn)來，或者打開之后過比較長時間才能加載出來。
進(jìn)入一個場景的時候，loading了很久，進(jìn)度條一直不動,進(jìn)入場景之后，看別人走路跟滑冰一樣。
手機發(fā)燙，耗電量急劇增加，運行的好好的突然ANR一下。
一到團戰(zhàn)閃退了。要么就是卡死不動了。
更極端一點，場景其他地方都很流暢，只要一到這個水坑邊上就掉幀。
更早的時候，流量資費沒降下來之前，數(shù)據(jù)流量也會算作性能的一個部分。
但這里要提一嘴，并不是只要遇到上述情況就歸于性能問題。游戲開發(fā)一般會有一個參照的適配機型，分為高中低配三個檔次。中配就是要能夠展現(xiàn)出所有項目預(yù)期的設(shè)計和效果。而高配會在中配的基礎(chǔ)上適當(dāng)調(diào)高效果和幀率，比如增加描邊，更好更好的紋理，更多更華麗的特效等等。而低配機型，我們一般只保證功能，不保證效果。
那些比低配機型更低的，就不會考慮了，能玩你就將就玩，不能玩請你換機器。
也就是說，很多的性能其實是和參照機型掛鉤的。舉個例子，PSS（實際使用的物理內(nèi)存）在中配機型上占800M，2020年的中配機1500-2000元，內(nèi)存怎么也的有個4G了，哪怕只有2G壓力也不大。所以這個指標(biāo)我們再中配機型上是能接受的。
但是，這個指標(biāo)在我們的低配機型上就不能接受，我們現(xiàn)在的低配機型可能就是東南亞的平均水平，所以有可能會它會跑在內(nèi)存只有1G的低端機器上。800M的PSS極容易造成閃退。這個時候，我們的性能優(yōu)化就需要上場，針對低端機型做內(nèi)存方面的優(yōu)化。
這些優(yōu)化的策略有的是基于整體的，也就是說，高中低配都受用，有些僅僅是針對機型的，比如換一些精度更低的紋理，減少一些不必要的裝飾加載，限制同屏顯示的內(nèi)容等等，具體手段需要因項目而異。
4 工具和服務(wù)

抓取性能問題的工具有很多，最常用的是Unity自帶的兩個。

登錄/注冊后可看大圖

Porfiler可以調(diào)試很多模塊的參數(shù)，但我基本上用它抓CPU和內(nèi)存。另外要說一下的是，因為Editor本身會占用很多額外消耗，所以直接用編輯器調(diào)試需要自己能排除掉Editor自身的干擾，也就是說你看的問題可能在實際機器上并沒有，又或者沒有這么凸顯。最準(zhǔn)確的方式就是用真機調(diào)試，但大多時候性能點并不會轉(zhuǎn)移，只是精確度的問題，所以開發(fā)時候用編輯器調(diào)試定位問題，然后修改之后在真機驗證。
自帶的第二工具是FrameDebug

登錄/注冊后可看大圖

這是用來調(diào)試渲染的，在這里可以逐幀的調(diào)試渲染，看到每一幀的渲染數(shù)據(jù)。比較適用于有一定圖形知識和能力的人，比如TA和懂圖形知識的程序員。他們可以在這里查看到，實際的渲染情況是否超出了預(yù)期，比如該合批的沒有合批，原因是啥。
另外也建議一些UI經(jīng)驗豐富的人學(xué)會查看UI層面的DrawCall情況，從而減輕UI部分的渲染壓力。
另外也可以給大家推薦一下UWA的幾個測試工具。

登錄/注冊后可看大圖

這些工具都是基于真機運行收集的數(shù)據(jù)，準(zhǔn)確度高，維度也多。尤其是GOT，如果團隊有性能解讀能力，這個工具的性價比是最高的，一次付費之后可以一直使用。
UWA是很老牌的性能優(yōu)化服務(wù)商，做的時間久，經(jīng)驗豐富。除了本地測試產(chǎn)品之外，他們也有云端測試產(chǎn)品和駐場服務(wù)。

登錄/注冊后可看大圖

云測試就是你們提交包給他們的網(wǎng)站，他們會使用真人幫助測試，然后生成一份性能報告。性能測試報告大概長下面這樣子：

登錄/注冊后可看大圖

報告分為免費報告和專業(yè)報告。專業(yè)報告參數(shù)更多，更全面，會有專門的專家負(fù)責(zé)解讀。但免費報告他們其實服務(wù)的也很好，基本上會基于報告的數(shù)據(jù)給與一些意見和建議。
第二個是Unity自己的UPR服務(wù)。這個是目前Unity正在做的方向，大概也是未來侑虎強有力的競爭對手。他們的測試方式和侑虎略有不同，侑虎是提交包之后，相關(guān)人員對接確定哪些地方重點測試，然后由侑虎人員去跑然后生成報告，也就是托管測試。而UPR是給了兩種工具，一種是基于PC的，一種是真機APP的，你可以通過這兩個工具自己去跑，然后上傳測試數(shù)據(jù)，網(wǎng)站后臺生成報告數(shù)據(jù)。
UPR的報告沒有分免費和付費，但同樣也不提供對接和基礎(chǔ)解讀，如果要解讀需要付費（和侑虎付費模式一樣）。另外還有一點，UPR現(xiàn)在是全免費，不限次數(shù)的。UWA的免費每個月一次并且提供基礎(chǔ)解讀。所以，我覺得大家選擇的時候，要根據(jù)自己團隊的能力，看看選哪個更好。

登錄/注冊后可看大圖

第三個是Unity和UWA都有的駐場優(yōu)化服務(wù)，主要就是給沒有能力做優(yōu)化的團隊，查找、分析項目問題，以入駐的形式，幫項目把性能點擺平，這個我沒用過，在次就不多介紹了。
除了Unity自有的工具和第三方工具之外，也可以根據(jù)需要自己創(chuàng)建工具?；赟criptImporter，我們可以寫很多自動化監(jiān)測和修改的腳本。同時也可以利用Unity Editor下的一些API完成對資源的檢測。下面就是我們團隊自己寫的針對各種美術(shù)資源或者的查詢和監(jiān)測。

登錄/注冊后可看大圖

說到這，我說個比較有意思的工具，因為要做低端機的分段適配，我們需要有一套算法來推測機型屬于哪一檔。組里的小伙伴很給力，自己寫了爬蟲，爬了市面上大部分安卓機器的型號和數(shù)據(jù)，然后做了一個工具和評分提供給策劃和QA，讓他們能夠快速的判別一個機器屬于哪一檔。

登錄/注冊后可看大圖

登錄/注冊后可看大圖

5 結(jié)尾

性能的話題暫時先聊這么多，我大概會寫一個基于性能的系列，會詳細(xì)聊聊各種性能相關(guān)的問題。另外，推薦一下本人的教程匯總：
希望能對一部分人有所幫助。

-----------------------------

林子疆

性能話題應(yīng)該是近兩年手游圈里最熱門的話題之一了。
1 性能優(yōu)化概念

隨著手機游戲開發(fā)管線的不斷成熟，越來越多的事情開始需要專業(yè)化和精細(xì)化，比如幾年前的TA?，F(xiàn)在，手游的性能優(yōu)化逐漸也開始成為一個獨立的崗位，甚至可以和TA、圖形程序員待遇相當(dāng)。這導(dǎo)致的影響就是游戲程序員的分支路線開始呈現(xiàn)多元化。

登錄/注冊后可看大圖

而對于絕大多數(shù)的程序員可能只能走前兩條路線了。相對而言下面這個方向都需要有一定的橫向能力，尤其是管理崗位，對于交際和溝通有著相當(dāng)大的要求。
TA和引擎有一些共同點，都需要豐富的圖形知識，但不同的是TA現(xiàn)在是歸屬在美術(shù)組的，這個崗位是一個偏業(yè)務(wù)向的也就是解決實際項目問題的崗位，另外因為歸屬于美術(shù)組，所以一定程度上TA還偏設(shè)計向。也就是說，一些表現(xiàn)方案應(yīng)該是由Ta進(jìn)行技術(shù)和原型驗證，沒問題之后再由前端程序進(jìn)行接入整合。
而引擎程序員則偏向于架構(gòu)向的。也就是說這些圖程會制定渲染管線，搭建渲染架構(gòu)，這些內(nèi)容往往會脫離具體業(yè)務(wù)，而成為公司/行業(yè)標(biāo)準(zhǔn)的一個部分。
如果要舉個例子的話，可以認(rèn)為圖形程序員是編寫photoShop的崗位，而TA是使用PS做海報和設(shè)計的崗位。最后前端程序員會拿著TA做的海報，根據(jù)實際的張貼需求，打印不同的大小，甚至裁剪其中的一些部分。
當(dāng)然這個比喻不一定恰當(dāng)，但基本可以描述圖程和TA的關(guān)系。
那么接下來就是現(xiàn)階段最火的崗位，性能優(yōu)化了。個人覺得催化這個崗位的主要原因還是因為商業(yè)引擎越來越成熟，手游開發(fā)客戶端的門檻越來越低導(dǎo)致的。當(dāng)然另外一個原因還是因為當(dāng)前國內(nèi)的游戲市場的版號限制，導(dǎo)致越來越多的公司要做出海計劃。既然要出海，那就不能只考慮歐美國家，像東南亞，印度，巴西等比較落后和貧窮的國家也是需要考慮的，甚至很多時候是優(yōu)先考慮的（主要原因還是推廣成本低，導(dǎo)量便宜）。
門檻低導(dǎo)致越來越多的Game Play程序員無法理解商業(yè)引擎的實現(xiàn)原理，甚至培訓(xùn)幾個月就來上崗，寫出來的代碼幾乎是屬于災(zāi)難性的。而出海貧窮地區(qū)則因為手機設(shè)備的落后，低端導(dǎo)致游戲必須要嚴(yán)控性能才有可能在落后國內(nèi)5年的硬件上跑起來。
這個時候必須要有一個人能夠挑起性能這個大梁，達(dá)成一夫當(dāng)關(guān)萬夫莫開的氣勢。所有有性能問題的設(shè)計、代碼或者實現(xiàn)統(tǒng)統(tǒng)在這里被擋回去。但這說的很容易，夠資格勝任的人卻很少。和TA、圖程的專業(yè)知識不一樣，性能崗位需要精通的是引擎和實現(xiàn)。
這就要求：
1 需要對引擎使用有較高的熟練度。這就隱性的要求該崗位人員的從業(yè)和引擎使用年限、項目經(jīng)歷、解決方案和見識、引擎的各種設(shè)置和實現(xiàn)原理等。
2 扎實的基礎(chǔ)和基本功。引擎再好也需要自己寫代碼。如果不了解自己語言的特性、設(shè)計模式、數(shù)據(jù)結(jié)構(gòu)等就沒有辦法檢查除別人代碼里的深層次原因。
有人可能會好奇，難道主程不能做嗎？一般能當(dāng)主程的技術(shù)肯定都還行啊。額，我的結(jié)論是，哪怕主程合格能cover，他也不應(yīng)該去做。因為管理崗和技術(shù)崗是獨立區(qū)分的崗位，它們有不同的崗位職責(zé)。對于主程而言，更多的工作是怎么分配協(xié)調(diào)任務(wù)，怎么保障進(jìn)度，怎么做技術(shù)沉淀和人員梯隊。有機會我們可以專門聊聊主程應(yīng)該做什么。但現(xiàn)在要理解的話，可以打一個簡單的比方，主程好比是班主任/輔導(dǎo)員，班主任首先自己是個老師，當(dāng)然也會教自己擅長的科目，但更多的精力還是放在怎么提高班級整體水平上。
說回性能優(yōu)化這個崗位，我們組里的崗位我設(shè)定的職責(zé)為，不做具體開發(fā)業(yè)務(wù)，只負(fù)責(zé)規(guī)劃、查找、解決項目中的性能問題。也就是什么都不做，又什么都要做。
好了，累死我了，終于能說，什么是性能問題了。
2 性能問題

所有的性能問題都可以歸結(jié)于一句話：硬件受委屈了。
1 它們承擔(dān)了它們這個級別不應(yīng)該有的壓力。 例如，CPU計算壓力過大，GPU的繪制壓力過大，CPU和GPU數(shù)據(jù)交互過大，過頻繁，內(nèi)存消耗太大等等。
但是造成這些硬件委屈的原因則有很多很多種情況。比如，CPU的委屈可能來自于，不合理的代碼循環(huán)，不必要的邏輯運算，頻繁的內(nèi)存申請導(dǎo)致的GC，過多的蒙皮動作，大量的粒子計算，超多的物理模擬，超多、超大的文件加載等等。

登錄/注冊后可看大圖

一核有難，九核圍觀

內(nèi)存的原因可能來自，過大的紋理、資源、文件、數(shù)據(jù)，過多的托管內(nèi)存申請，不恰當(dāng)?shù)膬?nèi)存管理和釋放機制，不恰當(dāng)?shù)木彺婀芾恚^多的SDK和工具引入，冗余的三方代碼和庫，沒有做變體剝離的Shader等等。

登錄/注冊后可看大圖

各個平臺上，內(nèi)存泄露的問題都比較嚴(yán)重

GPU的問題則可能來自于，過多的頂點和三角面，過多的OverDraw，過大的紋理，過復(fù)雜的Shader計算，過多的紋理采樣，復(fù)雜的后處理效果等等。

登錄/注冊后可看大圖

（Upr的GPU頁簽，關(guān)于GPU的一些常用參數(shù)）
2 它們沒有受到應(yīng)有的尊重。 也就是說，本來我可以做的更好，但是由于你不懂我，或者你的失誤，導(dǎo)致我的能力沒有得到最佳發(fā)揮（喂，不是這么用的！）。
最典型的就是DrawCall。大部分都知道DC越高，性能越差，卻有很多人無法真正回答正確DC高為什么會有性能問題（至少我面試過的人里占一大半），實際上它最大的原因是因為GPU需要等待，也就是處于空閑狀態(tài)。
另外一個就是不同類型的GPU紋理格式壓縮，大家或許都知道，要把紋理設(shè)置成ETC1，ETC2，ASTC，PVRTC，卻很少人（我面試過的人中）知道為什么。
還有對于Mono內(nèi)存的申請機制不了解，就不知道為什么要先申請大內(nèi)存的，然后再申請小內(nèi)存等等。
3 性能問題的具體表現(xiàn)

知道了性能問題的根源，也知道造成性能問題的原因，那么怎么樣把它們和具體的表現(xiàn)掛上鉤，從而能夠快速排查性能問題呢？或者說，有關(guān)于性能問題的具體表現(xiàn)是啥，怎么樣才知道項目遇到了性能問題？
這里我把性能問題的具體表現(xiàn)總結(jié)為兩個方面， 卡和慢 。
卡表現(xiàn)在那些地方？當(dāng)你打開某個界面的時候，界面是一頓一頓的從邊緣滑動進(jìn)來，或者打開之后過比較長時間才能加載出來。
進(jìn)入一個場景的時候，loading了很久，進(jìn)度條一直不動,進(jìn)入場景之后，看別人走路跟滑冰一樣。
手機發(fā)燙，耗電量急劇增加，運行的好好的突然ANR一下。
一到團戰(zhàn)閃退了。要么就是卡死不動了。
更極端一點，場景其他地方都很流暢，只要一到這個水坑邊上就掉幀。
更早的時候，流量資費沒降下來之前，數(shù)據(jù)流量也會算作性能的一個部分。
但這里要提一嘴，并不是只要遇到上述情況就歸于性能問題。游戲開發(fā)一般會有一個參照的適配機型，分為高中低配三個檔次。中配就是要能夠展現(xiàn)出所有項目預(yù)期的設(shè)計和效果。而高配會在中配的基礎(chǔ)上適當(dāng)調(diào)高效果和幀率，比如增加描邊，更好更好的紋理，更多更華麗的特效等等。而低配機型，我們一般只保證功能，不保證效果。
那些比低配機型更低的，就不會考慮了，能玩你就將就玩，不能玩請你換機器。
也就是說，很多的性能其實是和參照機型掛鉤的。舉個例子，PSS（實際使用的物理內(nèi)存）在中配機型上占800M，2020年的中配機1500-2000元，內(nèi)存怎么也的有個4G了，哪怕只有2G壓力也不大。所以這個指標(biāo)我們再中配機型上是能接受的。
但是，這個指標(biāo)在我們的低配機型上就不能接受，我們現(xiàn)在的低配機型可能就是東南亞的平均水平，所以有可能會它會跑在內(nèi)存只有1G的低端機器上。800M的PSS極容易造成閃退。這個時候，我們的性能優(yōu)化就需要上場，針對低端機型做內(nèi)存方面的優(yōu)化。
這些優(yōu)化的策略有的是基于整體的，也就是說，高中低配都受用，有些僅僅是針對機型的，比如換一些精度更低的紋理，減少一些不必要的裝飾加載，限制同屏顯示的內(nèi)容等等，具體手段需要因項目而異。
4 工具和服務(wù)

抓取性能問題的工具有很多，最常用的是Unity自帶的兩個。

登錄/注冊后可看大圖

Porfiler可以調(diào)試很多模塊的參數(shù)，但我基本上用它抓CPU和內(nèi)存。另外要說一下的是，因為Editor本身會占用很多額外消耗，所以直接用編輯器調(diào)試需要自己能排除掉Editor自身的干擾，也就是說你看的問題可能在實際機器上并沒有，又或者沒有這么凸顯。最準(zhǔn)確的方式就是用真機調(diào)試，但大多時候性能點并不會轉(zhuǎn)移，只是精確度的問題，所以開發(fā)時候用編輯器調(diào)試定位問題，然后修改之后在真機驗證。
自帶的第二工具是FrameDebug

登錄/注冊后可看大圖

這是用來調(diào)試渲染的，在這里可以逐幀的調(diào)試渲染，看到每一幀的渲染數(shù)據(jù)。比較適用于有一定圖形知識和能力的人，比如TA和懂圖形知識的程序員。他們可以在這里查看到，實際的渲染情況是否超出了預(yù)期，比如該合批的沒有合批，原因是啥。
另外也建議一些UI經(jīng)驗豐富的人學(xué)會查看UI層面的DrawCall情況，從而減輕UI部分的渲染壓力。
另外也可以給大家推薦一下UWA的幾個測試工具。

登錄/注冊后可看大圖

這些工具都是基于真機運行收集的數(shù)據(jù)，準(zhǔn)確度高，維度也多。尤其是GOT，如果團隊有性能解讀能力，這個工具的性價比是最高的，一次付費之后可以一直使用。
UWA是很老牌的性能優(yōu)化服務(wù)商，做的時間久，經(jīng)驗豐富。除了本地測試產(chǎn)品之外，他們也有云端測試產(chǎn)品和駐場服務(wù)。

登錄/注冊后可看大圖

云測試就是你們提交包給他們的網(wǎng)站，他們會使用真人幫助測試，然后生成一份性能報告。性能測試報告大概長下面這樣子：

登錄/注冊后可看大圖

報告分為免費報告和專業(yè)報告。專業(yè)報告參數(shù)更多，更全面，會有專門的專家負(fù)責(zé)解讀。但免費報告他們其實服務(wù)的也很好，基本上會基于報告的數(shù)據(jù)給與一些意見和建議。
第二個是Unity自己的UPR服務(wù)。這個是目前Unity正在做的方向，大概也是未來侑虎強有力的競爭對手。他們的測試方式和侑虎略有不同，侑虎是提交包之后，相關(guān)人員對接確定哪些地方重點測試，然后由侑虎人員去跑然后生成報告，也就是托管測試。而UPR是給了兩種工具，一種是基于PC的，一種是真機APP的，你可以通過這兩個工具自己去跑，然后上傳測試數(shù)據(jù)，網(wǎng)站后臺生成報告數(shù)據(jù)。
UPR的報告沒有分免費和付費，但同樣也不提供對接和基礎(chǔ)解讀，如果要解讀需要付費（和侑虎付費模式一樣）。另外還有一點，UPR現(xiàn)在是全免費，不限次數(shù)的。UWA的免費每個月一次并且提供基礎(chǔ)解讀。所以，我覺得大家選擇的時候，要根據(jù)自己團隊的能力，看看選哪個更好。

登錄/注冊后可看大圖

第三個是Unity和UWA都有的駐場優(yōu)化服務(wù)，主要就是給沒有能力做優(yōu)化的團隊，查找、分析項目問題，以入駐的形式，幫項目把性能點擺平，這個我沒用過，在次就不多介紹了。
除了Unity自有的工具和第三方工具之外，也可以根據(jù)需要自己創(chuàng)建工具?；赟criptImporter，我們可以寫很多自動化監(jiān)測和修改的腳本。同時也可以利用Unity Editor下的一些API完成對資源的檢測。下面就是我們團隊自己寫的針對各種美術(shù)資源或者的查詢和監(jiān)測。

登錄/注冊后可看大圖

說到這，我說個比較有意思的工具，因為要做低端機的分段適配，我們需要有一套算法來推測機型屬于哪一檔。組里的小伙伴很給力，自己寫了爬蟲，爬了市面上大部分安卓機器的型號和數(shù)據(jù)，然后做了一個工具和評分提供給策劃和QA，讓他們能夠快速的判別一個機器屬于哪一檔。

登錄/注冊后可看大圖

登錄/注冊后可看大圖

5 結(jié)尾

性能的話題暫時先聊這么多，我大概會寫一個基于性能的系列，會詳細(xì)聊聊各種性能相關(guān)的問題。另外，推薦一下本人的教程匯總：
放牛的星星：[教程匯總+持續(xù)更新]Unity從入門到入土——收藏這一篇就夠了希望能對一部分人有所幫助。

你的微笑

提供一個與眾不同的視角吧
國內(nèi)很多公司并不重視技術(shù)積累，但是重視性能優(yōu)化
所以很多想走技術(shù)路線的人會鼓動公司做性能優(yōu)化
公司也容易接受

不要談什么生產(chǎn)力，造輪子，砸?guī)讉€月進(jìn)去
就說，你的產(chǎn)品多爛的機器能跑吧，市場運營老板都愛聽這個

國內(nèi)的游戲性能優(yōu)化，是把很多公司產(chǎn)品引上技術(shù)正途的一個通道

這方面做起來的公司，典型的是UWA。你可以想象一下，如果UWA是個Unity，Unreal，或者小些級別的，比如當(dāng)年的微云木瓜之類的，在國內(nèi)會遇到什么情況……