本文由WeTest質量開放平臺團隊 發表於雲+社區專欄

作者：申江濤，騰訊互娛客戶端工程師

商業轉載請聯系騰訊WeTest獲得授權，非商業轉載請註明出處。

WeTest 導讀

加入項目組的這段時間主要是承擔性能優化這塊的工作，同時也會去實現一些場景材質、特效材質以及工具。今天就性能優化這塊分享一下個人的經驗。

設備等級劃分

設備等級劃分是一切優化，LOD策略的前提。

最新的iPhoneX A11 GPU性能直逼筆記本的集成顯卡，要照顧三四線的小朋友，紅米1你也得想辦法支持。

畫質選項高中低，遊戲第一次啟動通過設備硬件配置將設備匹配一個默認畫質，匹配依據可以按照CPU,GPU,內存等，也可以根據遊戲類型做一些特殊處理，每一檔選個代表機器，CPU,GPU性能最好心理有數，可以參考下CPU的天梯1和GPU的天梯2，想拿詳細數據的自己寫測試案例跑。

默認畫質匹配最好是基於配置文件的，這樣即使上線後發現匹配規則有問題或者設備更新換代了想優化匹配規則也可以動過熱更來刷新。

為滿足美術大大們的追求，可以在高畫質的基礎上再劃分一個超高配。

設備等級劃分之後，就可以做一些LOD策略了，一定要做的就是劃分各種特效的級別，其次場景最好也做一下，有條件的UI元素也做一下，對於非核心信息的UI可以在低配機隱藏。

關於Shader LOD的做法有在這個回答5裏面提到，這裏就不贅述了。

優化工具

磨刀不誤砍柴工，熟練掌握profile工具絕對是打開優化之門的第一步。

Unity Profile

p1.jpg

作為最簡單也是最實用的Profiler,即使是不做優化的同學也最好學會如何使用。它能夠非常方便地分析出當前的CPU熱點。

很多萌新會遇到無法手機連Profiler的問題，如果你也遇到了，請確定下面幾個點（假設連Android手機）

1． 手機是開發者模式，且在cmd中輸入adb devices能看到自己的設備

2． 配置了Android SDK

3． 編譯的是develop build版本

4． Unity當前是Android工程

5． 如果不是在本機構建的，需要在cmd中輸入 adb forward tcp:54999 localabstract:Unity-xxxx , xxxx是遊戲的包名。

新版本Unity集成了FrameDebugger 和新的內存快照工具，更方便了。

在不開Deep Profile的情況下，看到的消耗比較粗略，很難定位具體的消耗，打開DeepProfile能看到比較深的函數堆棧，但是會有一些消耗，不過在可以接受的範圍之內。

移動設備上沒法開Deep。

通常遇到的一個問題是手機上的Profile結果和PC上的結果不一致，解決方案如下

一切以移動設備為準，希望詳細定位的話可以選擇用Profiler.Begin打樁，或者在PC上開Deep Profile找到對應的位置，展開詳細的堆棧來定位。

Adreno Profiler

p2.jpg

蠻好用的一個Android平臺的GPU Profiler，之前很多人用來提取手遊的資源，但是已經被高通拋棄了，已停止更新支持一些老的高通GPU的設備，這邊確定好用的是紅米 Note 1.

如果能找到可以用的設備可以，建議還是可以連一下看看，還是能看到很多東西的：DC數量，繪制順序，渲染shader，動態修改shader看效果，貼圖格式…

這個東西除了看性能還可以用來查一些平臺相關的渲染錯誤。

XCode

首先你要有臺Mac以及不算太老的ios設備。

首先要去Apple 申請一個免費的開發者賬號，然後從Unity構建一個Xcode工程，連上真機運行。

p3.jpg

相對於Adreno, Xcode顯得專業很多，功能更加強大，最重要的是，可以看渲染耗時！這對於分析GPU熱點非常有幫助。

CPU時間顯示一直為0，不知道試Unity的bug還是XCode的Bug。

Instrument可以看函數耗時。

備選

--

Mali Graphic Debugger：只能用於Mali的GPU, 看上去很厲害，4.X從來沒有連接成功過， Unity5.X的集成稍微友好一些，還沒有深入研究。

Snapdragon Profiler：很卡，只能用於高端機，只能用於Android 6.0以上的系統，年底出了新版本，還可以。

Unity Frame Debugger：5.X以上才有，很方便，沒詳細研究。

WeTest - UPA：和Unity官方合作的客戶端性能測試工具，無需ROOT和接入SDK，挺方便。

優化流程

如果想在後期輕松一些，美術的規範一定要定好，同時要有配套的資源檢測，掃描工具。在定一些大的技術方案之前，各項消耗盡量做到心理有數，如果不確定就做一些實驗，數據不會能騙人。

遇到上線前三天發現遊戲只有十幾幀的，這就只能砍效果了。

程序ic方面主要是對C#的語言底層機制的熟悉程度以及對數據結構的理解，一些明顯有性能問題的寫法要規避。

項目上線前兩周左右就要開始對版本進行一些性能評估。高中低三檔機的幀率，內存，耗電等都需要有數據。接下來就是

發現熱點 -> 優化 ->繼續發現熱點->繼續優化 –>繼續…

這個過程肯定是沒法由優化的人一個人搞定，最好是進行完一輪Profile之後，把需要優化的點記錄下來，然後通過tapd等工具將優化任務派給對應的美術/程序同學，並去推進優化叠代，這其實牽涉到很多溝通工作。

關於GC

GC方面的優化很重要，原則就是任何大於20B的GC都值得被註意。GC的優化比較瑣碎，也比較考驗基本功。

除了最簡單的避免使用foreach，避免頻繁new內存，ToString。下面幾個點可能是往往容易被忽略。

1. GameObject.SetActive會引起GC

優化方法：對於渲染相關的，可以考慮是否隱藏MeshRenderer來替代，還有就是把GameObject拉到很遠的地方，UI也同樣適用。

1. C#自帶的排序有GC

優化方法：自己實現排序算法,數量不多的直接寫個簡單的冒泡就行。

1. 反射會引起GC

優化方法：大部分的反射都可以用dictionary做緩存。

1. List.Add會有GC

優化方法：List底層是數組，在數組容量不夠的時候就會擴充，會產生GC。可以考慮在new的時候直接指定大小。

1. Box Unbox 會有gc

Boxing的GC很隱藏，打樁也很難發現，Boxing的觸發條件：當需要將棧（Stack）上的值類型轉換為堆（Heap）上的引用類型，這個過程被稱為“裝箱”，它具有以下特性：

1. 在堆（Heap）上分配空間
2. 通知垃圾回收器有關新對象的信息
3. 復制值類型對象中的數據並傳遞給新的引用類型對象

當初是發現了Behavic組件底層有GC，跟到很下面的時候發現是一個equal函數

裏面有一處改動是這樣。

p4.png

GPU優化

不說GPU占有率，直接說GPU耗時Xms就是耍流氓。

通常XCode裏面有GPU時間，對於一個30fps得遊戲，理論上GPU有33ms的時間可以用，但是這個時間超過20ms的時候，就會發現再往上增加一些渲染消耗(1,2ms左右)，GPU耗時不會明顯增加，而原有的一些渲染消耗可能要1.5ms的你會發現只要1ms就可以了，這個時候其實GPU負載已經有點過了，GPU為了流暢度開始提升頻率（iPhone 6 plus親測）

p5.png

GPU的優化其實就是和美術同學Battle的過程，找到那個平衡點，就算優化成功了。很多時候GPU的優化不僅僅是Profile看熱點，而是需要你給出方案，這就很看經驗了，萌新需要多問問老司機。

下面幾個點一定要註意!

Overdraw! Overdraw! Overdraw!註意每一塊半透明是否需要渲染，面積是否能夠減少。

Shader的復雜度會影響fillrate。

遊戲場景內最好不要出現alpha test，會影響Hidden Surface Removal（HSR）的處理。

不要輕易嘗試後處理，耗CPU, 耗內存, 耗GPU,中低配一定要關掉。

粒子系統請慎重使用，耗CPU，多Overdraw，數量和粒子總數都要控制好。

Static Batch 會消耗內存。

Dynamic Batch耗CPU，但是當需要渲染很多個同樣的MeshRenderer的時候，對於減少DC非常有效，建議開啟。

單局外的性能也要註意！

耗電優化

當優化完卡頓問題之後，本人就開始想著做一些炫酷的事情了，比如更酷的特效啊，後處理加起來啊，然後對於移動平臺來說，你不是不卡就可以了，耗電，發熱也是要重點考慮的事情。

耗電的幾個大頭，GPU,網絡，CPU，GPRS,喇叭，屏幕亮度等等。上面介紹了幾個Profile CPU, GPU的工具，但是電量怎麽Profile呢？

關於耗電的優化踩過很多坑，參考網上能找過的方法挨個試了，比如用ios設備的記錄耗電情況日誌，或者是XCode的Energy impact等等，統統無效，其中的坑就不一一說了。只說一個絕對有效的方法。

使用WeTest雲真機耗電量測試！基於自家的耗電盒子來檢測電量，測得的結果精準。

p6.png

還有就是設備一直處於充電狀態，和實際使用有偏差，不過都在可接受範圍內。

首先要測試出一個同品類遊戲或者標桿產品的耗電水平，比如測得王者5v5單局得耗電如下：

p7.png

接下來就可以測自己得apk了，測試得時候，最好可以通過作弊指令去動態開啟關閉一些特性，得到各項的消耗，想要測得比較精確的結果就多次測取平均。

得到各項的消耗之後，就可以有針對性的優化了。

數據上報統計

數據上報統計是指將玩家的設備信息，設備畫質選擇，幀率信息進行上報，這樣每次測試都能獲取到很多有用的信息，利用這些信息可以進行相應的調整，比如說某些默認畫質匹配占比，不同設備的性能表現，各類硬件的占比，比較卡頓的場景有哪些等等，同時也可以橫向對比看優化的效果。

小結

記得剛加入團隊，飛車剛好要進行第一次輕度測試，那次測試的收到很多的玩家抱怨各種卡頓，競速賽卡，道具賽卡，連我們的策劃同學在跑單人單局的也覺得卡…當時為了保證流暢把大部分的機器歸為了低配機，還有很多玩家，設備是中高配的，為了開上高幀率，將畫質設為低…..

到PR2的時候，經過一輪強力優化，也是和美術策劃同學的通力合作，將默認中高配的設備從20%多提升到了70%以上，對於低配機，我們盡量會滿足30fps流暢運行，對於中高配，60幀的順暢體驗可以讓他們覺得玩的是另一個遊戲（Android設備需要開始多線程渲染），如今正式上線，在TapTap這種黑騰訊遊戲即政治正確的社區，好評也是絕大多數。

不過還是會有一些沒有優化到的地方，比如

”Android 機開局的完美起步會卡啊！“

“-請期待年前的版本”

”休閑區還是很卡啊！“

“-請期待年前的版本”

”新手引導品質太低了吧！“

“-請期待年前的版本”

….

優化是件漫長的事情，因為總有可以優化的東西，這裏的面是不是可以更省，那邊shader精度減一下是不是可以…..自身也需要去掌握多種的profile技術，內功也要加強修煉才行，你拿著消耗去和美術大佬談判，總得給個靠譜的解決方案吧。

對於一個老司機，應該在項目之初就能夠把各個標準都定好，給出最好的解決方案，能做的不能做的都和大佬拍好，這樣後面就舒服一些，但大部分還是一邊現問題一邊處理，然後慢慢地把規範和自動化測試流程搭建起來，這樣也不失為亡羊補牢，這裏面其實又涉及了一些TA工作。

特別感謝在優化過程中能夠耐心給我解答問題的各位前輩，非常感謝！

篇幅原因，能覆蓋的就這些了，沒有涉及到的或者有誤的迎大家指正。

參考

1 手機CPU性能天梯圖

2 Smartphone and Tablet Graphics Cards - Benchmark List and Comparison

3 mobile cpu上禁用alpha test的相關總結

4 iOS Hardware Guide

5 Unity移動開發如何依據性能選擇shader？ - 拳四郎的回答 - 知乎

問答
遊戲體系結構
相關閱讀
團戰開黑必備“良藥”了解一下！
再也不用擔心網吧開黑隊友聽不清了！
3行代碼，為QQ輕遊戲加上語音互動能力
【每日課程推薦】機器學習實戰！快速入門在線廣告業務及CTR相應知識

此文已由作者授權騰訊雲+社區發布，更多原文請點擊

搜索關註公眾號「雲加社區」，第一時間獲取技術幹貨，關註後回復1024 送你一份技術課程大禮包！

海量技術實踐經驗，盡在雲加社區！

七個要素幫你打造現象級手遊！優化程度堪比《QQ飛車》