如何準確評測Android應用的流暢度？

如何準確評測Android應用的流暢度？

做者簡介：

葉方正 2008年加入騰訊，就任於無線研發部【專項測試組】。曾經負責多個產品的性能優化工做，積累大量的移動終端平臺優化以及評測經驗。

---

怎樣獲取SM值？

經過測量應用的幀率FPS並不能準確評價App的流暢度，FPS較低並不能表明當前App在UI上界面不流暢，而1s內VSync這個Loop運行了多少次更加能說明當前App的流暢程度。

那麼咱們能夠直接在App代碼中經過Choreographer的回調FrameCallback來計算Loop被運行了幾回，從而知道應用的流暢度。但在實際狀況下咱們不必定能修改代碼（實際發佈的版本不容許加入測試代碼）或者根本拿不到代碼（譬如和競品進行對比）。

今天咱們介紹一種更簡單直觀測量Android應用流暢度的方法，就是經過開源測試工具GT（http://gt.qq.com）。

一、先啓動要測試的應用。

二、啓動GT，在插件中選擇GT Injector，再選擇被測進程，點擊「射它」。

三、點擊後，Para界面會出現流暢度指標以及被插入程序的CPU佔有率，而且會帶上被插入的進程名。將流暢度後面小方框勾選（表示須要記錄SM值到log文件），而後點擊右個角「Gather & Warning」下小紅圈（表示開始記錄數值）。

四、啓動App，開始作相關的測試。

五、完成測試後，在GT界面點擊流暢度(SM)，則會出現已經記錄的SM值圖表，點擊右上角磁盤圖標，保存log到指定名字的文件夾。

六、最後利用工具（好比應用寶），把log導入到PC端進行後期處理（通常狀況下，文件保存路徑在：SD卡/GT/GW/進程名/自定義文件夾）。

---

SM測試效果如何？

咱們已經收集了SM的測試數據，但測試數據是否準確？咱們拿一些瀏覽器產品爲例子，來評測下SM的數據和人的感覺是否對應得上。

首先，咱們爲了把感官和人的感覺對應上，特把主動感官分數對應到如下幾種描述。

一、先看看流暢度(SM)和丟幀(SF)之間的關係

測試場景：瀏覽器看妹子圖

評測手機：Nexus 4

流暢度主觀評分(整體)：2.5（界面滑動明顯頓挫感，響應用戶輸入有種慢半拍的感受）

由於丟幀是個不連續的過程，因此圖中的丟幀都是以點來表示其離散的狀態。從上面圖表能夠看出：

丟幀(SF)越多，流暢度(SM)越低。

26:16~26:42之間的流暢度很低，而且丟幀最密集。

再總體梳理一下這期間流暢度、丟幀和主觀評分的數據：

從這個數據能夠看到，丟幀(SF)越多流暢度(SM)越低，而且主觀感受比較卡，這個關係是成立的。

二、再引入FPS看看三者關係

測試場景：瀏覽器看妹子圖

評測手機：Nexus 4

流暢度主觀評分(整體)：2.5

此次測試引入了FPS數據，從圖表中能夠看出:

FPS曲線和SM曲線差很少，並且一樣受丟幀的影響。

有段比較奇怪的地方：流暢度很高，但FPS比較低，無丟幀狀況，將這段數據放大來看：

檢查這個時段的測試場景：靜置在某個界面沒有動，主觀評分在4.5左右。

再總體梳理一下這個時間段FPS、流暢度、丟幀和主觀的數據：

能夠看出，流暢度SM會比FPS更加適合客觀描述App卡的程度。

---

如何有效利用SM值判斷App流暢度？

肯定了使用SM值來評估手機App的流暢度後，咱們會開始進行一個產品在不一樣場景，以及多個產品間在相同場景下的測試對比。場景太多，測試數據巨大，該如何有效使用SM測試結果去判斷App流暢狀況？

一、一些思路

不能直接用平均值和方差
根據以往經驗，經過平均值，方差等一些指標，並很差說明問題。若是卡頓時間出現較短，測試時間較長，則平均值和方差這種指標不容易發現問題，可是又確實有卡頓。平均值和方差適合描述服從正態分佈的隨機變量，可是測試獲得的SM值並非這樣的隨機變量。

將測試結果按卡頓和流暢分段，對每一個卡頓區間段打分
以前參考了一篇遊戲流暢度評分的文章，該文章結合FPS平均值和卡頓的程度以及頻率，對遊戲總體流暢度打分。可是普通App和遊戲的區別比較大。對普通App來講，用戶不是一直在操做，並且不一樣的操做差別也較大，所以卡頓的頻率通常較低，用平均值和卡頓的頻率打分獲得的結果可能會偏高。因此把測試過程按照卡頓和流暢分段，計算每一個卡頓區間的打分和持續時間可能更有參考意義。

整體打分時加大卡頓時的權重，下降流暢區間的權重
雖然咱們重點關注的多是卡頓的地方，可是競品測試，以及兩個版本對比須要有整體評判結果，不能只看局部。爲了加大結果的區分度，對卡頓區間增長權重，對流暢區間下降權重，來突出卡頓對總體評分的影響。所以，評估結果將包括兩部分：整體打分，以及卡頓區間、流暢區間的持續時間和打分。

二、流暢度評估方法

預處理，每5個（秒）一組，取最低值。若是5秒內出現多於一次卡頓（SM低於40），則再乘以一個和卡頓次數有關的權值（小於1）。

【說明】若是卡頓出現次數較少，平均值和方差不容易發現問題。所以沒有直接對數據評估，先進行了預處理，突出SM值低的部分，加大卡頓對總分的影響。
處理前的三組數據：

處理後的三組數據：

將處理後的數據按卡頓和流暢分段，針對每段打分。

【說明】若是隻有最後總分，且流暢的時間較長，卡頓的數據容易被流暢的數據淹沒。並且有些測試場景存在一段流暢，一段卡頓的現象，卡頓並不必定在整個測試過程當中存在。這樣分開流暢和卡頓的區間處理，更容易看出卡頓的程度。

根據測試經驗，對SM值對應的卡頓嚴重程度打分。

【說明】根據測試同窗的經驗，流暢度指標SM低於40時，用戶能感知到卡頓，SM在20如下卡頓比較嚴重。所以在打分時，SM值在20如下時打分最低，對應0-20，在20-30區間打分低，對應20-60，30-40區間打分較低，對應60-70，40以上打分在70以上。
整體打分時下降流暢區間的權重。

【說明】這樣處理的緣由和第一項的緣由同樣，咱們更關注的是卡頓，流暢區間過長時會淹沒卡頓的數據。

三、對比幾個瀏覽器產品在同一個場景下的測試數據

測試場景：瀏覽網頁

評測手機：Nexus 4

測試方法：打開鳳凰網，來回上下滑動，在滑動的過程當中記錄流暢度數據

流暢度評估後數據：

從上面的數據能夠看出，在滑動瀏覽網頁時，C瀏覽器略微好於A瀏覽器和B瀏覽器。

固然這都是在性能比較好的手機（Nexus 4）上測試，其實主觀感覺差距不大，但從量化數據上就能夠看出優略。

---

小編有話說

卡頓的問題嚴重性，可能不像崩潰來得那麼強烈，但對於用戶的流失影響是潛移默化，慢慢深刻。若想知道本身產品流暢度如何，也能夠試試用SM來評測本身產品性能。

---

騰訊Bugly簡介

Bugly是騰訊內部產品質量監控平臺的外發版本，其主要功能是App發佈之後，對用戶側發生的Crash以及卡頓現象進行監控並上報，讓開發同窗能夠第一時間瞭解到App的質量狀況，及時機型修改。目前騰訊內部全部的產品，均在使用其進行線上產品的崩潰監控。