一、 App 性能指標

App 性能問題如 app 使用時卡頓嚴重或者加載頁面慢，cpu 占用率高，app 閃退等，在測試過程中，則需特別關注性能方面的體驗，app 性能差，通常會導致用戶對 app 的使用率下降，卸載率上升。

性能專項測試用戶維度

性能專項測試技術維度

響應
軟件的響應時間和響應速度直接影響到用戶的體驗度，如果一個軟件，遲遲加載不出來，會直接影響到軟件的日活、留存。因此對于一個軟件，對響應速度測試是必不可少的。
優秀：0～400ms，標準：400ms～2000ms，輕微隱患：2000ms～5000ms，嚴重隱患：5000ms 以上。
內存
在 Android 系統中，每個 APP 進程除了同其他進程共享內存(shared dirty)外，還獨用私有內存(private dirty)，通常我們使用 PSS(私有內存+比例分配共享內存)來衡量一個 APP 的內存開銷。由于一個移動設備的內存是固定的，如果內存消耗過大就會造成應用卡頓或者閃退，需要對內存進行測試。正常情況下，應用不應占用過多的內存資源，且能夠及時釋放內存，保證整個應用內的穩定性和流暢性。
CPU
主要關注的 CPU 的占用率。玩手機時，會出現發熱發燙，那是因為 CPU 使用率過高，CPU 過于繁忙，會使整個手機無法響應用戶，整體性能降低，用戶體驗就會很差，也容易引起 ANR（application not responding，應用程序無響應，主線程(UI線程)如果在規定時內沒有處理完相應工作，就會出現 ANR）等等一系列問題。
FPS
應用的使用流暢度，FPS 是圖像領域中的定義，是指畫面每秒傳輸幀數，通俗來講就是指動畫或視頻的畫面數。FPS 是測量用于保存、顯示動態視頻的信息數量。每秒鐘幀數愈多，所顯示的動作就會愈流暢。
一般，Android 設備的屏幕刷新率為 60 幀/s，要保持畫面流暢不卡頓，要求每一幀的時間不超過 1000/60=16.6ms，這就是 16ms 的黃金準則，如果中間的某些幀的渲染時間超過 16ms，就會導致這段時間的畫面發生了跳幀，因此原本流暢的畫面變發生了卡頓。
GPU 過度渲染
GPU 渲染是指在一個像素點上繪制多次（超過一次）：顯示一個什么都沒有做的activity 界面算作畫了 1 層，給 activity 加一個背景是第 2 層，在上面放了一個 TextView（有背景的 Text View）是第 3 層，Text View 顯示文本就是第 4 層，僅僅只是為了顯示一個文本，卻在同一個像素點繪制了四次，這一定要優化的。過度繪制對動畫性能的影響是極其嚴重的，如果你想要流暢的動畫效果，那么一定不能忽視過度繪制。
耗電量
測試應用對電量的消耗前需要對手機本身的電量消耗有個大概了解，測試前先看規定時間內手機正常待機下（重啟后待機）電量消耗為多少，然后再啟動待測試 APP看看消耗的電量增加了多少取差值。

測試點：
?測試手機安裝目標 APK 前后待機功耗無明顯差異；
?常見使用場景中能夠正常進入待機，待機電流在正常范圍內；
?長時間連續使用應用無異常耗電現象。
流量測試
目前的網絡類型包含 2G3G4Gwifi，其中還有不同運營商的區分，我們在 APP 的使用中經常遇到大資源，重復請求，調用響應慢，調用失敗等各種情況。在不同的網絡類型之下，我們不僅加快請求的響應，還要控制流量使用。
每秒鐘平均流量，建議值<5.12kb，每 10 分鐘平均流量，建議值<3MB,不存在 app偷跑流量等行為。

二、 使用 adb 進行測試

1.App 響應時間和響應速度測試

1.1 主要測試點
冷啟動：首次啟動 app 的時間間隔（只是啟動時間，不包括頁面加載）
熱啟動：非首次啟動 app 的時間間隔（只是啟動時間，不包括頁面加載）
Activity的啟動流程

1.2 測試方法
冷啟動
adb shell am start -W com.tencent.mm/.ui.LauncherUI（啟動App)
adb shell am force -stop 包名（停止APP）
?絕對路徑，首個 Activity
? am 是 shell 中集成的一個命令，ActivityManager 的簡寫。
? -W 是指啟動完成之后，返回啟動耗時。
?可能存在 app 緩存（提示 Warning: Activity not started, intent has beendelivered to currently running top-most instance），建議重新打開模擬器后，直接運行命令

含義
? ThisTime: 該 Activity 的啟動耗時，單位 ms；
? TotalTime: 應用自身啟動耗時, ThisTime+應用application等資源啟動時間；
? WaitTime: 系統啟動應用耗時, TotalTime+系統資源啟動時間。
如果只關心某個應用自身啟動耗時，參考 TotalTime；如果關心系統啟動應用耗時，參考 WaitTime；如果關心應用所有界面 Activity 啟動耗時，參考 ThisTime。
熱啟動

按返回按鍵（adb shell input keyevent 3）后再啟動 adb 命令
測試標準：冷啟動時間不超過 1.5s，熱啟動不超過 1s。
注意：此種方法不包含頁面渲染時間。
可以通過錄屏逐幀的方式獲取到首屏渲染時間。
andriod錄屏方式：
adb shell screenrecord --time-limit 10 /sdcard/video.mp4（--time-limit 10：限制錄制時間10s,不做限制默認為180s）
adb pull/sdcard/video.mp4 /user/desktop/video
錄屏逐幀
通過ffmpeg分幀（ffepeg的配置參考：https://blog.csdn.net/chy466071353/article/details/54949221）
ffmpeg -i d:/test/video.mp4 -r 10 -threads 2 d:/test/Android-Capture-%05d.png (-r 10 表示1s分成10幀,即1幀為0.1s)
視頻內容包含：桌面 → 被測 App 圖標變黑 → 展示知乎開屏 → 展示主體框架 → 首頁內容加載完成。
由于首頁內容加載完成是異步實現的，因此我們選取分析的關鍵節點，是「被測 App 圖標變黑」和「展示主體框架」這兩個點。
通過 FFmpeg 將視頻轉換成分幀后的圖像，用[展示主體框架]圖片的后綴減去[被測圖片APP變黑]的后綴*0.1s。

(49-11)*0.1=3.8s

1.3ios啟動時長的獲取
參考https://zhuanlan.zhihu.com/p/48218035，主要方式也是錄屏。

常見的 iOS 啟動時長測試方法，主要有以下幾種

Xcode Developer Tool： 使用 Instruments 的 Time Profiler 插件，可以檢測 App CPU 的使用情況。能看到 App 的啟動時間和各個方法消耗的時間；
客戶端計算統計： 通過 hook 關鍵函數的調用，計算獲得性能數據。目前知乎 App 性能監控已有啟動時長數據，類似的還有一些第三方的性能測試工具；
錄屏：使用截屏、錄屏、高速攝像機錄像等方法，記錄移動設備屏幕上的變化，分析啟動的起止點，獲取 app 啟動的耗時。

方法 1 可以精確獲取各個方法調用的耗時，需要 App 是 developer 證書簽名，否則無法執行測試；

方法 2 可以精確獲取各個啟動項耗時，但和實際用戶體驗感受有一定出入，且需要拿到客戶端源碼，將工具嵌入客戶端中；

方法 3 和用戶直觀感受一致，但分析截屏、視頻較麻煩，且發現問題時，無法定位到具體的啟動耗時項。

目前對于競品啟動時長的對比測試，由于源碼和簽名的限制，方法 1 和 2 都不太合適。

注意：有時會存在啟動頁面廣告，而各 App 在展示開屏廣告的過程中，可能會有其他啟動項在執行。所以需要分兩個場景進行測試，有廣告和無廣告。

2 .內存占用測試

2.1 主要測試點

空閑狀態
　　切換至后臺或者啟動后不做任何操作，消耗內存最少。
中強度狀態
　　時間偏長的操作應用。
高強度狀態
　　高強度使用應用，可以跑 monkey 來測試（通常用來測試內存泄漏）。
　　內存泄漏(OOM）:指使用 malloc 或 new 申請了一塊內存，但是沒有通過 free 或 delete 將內存釋放，導致這塊內存一直處于占用狀態。

2.2 測試方法

使用 adb 命令
adb shell dumpsys meminfo com.tencent.mm
主要指標
Native heap allocNative：代碼分配的內存，虛擬機和Android框架分配內存。
Dalvik heap alloc：Java對象分配的占據內存

若這兩個值一直增長，說明可能出現內存泄漏
PSS：App 實際占用的內存大小。

主要關注
?退出某個頁面后，內存是否有回落。
如果沒有及時回落，且程序自動 GC（Garbage Collection，垃圾回收）或者手動 GC，那便可確認有問題。
?進行某個操作后，內存是否增長過快。
如果增長過快，也有可能存在風險，需重復操作確認

android內存主要有四種形式：VSS 、RSS 、PSS 、 USS

一般來說內存占用大小有如下規律：VSS >= RSS >= PSS >= USS

VSS：Virtual Set Size，虛擬耗用內存。它是一個進程能訪問的所有內存空間地址的大小。這個大小包含了
一些沒有駐留在RAM中的內存，就像mallocs已經被分配，但還沒有寫入。VSS很少用來測量程序的實際使
用內存。

RSS：Resident Set Size，實際使用物理內存。RSS是一個進程在RAM中實際持有的內存大小。RSS可能會
產生誤導，因為它包含了所有該進程使用的共享庫所占用的內存，一個被加載到內存中的共享庫可能有很
多進程會使用它。RSS不是單個進程使用內存量的精確表示。

PSS：Proportional Set Size，實際使用的物理內存，它與RSS不同，它會按比例分配共享庫所占用的內存。
例如，如果有三個進程共享一個占30頁內存控件的共享庫，每個進程在計算PSS的時候，只會計算10頁。
PSS是一個非常有用的數值，如果系統中所有的進程的PSS相加，所得和即為系統占用內存的總和。當一個
進程被殺死后，它所占用的共享庫內存將會被其他仍然使用該共享庫的進程所分擔。在這種方式下，PSS
也會帶來誤導，因為當一個進程被殺后，PSS并不代表系統回收的內存大小。

USS：Unique Set Size，進程獨自占用的物理內存。這部分內存完全是該進程獨享的。USS是一個非常有用
的數值，因為它表明了運行一個特定進程所需的真正內存成本。當一個進程被殺死，USS就是所有系統回
收的內存。USS是用來檢查進程中是否有內存泄露的最好選擇。

內存

JAVA是在JVM所虛擬出的內存環境中運行的，JVM的內存可以分成三個區，堆（heap）、棧（stack）和方法區（method）。

棧（stack）

是最簡單的數據結構，但在計算機中使用廣泛。棧最顯著的特征是：LIFO(后進先出），棧中只存放基本類型和對象的引用（不是對象）

堆（heap）

堆內存用于存放由new創建的對象和數組。在堆中分配的內存，由java虛擬機自動垃圾回收器來管理。JVM只有一個堆區被所有線程共享，堆中不存放基本類型和對象引用，只存放對象本身。

方法區（method）

又叫靜態區，跟堆一樣，所有的線程共享。方法區包含所有的static變量。

內存泄露

程序在向系統申請分配內存空間后（new）,在使用完畢后未釋放。結果導致一直占用該內存單元，我們和程序都無法再使用該內存單元，直到程序結束。

內存溢出

程序向系統申請的內存空間超出了系統能給的，比如一車最多坐5個人，你確非要塞下10個，車就擠爆了。

大量的內存泄露會導致內存溢出（OOM）

內存泄露對應用的影響

內存泄露對于APP沒有直接危害，即使有發現內存泄露的情況，也不一定會引起APP崩潰

內存得不到釋放，慢慢的會造成app內存溢出，導致崩潰

內存泄露同時會觸發系統頻繁GC,發生內存抖動，會導致性能問題（卡頓不流暢）

3.CPU 繁忙測試

3.1 主要測試點

?在空閑時間(切換至后臺)的消耗，基本沒大應用使用 CPU
?在運行一些應用的情況下，CPU 已占 50%的情況下，觀察應用程序占用 CPU 的情況
?在高負荷的情況下看 CPU 的表現（CPU 占用應是在 80%以上）

3.2 具體場景

?應用空閑狀態運行監測 CPU 占用率
應用按 Home 鍵退到后臺，不再占用系統的狀態（通常是滅屏半分鐘后）
CPU 占用率=0%
?應用中等規格運行監測 CPU 占用率
模擬用戶最常見的使用場景
CPU 占用率≤30%
?應用滿規格長時間正常運行監測 CPU 占用率
應用正常運行，打開應用進行基本操作
CPU 占用率≤50%

3.3 測試方法

adb shell dumpsys cpuinfo apk 包名

adb shell top -m -s | findstr packageName
? -m 數字
顯示指定數目的最大值，一般后面不再接 findstr
使用-m 會導致隱藏列名
? -s 數字
按指定列號進行倒序排列
從 1 開始，最大 11
9 代表 CPU，10 代表內存
?-n 數字
刷新幾次后退出
? -d 秒數
刷新間隔
? q 回車
退出

4.FPS 應用流暢度測試

幀率(Frame Rate)：代表GPU在一秒內繪制操作的幀數，例如：30fps，60fps

刷新頻率(Refresh Rate):代表屏幕在一秒內刷新屏幕的次數，這取決于硬件的固定參數，如60HZ.

(1)開啟 Profile GPU renderingSettings→System→Advanced→Developer options→查找 profile→找到并單擊 ProfileGPU rendering→In adb shell dumpsys gfxinfo
(2)打開要測試的 app

adb shell dumpsys gfxinfo 包名

? Graphics info for pid 1331 [com.tencent.mm]：表明當前 dump 的為 com.tencent.mm的幀信息，pid 為 1331。
? Total frames rendered: 2218：本次 dump 搜集了 2218 幀的信息。
? Janky frames: 26 (1.17%)：幀中有 26 幀的耗時超過了 16ms，卡頓概率為 1.17%。
? Number Missed Vsync: 3：垂直同步失敗的幀
? Number High input latency:2213：處理 input 時間超時的幀
? Number Slow UI thread: 1：因為 ui 線程導致 slow 的幀
? Number Slow bitmap uploads: 0：因為 bitmap 加載 slow 的幀
? Number Slow issue draw commands: 3：因為繪制導致 slow 的幀

? Draw: 表示在 Java 中創建顯示列表部分中的 OnDraw()方法占用的時間。
? Prepare：表示渲染引擎準備時間。
? Process：表示渲染引擎執行顯示列表所花的時間，view 越多，時間就越長。
? Execute：表示把一幀數據發送到屏幕上排版顯示實際花費的時間。其實是實際顯示幀數據的后臺緩沖區與前臺緩沖區交換后，將前臺緩沖區的內容顯示到屏幕上的時間。
? Draw + Perpare+Process + Execute = 完整顯示一幀 ，這個時間要小于 16ms 才能保存每秒60 幀。
?通過 execl 進行表格處理可以直觀的查看軟件的流暢度
只保留 Process、Draw、Execute,將三列加和繪制線圖;16ms 以上的卡頓，需要優化

? Settings→System→Advanced→Developer options→查找 profile→on screen as bars結果以圖形形式顯示在設備中
開啟此功能后，隨著屏幕刷新，界面上會滾動顯示垂直的柱狀圖來表示每幀畫面所需要渲染的時間，柱狀圖越高表示花費的渲染時間越長。
每個直方條代表一幀，每個直方條的高度表示該幀渲染所用的時間（以毫秒為單位）
界面中間一根綠色水平線代表 16ms，每一幀的柱狀線都在這條綠線以下，才能避免出現由丟幀引起的卡頓。

?顏色含義（Android 6.0 及更高版本中的豎條區段）

5.GPU 過度渲染測試

開啟 GPU 過度渲染

?設置→開發者選項→單擊 Debug GPU overdraw→選擇 show overdraw areas

? GPU 過渡渲染不同的顏色代表不同的繪制程度
原色：無過渡繪制
藍色：繪制一次 （理想狀態）
綠色：繪制二次
淺紅：繪制三次 （可以優化）
深紅：繪制四次 （必須優化）

測試指標
?控制過渡繪制為 2x
?不允許存在 4x 過渡繪制
?不允許存在面積超過屏幕 1/4 的 3x 過渡繪制

6、流量數據獲取

先獲取進程命令 adb shell ps | grep 包名
獲取流量：adb shell cat /proc/進程名/net/dev
receive表示收包（下行）
Transmit表示收包（上行）
bytes表示收發的字節數
packets表示收發正確的包量
errs:表示收發錯誤的包量
drop表示收發丟棄的包量

7、電量數據獲取

adb shell dumpsys battery set status 1（設置手機進入非充電狀態 2為充電狀態）
db shell dumpsys battery（獲取電量） level表示電量

8、如何開展性能專項測試

1）什么時間點開展？

一般情況只有大版本迭代或者重點性能優化才進行

2）基于什么基礎上測試？

歷史版本&競品

3）什么時間點開展？

一般在第一輪測試結束無需大修改

4）要哪些場景？

App核心場景，需要優化場景

5）要測什么包？

一般測正式包，反應真是用戶體感

6）要測幾輪？

一般正式測試一輪，剩余看開發優化

9、性能專項測試流程

1）跟進版本確定這個版本性能測試需求

2）跟開發確定測試場景和側重點，并且確定基線數據和測試手段

基線數據：前三個版本的最優數據和競品數據

3）執行性能測試采集數據

4）編寫性能測試報告

10、性能專項測試報告

1）基本信息：版本/測試機型/測試場景/基線場景

2）問題概述：具體問題列表

3）具體性能專項數據列表

4）修復建議/風險

實例：

總結

以上是生活随笔為你收集整理的移动APP性能测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。