手遊前端效能測試

前端效能測試

導讀

目前遊戲行業已經呈現精品化狀態，行業對測試崗位的要求也越來越高，前端效能測試僅僅是用工具測試出相關資料（自動化測試即可滿足，包括自動化指令碼，或者自動化錄影），並告知研發，已經不能滿足測試要求。所以效能測試崗同學需要具備更多硬性技能，本篇文章適合效能測試新手；分別從測試場景，測試工具，然後測試資料概念，之後到和開發、美術同學在優化中的溝通，以及最後常用的優化方法策略，逐一展開介紹。

測試場景

導讀

前端效能測試，關注使用者在玩遊戲過程中的效能方面的體驗，包括是否卡頓，是否crash，是否手機發熱，是否耗電過快等，不管使用者的手機是高配機，中配機器，還是很渣的低配機器，都需要關注使用者效能體驗（有同學問，為什麼還這麼關注低配機使用者的感受，他們能充錢嗎？其實一個遊戲生態，需要比如5%的RMB使用者需要剩餘95%的屌絲使用者來襯托；另外遊戲口碑等都需要考慮所有使用者的體驗等）。

卡頓

遊戲流暢是遊戲比較基本的效能指標，尤其在核心玩法的時候。從測試角度看，更多關注遊戲的fps資料、卡幀率、bigjank值等

crash

使用者不希望遊戲過程中出現crash情況，測試關注crash率資料

發熱

手機發熱之後除了體感不好，另外不同的手機廠商會選擇降頻或者鎖核，從而導致遊戲卡頓。手機發熱原因較多（比如執行高功耗app、在充電中、不良電池、保護殼不能散熱、所處環境溫度高等），這裡關注的是怎麼降低遊戲的功耗，其實更多是怎麼降低GPU和CPU的使用率

耗電過快

手機電池毫安數本身就是手機的重要指標，耗電快無疑是硬傷。

測試工具介紹

perfdog

騰訊出品的效能工具，無需root或者越獄。PerfDog支援移動平臺所有應用程式（遊戲、APP應用、瀏覽器、小程式、小遊戲、H5、後臺系統程式等）
安裝，使用教程等參考官網詳細介紹：
https://bbs.perfdog.qq.com/article-detail.html?id=5

UWA

針對unity和unreal引擎的遊戲或者VR產品提供服務，包括資源監測（動態和靜態，免費），效能診斷和優化（收費），lua效能分析，自動化測試，社群問答等
UWA GOT是UWA推出的本地效能測評工具，需要裝對應sdk，無需越獄或者root。
UWA成立2015年，目前積累了不少使用者和測試資料，是目前比較主流的測試工具和社群。
安裝和使用，官網詳細介紹：
https://uwa-public.oss-cn-beijing.aliyuncs.com/uwa-got/document/UWA%20GOT%20%E4%BD%BF%E7%94%A8%E8%AF%B4%E6%98%8E.pdf

UPR

UPR開始於這兩年，目前UPR在積累使用者中，所以是免費的，而且技術支援比較好（有什麼問題反饋比較及時，甚至會現場解決），UPR的一些功能還在完善和開發中
URP分手機和桌面版，可以帶sdk和不帶sdk，當然，沒有繼承UPR sdk的測試資料會少。
安裝和使用，參考官網介紹：
https://upr.unity.cn/instructions

其他測試工具

比如騰訊GT，網易的Emmagee，以及google的工具等等

自研測試工具

對應一些廠商，比如呼叫引擎給的介面等方法，來獲取相關效能資料，來實現工具的目的。

測試資料概念介紹

記憶體

一般關注：
①pss記憶體（實際使用的實體記憶體）的大小（ios和andriod機器一般都是分三檔機器，每檔機器的pss記憶體標準不一樣，標準數值隨著硬體裝置提升也在逐漸而變高）
②記憶體洩漏（記憶體洩漏後，記憶體越來越大，可能會因為申請分配記憶體越來越慢導致的卡頓，或者crash等）
③記憶體資源重複率：資源重複是指記憶體中同一時刻，存在兩份或以上相同的紋理、網格、動畫、音訊等資源。一般是相同的一份資源被打包到多個AB包中，如果這些AB都被載入進記憶體，記憶體中就會存在多份相同的資源

bigjank

PerfDog計算方法：同時滿足兩條件，則認為是一次卡頓Jank.
1、 當前幀耗時>前三幀平均耗時2倍。
2、 當前幀耗時>兩幀電影幀耗時(1000ms/24*2=84ms)。
同時滿足兩條件，則認為是一次嚴重卡頓BigJank.
1、 當前幀耗時>前三幀平均耗時2倍。
2、 當前幀耗時>三幀電影幀耗時(1000ms/24*3=125ms)。

FPS

幀率，標準要求比如：核心遊戲場景預設要求90%數值都不低於25FPS；

流暢度

比如：核心遊戲場景，預設要求卡頓率不高於2%

CPU

比如：綜合CPU平均佔用(90%)小於60%，單核CPU峰值佔用（90%）小於90%
另外要關注單核CPU使用率，以及是否所有核心都在使用，以及使用是否平均等
還有CPU的曲線是相對平滑，還是鋸齒嚴重

工具中常用資料

cpu：
①frameTime：同一幀的耗時
②Rendering Time：當前幀渲染耗時；drawcall越高，這部分開銷越大
③ScriptTime：當前幀函式耗時
④PhysicsTime：當前幀物理耗時
記憶體：
程式碼中的記憶體 –Mono記憶體（mono記憶體，記憶體池，只增不減）；資源中的記憶體佔用 –Native記憶體
①ReservedMono：一般是指令碼分配的記憶體
②pss記憶體：一般用於定位多局戰鬥、場景跳轉、開啟關閉UI中是否有記憶體洩漏
③total_reserved記憶體：unity_reserved記憶體+GFX記憶體+FMOD記憶體+Mono記憶體+Profiler記憶體
④mono reserved：分配的mono記憶體（綠線部分），只升不降，需要嚴格控制。mono記憶體表示遊戲中指令碼分配的記憶體
⑤gfxdriver_reserved：表示渲染模組的記憶體，如果比較高需要對紋理資源和Shader進行優化。
⑥fmod_reserved：表示音訊模組的記憶體，如果比較高需要對音訊資源進行優化
⑦記憶體資源重複率：資源重複是指記憶體中同一時刻，存在兩份或以上相同的紋理、網格、動畫、音訊等資源。一般是相同的一份資源被打包到多個AB包中，如果這些AB都被載入進記憶體，記憶體中就會存在多份相同的資源

其他資料可以參考：
https://segmentfault.com/a/1190000016342638?utm_source=tag-newest

研發（開發和美術）概念介紹

導讀

在和研發同學溝通時，需要對研發上的一些概念，以及常用的優化思路，方法有所瞭解，可以根據問題資料，提供一些優化建議。

圖集atlas

是通過專門的工具，將多張圖片合併成一張大圖，並通過 plist 等格式的檔案索引的資源
NGUI強調圖集，圖集要規劃好，否則經常會出現圖集不夠用等問題；UGUI弱化使用者對圖集的概念，在打包的時候自動生成圖集。各有優缺點
目前研發團隊中主要使用的則是Unity自身的 UGUI系統 和Asset Store上的 NGUI外掛

畫布canvas

Canvas畫布是承載所有UI元素的區域。Canvas實際上是一個遊戲物件上繫結了Canvas元件。所有的UI元素都必須是Canvas的自物件。如果場景中沒有畫布，那麼我們建立任何一個UI元素，都會自動建立畫布，並且將新元素置於其下

Collider

碰撞體

網格mesh

mesh就是我們所說的三角網格。三角網格就是由一系列三角形組成的多邊形網格，主要用於模擬複雜物體的表面，事實上游戲開發過程中美術給我們的人體、車輛模型都是由一個或多個三角網路(mesh)組成的。
工具：mash baker，能夠有效合併網格以及網格所使用的材質，來有效減少渲染批次所帶來的開銷

紋理Texture

紋理即“紋路”，每個物體表面上不同的樣子，譬如說木頭的木紋狀。紋理就是一段有規律、可重複的影像

貼圖 Map

貼圖是圖，最簡單的形式是ps之類的軟體做出來的一張圖，這些圖在3D中用來貼到物體的表面，用來表現物體的“紋理”
最有名的是lighting map，即光照貼圖， 光照貼圖是生成或者繪製出來，用於物體表面模擬光照效果的

材質Material

材質主要是用來表現物體對光的互動（反射、折射等）性質的。譬如金屬對光的反射和毛毯對光的反射性質完全不一樣，那麼對3D程式來說，這樣的差別就通過材質這個屬性來計算出不同的顏色。
材質，本質是資料集：表現物體對光的互動，供渲染器讀取的資料，包括貼圖，紋理，光照演算法等

著色器shader

實際上就是一小段程式，它負責將輸入的Mesh（網格）以指定的方式和輸入的貼圖或者顏色等組合作用，然後輸出，模擬真實世界中的光影效果，這個效果是由物體表面材質、燈光、觀察者的視角等多種因素共同決定的
Unity中所有的渲染都使用著色器完成

材質球

U3D引擎中材質的預覽方式為一個球體，材質球是什麼樣子，通常由貼圖決定
紋理---貼圖--->經過shader---->材質球--->材質球貼到具體的模型上，生成模型1，模型2......

Alpha通道

指一張圖片的透明和半透明度
對於16bit儲存的點陣圖，每5個bit分別表示紅黃藍，最後一個bit是表示阿爾法通道，0或1，所以要麼透明要麼不透明；對於32位儲存的點陣圖，每8個bit分別表示紅黃藍，最後8位表示阿爾法通道，就有256種透明可能

draw call

簡稱DC，由CPU收集美術的資源資訊，傳遞給GPU，通知GPU進行一次渲染過程叫DrawCall。是cpu通知gpu幹活的一種命令

• 為什麼drawcall多了會影響幀率
  • 在每次呼叫Draw Call之前，CPU需要向GPU傳送很多內容，包括資料，狀態，命令等。在這一階段，CPU需要完成很多工作，例如檢查渲染狀態等 而一旦CPU完成了這些準備工作，GPU就可以開始本次的渲染。
  • GPU的渲染能力是很強的，渲染300個和3000個三角網格通常沒有什麼區別，因此渲染速度往往快於CPU提交命令的速度。
  • 如果Draw Call的數量太多，CPU就會把大量時間花費在提交Draw Call命令上，造成CPU的過載。因此造成Draw Call效能問題的元凶是CPU

提交大量很小的Draw Call會造成CPU的效能瓶頸，即CPU把時間都花費在準備Draw Call的工作上了。把很多小的Draw Call合併成一個大的Draw Call,這就是批處理的思想。

渲染通道pass

每個pass都會消耗一個drawcall，在滿足渲染效果的情況下，儘可能減少渲染通道的數量

Lightmap

其實就是打了燈光的貼圖，通常是對遊戲場景中靜態物體上，貼了一層帶燈光效果的貼圖
優點：省去了很大光照相關的計算，減少了效能的消耗
缺點：多了一層紋理，我們使用了燈光貼圖肯定多了一層紋理。另外靜態貼圖無法改變燈光的方向，比如燈泡被使用者打碎了，燈光效果還在，實際要幹掉

mipmap

也是貼圖。使用Mipmap後，貼圖會根據攝像機距離的遠近，選擇使用不同精度的貼圖
Mipmap技術有點類似於LOD技術，但是不同的是，LOD針對的是模型資源，而Mipmap針對的紋理貼圖資源
缺點：會佔用記憶體，因為mipmap會根據攝像機遠近不同而生成對應的八個貼圖，所以必然佔記憶體！
優點：會優化視訊記憶體頻寬，用來減少渲染，因為可以根據實際情況，會選擇適合的貼圖來渲染

LOD

在遊戲場景中，根據攝像機與模型的距離，來決定顯示哪一個模型，一般距離近的時候顯示高精度多細節模型，距離遠的時候顯示低精度低細節模型。
優點：可根據距離動態地選擇渲染不同細節的模型，從而提高渲染的效率
缺點：加重美工的負擔，要準備不同細節的同一模型，同樣的會稍微增加遊戲的容量

烘焙

物體表面的反光或者陰影，記錄到模型裡，形成新的貼圖，執行的時候，顯示卡和CPU不需要進行對環境光效果的運算了。實際上就是lightmap的生成過程

面數Tris

模型上的三角形面數，對應不同型別的模型，一般有不同的標準，比如小怪多少面，精英怪多少面，boss多少面，隨著遊戲製作精度和硬體的提高，面數的標準也隨著變多

bloom

Bloom放在後期特效中，是實現光線綻放，燈光溢位的效果
特效有有2個最常見的後期：Color Grading（調色） 和 Bloom（泛光/輝光）
參考連結：
https://zhuanlan.zhihu.com/p/76505536

GC

垃圾回收，一種記憶體管理機制（針對堆記憶體）
參考連結：
https://www.jianshu.com/p/db449e84a7ab

AssetBundle

資源打包，簡稱AB包，主要考慮打包策略和載入策略，比如：把需要同時載入的Asset儘量打包到同一個AB裡。例如模型，其紋理和動畫
參考連結：
https://zhuanlan.zhihu.com/p/91926428

渲染技術彙總

https://blog.csdn.net/poem_qianmo/article/details/78309500

開發優化工具介紹

不同的專案組，有不同的優化工具，也有共用的。

常見的共用優化工具

Unity Profiler，Unity Memory Profiler, XCode Instrument. XCode Instrument內又包含了很多工具，其中最常用的有Time Profiler，Allocation以及Capture GPU Frame。adb命令
比如：XCode Allocation，會統計記憶體的分配和釋放情況，從而看出是否存在記憶體洩漏情況（比如主城--戰鬥--主城，記憶體快照的情況下）

自研優化工具

比如：場景優化時：按照格子（比如4米*4米）獲取場景內的熱點資料；比如按照場景攝像機內的物件個數和物件類別的比例曲線，比如場景中，重複材質檢查工具等

常用的優化方法策略

導讀

①效能優化是一個長期的過程
②效能優化不但是程式部門的事情，而是需整個專案組共同配合和努力的結果，一般專案組每個部門都會有對應的專職人員
③好的優化工具至關重要
④不同的機器裝置，展示的美術品質是不一樣的，所以針對機型（分三檔機器）有不同的優化策略
⑤每個核都充分利用，多執行緒渲染技術（unity5以上就開始支援了）
⑥在不同的場景，時間和空間的選擇（時間換空間，還是空間換時間，CPU和GPU可以互換，CPU和記憶體可以互換、記憶體和磁碟可以互換）
⑦不必要渲染的東西不渲染（比如UI層級，不顯示的UI不渲染；不在攝像機內的不渲染；遮擋減少渲染；imposter，LOD，minimap等）。不必載入的內容不載入（比如大表拆分按需載入；圖集拆分按需載入等；AB包載入策略等）。能壓縮的都壓縮（這個好理解）
⑧效能優化不是一勞永逸的事情，是持久戰；即便是已經上線多年的長線產品，效能測試也是一如既往在挖掘效能點並優化

參考：
https://segmentfault.com/a/1190000019844821?utm_source=tag-newest

場景優化

①關注場景的熱點資料（比如按照2米一個計算範圍單位），通過調整物件的位置，優化物件的資源等來優化熱點問題
②新增關鍵遮擋物，來減少相機內的渲染量
③LOD技術的運用，或者imposter技術的運用等
④遠景物件包括角色怪物等平滑渲染（多幀完成渲染）
等等

同屏人數優化

①同屏人主要集中的場景點，第一是要場景分離，比如拍賣行和交易地點分開，一個室內，一個室外；第二是減少對應場景的物件消耗
②計算策略優化，優先渲染離自己近的角色和場景物件
②效果優化，比如同一型別的特效到一定數量後不在渲染等
④同屏時使用者角色是動態的，不停的載入和釋放，做平滑處理（按幀控制渲染數目方法等）。避免瞬間載入導致的卡頓
⑤同屏戰鬥時，尤其國戰，同角色avatar一樣
⑥Imposter(偽裝者，或者叫替代物)技術：（基本原理用相機把模型各個角度的圖片拍下來，然後根據玩家相機的角度選取不同的圖片顯示）
等等

UI優化

比如：
①格式
②儘可能將動態UI元素和靜態UI元素分離到不同的UIPanel中（UI的重建以UIPanel為單位），從而儘可能將因為變動的UI元素引起的重構控制在較小的範圍內
③帶通道和不帶通道圖集，儘量分開
④同一個UI介面或者同一個功能點的ui資源放在一個圖集，可以減少drawcall
等等
參考：
https://www.cnblogs.com/wetest/p/6147011.html

GC優化

GC的時候會佔用大量計算資源，如果GC之後發現記憶體依然不夠用，需要再次分配（unity非官方資料一次大概6MB），那麼就更耗資源了。GC優化一般有：
①物件池技術---重複使用物件（比如子彈，需要頻繁的生成和銷燬）
②減少記憶體垃圾的數量（比如：不要在頻繁呼叫的函式中反覆進行堆記憶體分配，後者使用快取技術）
③減緩GC的時間，不要在關鍵時候GC操作；在非敏感期主動gc
④其他技術手段，比如裝箱，list，字串等導致GC的解決方案
參考：
https://www.cnblogs.com/u3ddjw/p/8624438.html

記憶體優化

記憶體效能原因主要有這幾點：記憶體碎片過多（記憶體池解決）、記憶體頻繁建立銷燬（物件池解決）、記憶體載入慢、記憶體佔用過高。
①資源（貼圖，模型，動畫，聲音等）有失真壓縮，每種資源都有最優的壓縮方式和格式等。
②指令碼和配置，及時解除安裝，以及拆分等
③第三方shader庫，冗餘預編譯巨集佔用
④AB包打包策略和載入策略，都會影響記憶體佔用。AB自動打包工具（公共包合併，AB包要在10MB內），遊戲型別邏輯強關聯打包模式，比如moba，把一個英雄的所有資源打到一個包裡。
比如：
第三方庫記憶體佔用，延時載入和模組隔離方法（第三方庫記憶體洩漏，或者佔用過大，方便處理）
比如技能表，常駐優化方案
去掉記憶體中同時存在的相同資源（比如特效資源）

Unity資源記憶體優化，資源記憶體佔用排行榜(優化價效比)：貼圖>動畫>網格>音訊>材質
一、貼圖優化
1.降低解析度
2.拆分透明通道
3.調整壓縮格式（比如帶阿爾法通道的貼圖拆分2兩張，分別壓縮；格式轉換大概是原來1/4的記憶體）
4.禁用Mipmap
5.啟用Use Crunch Compression
1張512*512點陣圖，安卓：RGBA ETC2（帶通道）佔用256KB，RGB ETC2（不帶通道）佔用128KB記憶體；在iOS:RGBA PVRTC（帶通道）和RGB PVRTC都佔用128KB記憶體
二、動畫優化
1.減小動畫長度
2.減少骨骼數量
3.減少關鍵幀密度
4.減少動畫精度
三、網格優化
1.減少頂點
2.開啟Optimize Mesh選項
四、音訊優化
建議較長的音訊使用.mp3或.ogg格式，較短的音訊使用.wav 或.aiff格式

CPU優化

方法：
微觀方法：從每一幀中發現問題（主要方法）
巨集觀方法：從統計中發現問題，比如一局戰鬥，每個模組和函式的耗時和呼叫次數統計，也方便不同版本的對比（工具或者日誌來統計）
分類：
①GC，GCAlloc耗時
②渲染耗時（合併批處理，減少drawcall：比如使用動、靜態批處理，GPU Instance技術）
③邏輯耗時（比如迴圈查詢，比如大量伺服器訊息集中處理等）
④其他引擎消耗（動畫，物理）
參考：
https://gameinstitute.qq.com/community/detail/120536

GPU優化

GPU的計算目前看，大部分還是能勝任，設定錯錯有餘的。所有在CPU優化方案裡，有一部分就是把CPU做的事情，讓GPU做。
GPU優化思路：
①減少渲染批次
②同一個drawcall裡，減少渲染型別
③平滑渲染

細節點

①模型儘量不要做成多個物體掛點組合的方式，如果多個物體用到不一樣的材質，那額外產生的DC可是很酸爽的
②如果模型是帶動作的話,模型的頂點數和骨骼數也是模型動作製作時的重要標準。
③圖片佔用記憶體的大小與圖片大小、顏色深度、圖片格式有關，與美術是否對圖片資源進行壓縮無關（android用ETC1，ios用pvrtc，不帶alpha通道圖片可以用jpg）

效能監控

①內部監控（上傳資源時效能監控，和版本測試時，效能監控；從而及時發現問題）
②外網效能監控，比如wetest APM監控系統。

耗電相關

工具：比如google的Battery Historian
優化思路：
①計算優化。演算法、for迴圈優化、Switch..case替代if..else、避開浮點運算
②避免 Wake Lock 使用不當
③使用 Job Scheduler 管理後臺任務
④降低亮度等

總結

手遊效能測試的核心競爭力，更多是設計合理的測試用例，在測試完畢後分析資料，並根據問題資料提供合理化的優化建議；從而給研發團隊提供高效服務，體現價值。