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開銷導致的耗電情況