前言

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

一,、內存

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

• 編譯代碼

• 選定測試場景（來自于經驗&開發(fā)）

• 測試場景轉換成用例

• 跑起工具Run用例

• 結合代碼,，分析,，分析…

  
  

1.內存測試通用的方法

測試分析內存有以下幾種方法：

• DDMS（Heap&Allocation Tracker）

Heap查看堆的分配情況：

主要關注兩項數據：

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

2）Allocated堆中已分配的大小,，這是應用程序實際占用的內存大小,，資源回收后，此項數據會變小,。

注：如果進行反復操作,，或堆的大小一直增加，則有內存泄漏的隱患,。

Allocation Tracker跟蹤內存分配情況：

MAT（Memory Analyzer）

• Leak Suspects：內存泄露報告

• Top Components：吃貨報告

• Histogram：每個Class占用內存

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

2. Android常見的內存問題

Android常見的內存問題有：

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

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

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

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

• 大胖子Bitmap

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

可以找到這塊內存的引用關系,，然后找代碼,。

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

1）及時的銷毀,；
2）設置一定的采樣率,；
3）巧妙的運用軟引用（SoftRefrence）。

• Cursor

Cursor用完記得關掉,，如果實在不確定Cursor是否關閉,，可以在onDestroy中關了。

總的來說,，沒有嚴格意義上泄露只是你hold太久,。

二、流暢度

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

首先從下面開始…

1. Android如何繪制UI

   
   

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

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

2. 先VSync開始

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

如上圖所示在VSync機制下的繪制過程。從上面的圖看CPU和GPU處理時間都很快都少于一個VSync的間隔也就是16ms，并且每個間隔都有繪制的情況下那么當前的FPS即是60幀,。當CPU和GPU處理時間都很慢或者因為其他的原因,，比如在主線程中干活太多那么就會出現如下圖這樣的狀況。

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

Oh my ladygaga~~~這些把灑家看暈了…那打個比方講得通俗點。

VSync機制就像是一臺轉速固定的發(fā)動機（60轉/s）,。它每一轉帶動著去做一些UI相關的事情,，但是不是每一轉都會有工作去做（就像有時在空擋，有時在D檔）,。有時候因為各種阻力某一圈工作量比較重超過了16.6ms,，那么這臺發(fā)動機這秒內就不是60轉了，當然也有可能被其他因素影響比如給油不足（主線程里干的活太多）等等,。就會出現轉速降低的狀況我們把這個轉速叫做流暢度,。

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

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

• 丟幀（SF: Skipped Frame）：如上圖所示情況應該在16ms完成工作卻因各種原因沒做完,，占了下n個16ms的時間，相當于丟了n幀,。

• 流暢度（SM: SMoothness）：和丟幀相對,，在VSync機制中1s內Loop運行的次數。

1）和丟幀相對1s內有60個Loop因為某幾次工作時間超過了16ms（丟幀）,，這樣Loop就無法運行60次（理論最大值）,。

2）當流暢度越小的時候說明當前程序越卡頓。

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

接著上面的結論如果在這樣的機制下每次Loop運行之前通知我下,，我就記個數就好了,。

很幸運我們在新的Android的那一套機制中找到了一個畫圖的打雜工Choreographer這個對象。根據Google的官方API文檔描述他是用來協調animations,、input以及drawing時序的,，并且每個Looper共用一個Choreographer對象。

Choreographer的定義和結構：

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

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

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

2) 如果沒有以上事件的時候同樣也會運行這樣一個Loop,；

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

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

• 可以在Choreographer的回調FrameCallback中按秒計數表示當前App的流暢程度,。

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

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

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

2）選擇被測進程&點擊射它：

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

4）開始做相關的測試測試,。

5）完成測試后在剛才的界面點擊流暢度（SM）出現下列界面，然后點擊磁盤圖標,，保存log到指定名字的文件夾,。

6）最后利用各種工具（比如應用寶）把log導入到PC端進行后期處理（文件保存在SD卡/GT/GW/進程名/自定義文件夾名下）,。

注：以上的操作因為涉及到進程注入需要手機Root權限,，如果不能使用可以郵件給我,，地址見文章末尾處,。

7. 那么SM實際的測試效果如何？

所以,，我們拿a,、b,、c三個瀏覽器為例,，對比評測下這樣的數據和人感受是否對應得上,。首先,，我們?yōu)榱税迅泄俸腿说母惺軐咸匕阎鲃痈泄俜謹祵揭韵聨追N描述如下表：

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

來看看流暢度（SM）和丟幀（SF）之間關系…這個數據是用瀏覽器瀏覽妹子圖時采集,。因為丟幀是個不連續(xù)的過程，所以后面的圖中丟幀都是以點來表示其離散的狀態(tài),。

從上面圖可以看出：

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

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

• 再看看這期間流暢度,，丟幀和主觀的對應關系：

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

場景2. 看妹子圖……引入FPS看看這3者關系…

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

這個數據里面引入了FPS數據,。從上圖可以看出：

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

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

1）流暢度很高FPS比較低，無丟幀情況…當時靜置在某個界面沒有動此時主觀評分應該在4.5左右,；

2）FPS比較高,，丟幀很嚴重流暢度很低…當時在不斷刷新很多圖片出來主觀評分應該在2.0以下。

把這2部分數據放大看：

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

本場景數據統(tǒng)計：

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

8. 問題來了：這么多數據實在hold不住

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

思路：

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

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

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

流暢度評估方法：

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

   
   

處理前三組數據：

處理后三組數據：

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

3. 根據測試經驗,，對SM值對應的卡頓嚴重程度打分,。說明：根據測試同學的經驗，流暢度指標SM低于40時,，用戶能感知到卡頓,，SM在20以下卡頓比較嚴重。因此在打分時,，SM值在20以下時打分最低,，對應0-20，在20-30區(qū)間打分低,，對應20-60,，30-40區(qū)間打 分較低，對應60-70,，40以上打分在70以上,。

4. 總體打分時降低流暢區(qū)間的權重。說明：這樣處理的原因和第一項的原因一樣,，我們更關注的是卡頓,，流暢區(qū)間過長時會淹沒卡頓的數據。

然后我們拿同一個測試場景下的測試數據出來對比一下：

1）網頁滑動（Nexus 4上測試）：

測試方法：打開某網站,，來回上下滑動,，在滑動的過程中記錄流暢度數據。

流暢度評估數據：

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

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

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

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