60幀的絲般順暢 - QQ飛車手遊優化點滴

做者:申江濤,騰訊互娛客戶端工程師
商業轉載請聯繫騰訊WeTest得到受權,非商業轉載請註明出處。
原文連接:http://wetest.qq.com/lab/view/401.htmlhtml

WeTest 導讀

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


設備等級劃分

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

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

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

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

爲知足美術大大們的追求,能夠在高畫質的基礎上再劃分一個超高配。網絡

設備等級劃分以後,就能夠作一些LOD策略了,必定要作的就是劃分各類特效的級別,其次場景最好也作一下,有條件的UI元素也作一下,對於非核心信息的UI能夠在低配機隱藏。數據結構

關於Shader LOD的作法有在這個回答[5]裏面提到,這裏就不贅述了。多線程

優化工具

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

Unity Profile

圖片描述

做爲最簡單也是最實用的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

圖片描述

蠻好用的一個Android平臺的GPU Profiler,以前不少人用來提取手遊的資源,可是已經被高通拋棄了,已中止更新支持一些老的高通GPU的設備,這邊肯定好用的是紅米 Note 1.

若是能找到能夠用的設備能夠,建議仍是能夠連一下看看,仍是能看到不少東西的:DC數量,繪製順序,渲染shader,動態修改shader看效果,貼圖格式…

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

XCode

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

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

圖片描述

相對於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函數

裏面有一處改動是這樣。
圖片描述

GPU優化

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

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

圖片描述

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雲真機耗電量測試!基於自家的耗電盒子來檢測電量,測得的結果精準。

圖片描述

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

首先要測試出一個同品類遊戲或者標杆產品的耗電水平,好比測得王者5v5單局得耗電以下:

圖片描述

接下來就能夠測本身得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? - 拳四郎的回答 - 知乎


騰訊WeTest「耗電量測試」已在雲端部署,獨家研製的耗電量盒子進行耗電量測試,精準定位手遊耗電問題,點擊http://wetest.qq.com/cloud/phone 便可體驗。

若是使用當中有任何疑問,歡迎聯繫騰訊WeTest企業QQ:2852350015

相關文章
相關標籤/搜索