前言

在智能手機(jī)App競爭越來越激烈的今天，Android App各項(xiàng)性能如CPU、內(nèi)存消耗等都是我們在開發(fā)測試中需要關(guān)注的指標(biāo)，如何將App打造得更加“優(yōu)雅”是我們需要不斷追求探索的方向，下面我們從內(nèi)存和流暢度兩個(gè)緯度來說說如何對Android App進(jìn)行評測和調(diào)優(yōu)。

一、內(nèi)存

內(nèi)存不是無限使用的，如果內(nèi)存過大或泄漏會(huì)出現(xiàn)OOM（Out Of Memory）、UI不流暢等問題，因此內(nèi)存也是一個(gè)稀缺資源，我們應(yīng)該保證沒有內(nèi)存泄漏且對不需要使用的內(nèi)存及時(shí)釋放。一般內(nèi)存測試或分析內(nèi)存問題可以分為下面幾步：

• 編譯代碼

• 選定測試場景（來自于經(jīng)驗(yàn)&開發(fā)）

• 測試場景轉(zhuǎn)換成用例

• 跑起工具Run用例

• 結(jié)合代碼，分析，分析…

  
  

1.內(nèi)存測試通用的方法

測試分析內(nèi)存有以下幾種方法：

• DDMS（Heap&Allocation Tracker）

Heap查看堆的分配情況：

主要關(guān)注兩項(xiàng)數(shù)據(jù)：

1）Heap Size堆的大小，當(dāng)資源增加，當(dāng)前堆的空余空間不夠時(shí)，系統(tǒng)會(huì)增加堆的大小。

2）Allocated堆中已分配的大小，這是應(yīng)用程序?qū)嶋H占用的內(nèi)存大小，資源回收后，此項(xiàng)數(shù)據(jù)會(huì)變小。

注：如果進(jìn)行反復(fù)操作，或堆的大小一直增加，則有內(nèi)存泄漏的隱患。

Allocation Tracker跟蹤內(nèi)存分配情況：

MAT（Memory Analyzer）

• Leak Suspects：內(nèi)存泄露報(bào)告

• Top Components：吃貨報(bào)告

• Histogram：每個(gè)Class占用內(nèi)存

• Dominator Tree：列出哪些對象占用內(nèi)存最多以及誰hold住這些對象

2. Android常見的內(nèi)存問題

Android常見的內(nèi)存問題有：

• 萬惡的Static通常見到在單例模式

下面就是一個(gè)例子，static變量占用過大的內(nèi)存比例（7.1M），這里碰到該情況需要具體分析里面數(shù)據(jù)是否都是需要常駐的，不要把很多不相干的變量設(shè)為static屬性。

• 多線程生命周期過長hold住本該釋放資源

這里需要自己搜索代碼查看是哪里一直hold住了資源導(dǎo)致沒有釋放。

• 大胖子Bitmap

圖上可以看到Bitmap占用內(nèi)存很大（5.7M），利用MAT來找到他的outgoing和incoming引用：

可以找到這塊內(nèi)存的引用關(guān)系，然后找代碼。

在遇到圖片資源占用過大的情況，建議：

1）及時(shí)的銷毀；
2）設(shè)置一定的采樣率；
3）巧妙的運(yùn)用軟引用（SoftRefrence）。

• Cursor

Cursor用完記得關(guān)掉，如果實(shí)在不確定Cursor是否關(guān)閉，可以在onDestroy中關(guān)了。

總的來說，沒有嚴(yán)格意義上泄露只是你hold太久。

二、流暢度

對于App是否流暢這個(gè)維度，之前一直沒有一個(gè)客觀的數(shù)據(jù)來將用戶客觀感受和數(shù)據(jù)一一對應(yīng)起來。雖然之前有FPS（每秒幀數(shù)）這個(gè)指標(biāo)來衡量，不過這對于App這樣的大部分時(shí)候可能沒有界面更新的軟件來說，是一個(gè)不恰當(dāng)?shù)目陀^數(shù)據(jù)（當(dāng)然FPS用于游戲或視頻類業(yè)務(wù)肯定是沒問題的）。在和我們的瀏覽器團(tuán)隊(duì)溝通后，應(yīng)他們的需求（它不僅要做最快的瀏覽器，同時(shí)也要做最流暢的瀏覽器），MIG（專項(xiàng)測試組）多位同學(xué)一起來通過研究Android自身UI更新機(jī)制以及通過數(shù)學(xué)建模摸索出一個(gè)客觀數(shù)據(jù)指標(biāo)流暢度（SM: SMoothness）來量化流暢度這個(gè)客觀感受。

首先從下面開始…

1. Android如何繪制UI

   
   

關(guān)于Android是如何去更新UI的，我相信有很多文章來介紹其中步驟以及過程，大體上可以用下圖來展示：

從圖中可以看到，無論哪條路走下去始終都由SurfaceFlinger來控制最后更新。在Android版本更新過程中發(fā)現(xiàn)在Jelly Bean版本更新中，Google加入一個(gè)Project Butter來解決嚴(yán)重影響Android口碑問題之一的UI流暢性差的問題。而Project Butter中引入了三個(gè)核心元素，即VSync（垂直同步）、Triple Buffer和Choreographer。

2. 先VSync開始

在Android 4.1（JB）中引入了VSync機(jī)制，是Vertical Synchronization（垂直同步）的縮寫，是一種在PC上已經(jīng)很早就廣泛使用的技術(shù)，可以簡單地把它認(rèn)為是一種定時(shí)中斷。

如上圖所示在VSync機(jī)制下的繪制過程。從上面的圖看CPU和GPU處理時(shí)間都很快都少于一個(gè)VSync的間隔也就是16ms，并且每個(gè)間隔都有繪制的情況下那么當(dāng)前的FPS即是60幀。當(dāng)CPU和GPU處理時(shí)間都很慢或者因?yàn)槠渌脑颍热缭谥骶€程中干活太多那么就會(huì)出現(xiàn)如下圖這樣的狀況。

從上圖可以看到CPU和GPU處理時(shí)間因?yàn)楦鞣N原因比較慢都大于一個(gè)VSync的間隔（16ms），那么可以看到在第二個(gè)VSync還在處理A區(qū)域的繪制這樣就不可能實(shí)現(xiàn)理論上的FPS 60了同時(shí)也出現(xiàn)了丟幀（SF: Skipped Frame）。上圖為了便于理解用的是雙Buffer機(jī)制的情況，實(shí)際上Android 4.1在引入了Triple Buffer，所以當(dāng)雙Buffer不夠用時(shí)Triple Buffer丟幀的情況如下圖所示。

Oh my ladygaga~~~這些把灑家看暈了…那打個(gè)比方講得通俗點(diǎn)。

VSync機(jī)制就像是一臺(tái)轉(zhuǎn)速固定的發(fā)動(dòng)機(jī)（60轉(zhuǎn)/s）。它每一轉(zhuǎn)帶動(dòng)著去做一些UI相關(guān)的事情，但是不是每一轉(zhuǎn)都會(huì)有工作去做（就像有時(shí)在空擋，有時(shí)在D檔）。有時(shí)候因?yàn)楦鞣N阻力某一圈工作量比較重超過了16.6ms，那么這臺(tái)發(fā)動(dòng)機(jī)這秒內(nèi)就不是60轉(zhuǎn)了，當(dāng)然也有可能被其他因素影響比如給油不足（主線程里干的活太多）等等。就會(huì)出現(xiàn)轉(zhuǎn)速降低的狀況我們把這個(gè)轉(zhuǎn)速叫做流暢度。

3. 從FPS&丟幀到流暢度（SM: SMoothness）

實(shí)際上在我們很多的Android App中，很少有需要不斷地去繪制的場景，很多時(shí)候都是靜態(tài)的。也就是會(huì)出現(xiàn)這樣的狀況，雖然1s中VSync的60個(gè)Loop中不是每個(gè)都在做繪制的工作FPS比較低，但并不能代表這個(gè)時(shí)候程序不流暢（如我將App放在那不動(dòng)實(shí)測FPS為1）。所以FPS為1這個(gè)數(shù)并不能代表當(dāng)前App在UI上界面不流暢，因此1s內(nèi)VSync這個(gè)Loop運(yùn)行了多少次更加能說明當(dāng)前App的流暢程度。So…另2個(gè)指標(biāo)比FPS更加能代表當(dāng)前的App是否處于流暢的狀態(tài)同樣這2個(gè)指標(biāo)更加能夠量化App卡頓的程度：

• 丟幀（SF: Skipped Frame）：如上圖所示情況應(yīng)該在16ms完成工作卻因各種原因沒做完，占了下n個(gè)16ms的時(shí)間，相當(dāng)于丟了n幀。

• 流暢度（SM: SMoothness）：和丟幀相對，在VSync機(jī)制中1s內(nèi)Loop運(yùn)行的次數(shù)。

1）和丟幀相對1s內(nèi)有60個(gè)Loop因?yàn)槟硯状喂ぷ鲿r(shí)間超過了16ms（丟幀），這樣Loop就無法運(yùn)行60次（理論最大值）。

2）當(dāng)流暢度越小的時(shí)候說明當(dāng)前程序越卡頓。

4. 數(shù)數(shù)：如何得到流暢度（SM: SMoothness）

接著上面的結(jié)論如果在這樣的機(jī)制下每次Loop運(yùn)行之前通知我下，我就記個(gè)數(shù)就好了。

很幸運(yùn)我們在新的Android的那一套機(jī)制中找到了一個(gè)畫圖的打雜工Choreographer這個(gè)對象。根據(jù)Google的官方API文檔描述他是用來協(xié)調(diào)animations、input以及drawing時(shí)序的，并且每個(gè)Looper共用一個(gè)Choreographer對象。

Choreographer的定義和結(jié)構(gòu)：

5. 所以通過如上原理分析可以得出結(jié)論：

• 根據(jù)了解文檔發(fā)現(xiàn)Android 4.1引入了VSync機(jī)制可以通過其Loop來了解當(dāng)前App最高繪制能力。

1) 固定每隔16.6ms執(zhí)行一次（這個(gè)值是一個(gè)靜態(tài)變量會(huì)根據(jù)系統(tǒng)版本不同而采不同的值,目前測試版本是16.6ms這樣最高的刷新的幀率就控制在60FPS以內(nèi)）；

2) 如果沒有以上事件的時(shí)候同樣也會(huì)運(yùn)行這樣一個(gè)Loop；

3) 所以這個(gè)Loop在1s之內(nèi)運(yùn)行了多少次,即可以表示當(dāng)前App繪制的最高的能力,也就是Android App卡頓的程度…

4) 另，在一次Loop時(shí)如果執(zhí)行時(shí)間超過了16.6ms，那么多于16.6ms的時(shí)間除以16.6ms，即是當(dāng)前App的丟幀（SF: Skipped Frame）。

• 可以在Choreographer的回調(diào)FrameCallback中按秒計(jì)數(shù)表示當(dāng)前App的流暢程度。

采用這樣方式就可以在App內(nèi)部觀測當(dāng)前App的流暢度。當(dāng)然，還有更簡單的方法，采用GT工具獲取流暢度，見下面步驟說明。

6. 用GT動(dòng)態(tài)注入被測程序獲取SM：

1）打開被測App，然后打開GT在插件中選擇GT Injector：

2）選擇被測進(jìn)程&點(diǎn)擊射它：

3）注入成功后Para界面會(huì)出現(xiàn)流暢度指標(biāo)以及被插入程序的CPU占有率這些并且會(huì)帶上被插入的進(jìn)程名。將流暢度后面小方框勾選（表明記錄SM值到log文件），然后點(diǎn)擊Gather & Warning下小紅圈（表明開始記錄數(shù)值）。

4）開始做相關(guān)的測試測試。

5）完成測試后在剛才的界面點(diǎn)擊流暢度（SM）出現(xiàn)下列界面，然后點(diǎn)擊磁盤圖標(biāo)，保存log到指定名字的文件夾。

6）最后利用各種工具（比如應(yīng)用寶）把log導(dǎo)入到PC端進(jìn)行后期處理（文件保存在SD卡/GT/GW/進(jìn)程名/自定義文件夾名下）。

注：以上的操作因?yàn)樯婕暗竭M(jìn)程注入需要手機(jī)Root權(quán)限，如果不能使用可以郵件給我，地址見文章末尾處。

7. 那么SM實(shí)際的測試效果如何？

所以，我們拿a、b、c三個(gè)瀏覽器為例，對比評測下這樣的數(shù)據(jù)和人感受是否對應(yīng)得上。首先，我們?yōu)榱税迅泄俸腿说母惺軐?yīng)上特把主動(dòng)感官分?jǐn)?shù)對應(yīng)到以下幾種描述如下表：

場景1. 瀏覽妹子圖……看看流暢度（SM）和丟幀（SF）之間關(guān)系

來看看流暢度（SM）和丟幀（SF）之間關(guān)系…這個(gè)數(shù)據(jù)是用瀏覽器瀏覽妹子圖時(shí)采集。因?yàn)閬G幀是個(gè)不連續(xù)的過程，所以后面的圖中丟幀都是以點(diǎn)來表示其離散的狀態(tài)。

從上面圖可以看出：

• 丟幀（SF）越多流暢度（SM）越低…

• 26:16秒后到26:42之間流暢度很低并且丟幀最密集，在這段期間流暢度主觀評分在2.5。

• 再看看這期間流暢度，丟幀和主觀的對應(yīng)關(guān)系：

從這個(gè)數(shù)據(jù)可以看到丟幀（SF）越多流暢度（SM）越低，并且主觀感覺是比較卡的（界面滑動(dòng)明顯頓挫感，響應(yīng)用戶輸入有種慢半拍的感覺）。

場景2. 看妹子圖……引入FPS看看這3者關(guān)系…

同樣這段看妹子的過程中主觀感受也是在2.5分：

這個(gè)數(shù)據(jù)里面引入了FPS數(shù)據(jù)。從上圖可以看出：

• 雖然FPS曲線和SM曲線差不多而且同樣受丟幀的影響；

• 里面有幾段比較奇怪的地方：

1）流暢度很高FPS比較低，無丟幀情況…當(dāng)時(shí)靜置在某個(gè)界面沒有動(dòng)此時(shí)主觀評分應(yīng)該在4.5左右；

2）FPS比較高，丟幀很嚴(yán)重流暢度很低…當(dāng)時(shí)在不斷刷新很多圖片出來主觀評分應(yīng)該在2.0以下。

把這2部分?jǐn)?shù)據(jù)放大看：

流暢度很高FPS比較低無丟幀：

本場景數(shù)據(jù)統(tǒng)計(jì)：

這個(gè)局部場景雖然畫面一直在動(dòng)，沒有丟幀F(xiàn)PS在20以下但是流暢度比較高。So…從次場景可以看出這樣流暢度SM比FPS更加適合來客觀描述Android App卡的程度。

8. 問題來了：這么多數(shù)據(jù)實(shí)在hold不住

從上面可以看出數(shù)據(jù)量比較大而且?guī)讉€(gè)產(chǎn)品條曲線之間有交錯(cuò)那如何評定哪個(gè)在某些場景下更好呢？于是我們就想：通過SM數(shù)據(jù)判斷App流暢情況，并給出一個(gè)定量的結(jié)果。

思路：

1. 不能直接用平均值和方差。根據(jù)以往經(jīng)驗(yàn)，通過平均值、方差等一些指標(biāo)，并不好說明問題。如果卡頓時(shí)間出現(xiàn)較短，測試時(shí)間較長，則平均值和方差這種指標(biāo)不容易發(fā)現(xiàn)問題，但是又確實(shí)有卡頓。平均值和方差適合描述服從正態(tài)分布的隨機(jī)變量，但是測試得到的SM值并不是這樣的隨機(jī)變量。

2. 將測試結(jié)果按卡頓和流暢分段，對每個(gè)卡頓區(qū)間段打分。參考了KM上一篇游戲流暢度評分的文章，該文章結(jié)合FPS平均值和卡頓的程度以及頻率，對游戲整體流暢度打分。但是普通App和游戲區(qū)別還是比較大的。對普通App來說，用戶不是一直在操作，不同的操作差異也較大，因此卡頓的頻率一般較低，用平均值和卡頓的頻率打分得到的結(jié)果可能會(huì)偏高。所以把測試過程按照卡頓和流暢分段，計(jì)算每個(gè)卡頓區(qū)間的打分和持續(xù)時(shí)間可能更有參考意義。

3. 總體打分時(shí)加大卡頓時(shí)的權(quán)重，降低流暢區(qū)間的權(quán)重。雖然我們重點(diǎn)關(guān)注的可能是卡頓的地方，但是競品測試，以及兩個(gè)版本對比又需要有總體評判結(jié)果，不能只看局部。為了加大結(jié)果的區(qū)分度，對卡頓區(qū)間增加權(quán)重，對流暢區(qū)間降低權(quán)重。突出卡頓對整體評分的影響。因此，評估結(jié)果將包括兩部分：總體打分以及卡頓區(qū)間，流暢區(qū)間的持續(xù)時(shí)間和打分。

流暢度評估方法：

1. 預(yù)處理，每5個(gè)（秒）一組，取最低值。如果5秒內(nèi)出現(xiàn)多于一次卡頓（SM低于40），則再乘以一個(gè)和卡頓次數(shù)有關(guān)的權(quán)值（小于1）。說明：如果卡頓出現(xiàn)次數(shù)較少，平均值和方差不容易發(fā)現(xiàn)問題。因此沒有直接對數(shù)據(jù)評估，先進(jìn)行了預(yù)處理，突出SM值低的部分，加大卡頓對總分的影響。

   
   

處理前三組數(shù)據(jù)：

處理后三組數(shù)據(jù)：

2. 將處理后的數(shù)據(jù)按卡頓和流暢分段，針對每段打分。說明：如果只有最后總分，且流暢的時(shí)間較長，卡頓的數(shù)據(jù)容易被流暢的數(shù)據(jù)淹沒。而且有些測試場景存在一段流暢，一段卡頓的現(xiàn)象，卡頓并不一定在整個(gè)測試過程中存在。這樣分開流暢和卡頓的區(qū)間處 理，更容易看出卡頓的程度。

3. 根據(jù)測試經(jīng)驗(yàn)，對SM值對應(yīng)的卡頓嚴(yán)重程度打分。說明：根據(jù)測試同學(xué)的經(jīng)驗(yàn)，流暢度指標(biāo)SM低于40時(shí)，用戶能感知到卡頓，SM在20以下卡頓比較嚴(yán)重。因此在打分時(shí)，SM值在20以下時(shí)打分最低，對應(yīng)0-20，在20-30區(qū)間打分低，對應(yīng)20-60，30-40區(qū)間打 分較低，對應(yīng)60-70，40以上打分在70以上。

4. 總體打分時(shí)降低流暢區(qū)間的權(quán)重。說明：這樣處理的原因和第一項(xiàng)的原因一樣，我們更關(guān)注的是卡頓，流暢區(qū)間過長時(shí)會(huì)淹沒卡頓的數(shù)據(jù)。

然后我們拿同一個(gè)測試場景下的測試數(shù)據(jù)出來對比一下：

1）網(wǎng)頁滑動(dòng)（Nexus 4上測試）：

測試方法：打開某網(wǎng)站，來回上下滑動(dòng)，在滑動(dòng)的過程中記錄流暢度數(shù)據(jù)。

流暢度評估數(shù)據(jù)：

從上面的數(shù)據(jù)可以看出滑動(dòng)瀏覽網(wǎng)頁的時(shí)候，其中c瀏覽器略微好于其他兩個(gè)。當(dāng)然這都是在性能比較好的手機(jī)（N4）上測試主觀感受差距不大但是從量化數(shù)據(jù)上可以看出優(yōu)劣。評分差距就和主觀感受拉開分值差不多能對應(yīng)上，從客觀上可以證明這套評分算法某種程度上的準(zhǔn)確性。

作者簡介：葉方正 2008年加入騰訊，目前就職于無線研發(fā)部專項(xiàng)評測組。曾在微博、手機(jī)QQ、瀏覽器等項(xiàng)目組負(fù)責(zé)性能優(yōu)化工作，積累大量的移動(dòng)終端平臺(tái)優(yōu)化以及評測經(jīng)驗(yàn)，郵箱地址：Michaelye#tencent.com（請把#改成@）。

本文為CSDN原創(chuàng)，點(diǎn)擊“閱讀原文”可查看全文并參與討論。

如果您喜歡這篇文章，請點(diǎn)擊右上角“…”將本文分享給你的朋友。