1.開機時間：

一般測試的方法是人工計時，這的確是個不錯的方法，但是耗時耗力，最重要的人工測試誤差較大，而我經過查問，知道了在adb工具下有個命令：

adb shell cat /proc/bootprof

（說白了也就是查看Linux內黑下的proc文件夾中的內容）是可以反映出啟動過程中的每個進程消耗了多少時間，依此疊加來顯示開機時間。

2.主頁滑動時的刷新率（home_fps）

一般來說，桌面是用戶接觸最多的一個場景，而桌面滑動的流暢性是至關重要的一個體驗標準。即使使用當今最強的CPU，系統優化不好，桌面程序寫的不行，要卡還是得卡，這個用安卓的朋友都有很大的體驗。它的測試在MTK的平臺下，筆者借助的是SurfaceFlinger，只要執行：

adb logcat -s SurfaceFlinger | findstr fps

當快速滑動住頁面的時候，屏幕上就會閃現當前的fps值，即屏幕刷新率。一般來說，只有fps達到60的時候，人眼才會感覺很絲滑流暢，沒有卡頓，可惜筆者測試了幾個機器，都沒有達到這個水準的。

3.應用第一次啟動時間

應用第一次啟動的時候，內存中沒有任何該應用的信息，是從頭開始，才能正確反應速度的快慢。

②通過eclipse的DDMS工具，過濾log，過濾的tag值為ActivityManager，Level值為I，在啟動的時候可以找啟動應用所需要的時間，經過驗證與方法1時間長短是一致的

4.非滑動下的fps，這個就是你日常操作的時候的流暢度，有專門的軟件：fps2d 可以測試

2.1 性能指標

a，響應時間/加載速度

b，動畫幀率

圖片處理器每秒刷新的幀數(FPS)，可用來指示頁面是否平滑的渲染。高的幀率可以得到更流暢，更逼真的動畫，不過幀率達到60fps以上，人眼主觀感受到的差別就不大了。所以以60fps作為衡量標準，即要求每一幀刷新的時間小于16ms，這樣才能保證滑動中平滑的流暢度。

c，內存使用

在android系統中，每個APP進程除了同其他進程共享(shared dirty)外，還獨用私有內存(private dirty)，通常我們使用PSS(=私有內存+比例分配共享內存)來衡量一個APP的內存開銷。移動設備的內存資源是非常有限，為每個APP進程分配的私有內存也是有限制。一方面我們要合理的申請內存使用，以免導致頻繁的GC影響性能和大對象申請發生內存溢出；另一方面，我們要及時釋放內存，以免發生內存泄漏。

d，電量

相對于PC來說，移動設備的電池電量是非常有限的，保持持久的續航能力尤為重要。另外，android的很多特性都比較耗電(如屏幕，GPS，sensor傳感器，喚醒機制，CPU，連網等的使用)，我們必須要慎重檢查APP的電量使用，以免導致用戶手機耗電發熱，帶來不良體驗。

e，流量

目前的網絡類型包含2G\3G\4G\wifi，其中還有不同運營商的區分，我們在APP的使用中經常遇到大資源，重復請求，調用響應慢，調用失敗等各種情況。在不同的網絡類型之下，我們不僅要控制流量使用，還需要加快請求的響應。

f，ANR

在android應用程序中，如果主線程(即UI線程)在超時間內對用戶輸入時間沒有處理完畢，就會出現Application note responding彈出框，用戶可以選擇等待或者強制關閉來殺死進程。

g，app crash閃退

由于空指針，內存泄漏，數組越界等等編碼問題，導致應用程序在移動設備上運行異常，發生閃退，進程被殺。

頻繁發生的問題會導致用戶體驗差，最終使用戶卸載APP。

2.2 適配機型

對市面上的android機型活躍用戶數量進行統計。將其劃分為高，中，中低，低4類型機，分別選擇其中使用量最大的作為代表機型，進行細致深入的性能測試分析。

也可以使用虛擬機進行模擬。

2.3 網絡

目前網絡有2G,2G/3G，3G，3G/4G，4G，wifi。通過統計查看每個網路的使用量。 其中弱網絡也許關注。特別是弱網絡+低端機型，性能的瓶頸尤其容易碰觸到。

(問題: 什么情況或者什么樣的網絡傳輸速度可以稱為弱網絡?)

3 場景設計

具體哪些場景需要性能測試，可以初步依據下面角度進行判斷:

1，業務層面，用戶最核心基礎的模塊。

2，新增的基礎邏輯，例如登入模塊，大量的用戶段時間內訪問，如此必須保證性能

3，活動需求，因為活動上的新邏輯，存在較的用戶訪問，需要盡力提升用戶體驗

4，用戶體驗不好的模塊

當場景A需要進行客戶端性能測試，那么個性能指標唯獨的表現都需要關心，排除改場景中是否存在下面這些性能問題:

a，頁面加載是否緩慢

b，滑動是否流暢

c，是否存在在內存泄露

d，流量開銷大不大

e，cpu占用高不高

f，電量消耗是否合理

g，是否有異常的crash和ANR

h，低端機下ANR是否加劇

開發相關:

a，主線程有沒有不合理的io調用

b，有沒有重復的網絡請求

c，圖片大小有沒有控制好

測試相關:

弱網絡下的加載速度是否可接受

網絡切換或者斷網時是否有異常

機型適配中是否有特殊情況等

4 監控分析

4.1 加載響應速度

在測試之前，我們需要了解一下activity的生命周期，比如從activity1跳轉到activity2，在我們點擊觸發之后，activity1是如何被暫停而activity2又是如何被創建執行的，過程中那些activity方法被調用到(也可以結合adb logcat -v time -b events查看對應activity切換事件)。

測試執行中，發現問題的方法有很多，肉眼也不失是一種辦法，如果想要更準確，可以通過埋點進行度量。另外adb logcat -v time -b events監控的am_activity_launch_time時間也可以參加，不過它僅僅統計到Activity.onResume()的調用。

一旦發現耗時問題，可以通過詳細的埋點來分析定位耗時的方法邏輯，當然還有一個更值得推薦的工具: traceview, 下面我們稍稍介紹一下它的使用。

1) 安裝可debug的apk包，啟動DDMS，找到對應進程，按下頭部工具欄按鈕"Start method profiling"，如圖4-1所示，一旦其變灰，開始監控。

2) 操作app，完成被測業務后，再次點擊頭部工具按鈕欄的對應按鈕，使其變紅。此時，監控結束，會自動生成解析后的trace文件

另外不通過DDMS，直接在app代碼中植入Debug類的StartMonitor和StopMonitor方法，也可在sdcard中得到trace文件，pull文件到電腦上，用sdk tools下的traceview命令打開trace文件即可。

4.2 滑動流暢度

4.2.1 View渲染原理

Android UI視圖窗口可以有N多個View組成，其中ViewGroup是一個特殊的View，繼承自android.view.view, 類似容器管理其子View和子ViewGroup。

4.2.2 流程度測試分析工具

4.2.2.1 gfxinfo

Android4.1引入gfxinfo，用于監控分析GPU profiling信息，Draw+Process+Execute是一幀的繪制渲染時間，如果持續超過16ms，用戶會明顯感知卡頓:

a: "Draw" : 創建顯示列表(display lists，記錄所有view對象的繪制指令)的時間開銷。

b: "Process" : 執行顯示列表中繪制指令的時間。UI視窗中的View數量越多，需要執行的繪畫命令就越多。

c: "Execute" : 將一幀圖像交給合成器compostior的時間。這部分占用的時間通常比較少

使用方法:

1) 打開android手機 “設置->開發者選項->GPU呈現模式分析"

2) 執行測試場景(比如滑動頁面)后，執行adb shell dumpsys gfxinfo packageName

3) 找到"Profile data in ms"的Draw Process Exceute這三列數據，Excel做出表格，sum出每列的總GPU時間

4) 針對時間大不幅度>16ms，可以使用systrace進行分析定位瓶頸。

4.2.2.2 systrace

Systrace是Android4.1引入的一套用于做性能分析的工具，使用它來診斷繪圖卡頓問題是非常有效的。生成的trace.html文件中可以在同一時間軸上清晰的對比進程線程的運行內容和狀態，展示VSYNC間隔, SurfaceFlinger進程信息,調用方法的執行耗時等，讓上下文運行狀態的分析更簡單方便。

4.2.2.3 Show GPU overdraw

顯示GPU過度渲染，從最美到最差依次是: 藍，綠，淡紅，紅

a，沒有顏色意味著沒有透支。像素只畫了一次。

b，藍色 : 意味著透支1倍。像素繪制了2次。

c，綠色：意味著透支2唄。像素繪制了3此

d，淡紅：意味著透支3倍。像素繪制了4次

e，紅：意味著透支4倍。像素繪制了5次或者更多

4.3 內存使用

雖然Android L 版本正式使用ART代替Dalvik虛擬機運行機制，但是考慮到當前市場份額，我們再次仍重要關注Dalvik虛擬機內存管理機制。需要注意：在Android2.×系統上，Bitmaps存儲在Navtive memory中，有recycle()進行釋放，而android3.0之后，bitmaps則存儲在dalvik heap中，由GC垃圾惠州機制進行回收釋放。

android app的內存問題主要發生在dalvik heap和navtive heap上。而dalvik heap的內存問題最為常見: 比如Activity內存泄漏，Bitmap內存泄漏，Bitmaps導致的內存溢出。

我們先了解一下對象和引用的關系，然后通過GC log看一下GC垃圾回收的集中模型

4.4 CPU 監控

在CPU持續使用較高或者不正常時，我們首先要確定APP相關進程的的占用，找到有問題的進程，在進一步跟進到具體線程，所以排除方位。比借助traceview和systemtrace進行分析。

4.5 流量

通常來說APP流量使用最大的兩部分是: 服務端api交互，圖片/css/js等cdn靜態資源。減少這兩個部分的資源個數和資源大小，能有效的限制流量的使用。另外還需要嚴格控制后臺靜默時流量的使用。

4.5.1 流量統計工具

DDMS Network Statistics

3款代理工具: fiddler, charles, wmock

抓包工具 : tcpdump

4.5.3 弱網絡模擬&網絡切換測試

使用 charles throttle settings模擬，能夠對上下行帶寬，丟包率，延遲等網絡參數進行設置

4.6 耗電量

4.6.1 耗電原理

手機中的每個部件運行時對應的能耗值都放在power_profile.xml文件中，而系統的 設置->電池->使用情況中，統計的能耗使用情況也是以power_profile.xml的value作為基礎參數的。通過命令監控app個部件的使用時長，然后結合設備耗電的基礎參宿進行加權計算，即可得到app使用的耗電量。

4.6.2 電量測試監控方法

充電關注前臺靜默和后臺靜默。即APP沒有被操作，但卻偷偷的在耗電。

a，系統自帶電池使用監控工具

b，adb shell dumpsys batteryinfo\batterystat 查看各部件耗時

4.6.3 查看CPU開銷導致的耗電情況

轉載自：

http://blog.csdn.net/tianxuhong/article/details/50911186

http://blog.csdn.net/tianxuhong/article/details/50911186