App性能測試中的幾個(gè)重要概念總結(jié)

今天就來從我們軟件測試人員的角度，App驗(yàn)收測試過程中需要關(guān)注到一些指標(biāo)項(xiàng)目：內(nèi)存占用、CPU 占用、流量耗用、電量耗用、啟動(dòng)時(shí)間。下面針對每一個(gè)方面的一些重要知識點(diǎn)進(jìn)行了整理。

一. 內(nèi)存

1. 內(nèi)存泄漏

說到內(nèi)存方面，最經(jīng)典的內(nèi)存問題當(dāng)數(shù)內(nèi)存泄漏。百度上對內(nèi)存泄漏的定義是這樣的：內(nèi)存泄漏（Memory Leak）是指程序中己動(dòng)態(tài)分配的堆內(nèi)存由于某種原因程序未釋放或無法釋放，造成系統(tǒng)內(nèi)存的浪費(fèi)，導(dǎo)致程序運(yùn)行速度減慢甚至系統(tǒng)崩潰等嚴(yán)重后果。通俗點(diǎn)講，在大部分應(yīng)用中，會有一類功能是需要加載附加資源的，比如顯示從網(wǎng)絡(luò)下載的文本或圖片。這類功能往往需要在內(nèi)存中存放要使用的資源對象，退出該功能后，就需要將這些資源對象清空。如果忘了清理，或者是代碼原因造成的清理無效，就會形成內(nèi)存泄漏。

2. 垃圾回收

說到了內(nèi)存泄漏，又不得不提到垃圾回收，內(nèi)存中的垃圾，主要指的是內(nèi)存中已無效但又無法自動(dòng)釋放的空間，除非是重啟系統(tǒng)不然永遠(yuǎn)也不會還給操作系統(tǒng)。這樣以來，時(shí)間久了當(dāng)程序運(yùn)行的時(shí)候就會產(chǎn)生很多垃圾，一方面浪費(fèi)了不少內(nèi)存空間，另一方面如果同一個(gè)內(nèi)存地址被刪除兩次的話，程序就會不穩(wěn)定，甚至奔潰。

在 Java 程序運(yùn)行過程中，一個(gè)垃圾回收器會不定時(shí)地被喚起檢查是否有不再被使用的對象，并釋放它們占用的內(nèi)存空間。但垃圾回收器的回收是隨機(jī)的，可能在程序的運(yùn)行的過程中，一次也沒有啟動(dòng)，也可能啟動(dòng)很多次，它并不會因?yàn)槌绦蛞划a(chǎn)生垃圾，就馬上被喚起而自動(dòng)回收垃圾。所以垃圾回收也并不能完全避免內(nèi)存泄漏的問題。

另一方面，垃圾回收也會給系統(tǒng)資源帶來額外的負(fù)擔(dān)和時(shí)空開銷。它被啟動(dòng)的幾率越小，帶來的負(fù)擔(dān)的幾率就越小。

3. 內(nèi)存指標(biāo)

內(nèi)存指標(biāo)有 VSS、RSS、PSS、USS，他們的含義分別是：

VSS：Virtual Set Size 虛擬耗用內(nèi)存（包含共享庫占用的內(nèi)存）

RSS：Resident Set Size 實(shí)際使用物理內(nèi)存（包含共享庫占用的內(nèi)存）

PSS：Proportional Set Size 實(shí)際使用的物理內(nèi)存（按比例分配共享庫占用的內(nèi)存）

USS：Unique Set Size 進(jìn)程獨(dú)自占用的物理內(nèi)存（不包含共享庫占用的內(nèi)存）

一般來說內(nèi)存占用大小有如下規(guī)律：VSS >= RSS >= PSS >= USS，一般測試中關(guān)注的比較多的是 PSS 這個(gè)指標(biāo)。

二. CPU

1. 時(shí)間片

時(shí)間片即 CPU 分配給各個(gè)程序的時(shí)間，每個(gè)線程被分配一個(gè)時(shí)間段，稱作它的時(shí)間片，即該進(jìn)程允許運(yùn)行的時(shí)間，使各個(gè)程序從表面上看是同時(shí)進(jìn)行的。

2. Jiffies

Jiffies的概念

HZ：Linux 核心每隔固定周期會發(fā)出 timer interrupt (IRQ 0)，HZ 是用來定義每一秒有幾次 timer interrupts。例如 HZ 為 1000，就代表每秒有 1000 次 timer interrupts。

Tick：HZ 的倒數(shù)，Tick = 1/HZ，即 timer interrupt 每發(fā)生一次中斷的時(shí)間。如 HZ 為 250 時(shí)，tick 為 4 毫秒（millisecond）。

而 Jiffies 為 Linux 核心變量，是一個(gè) unsigned long 類型的變量，被用來記錄系統(tǒng)自開機(jī)以來，已經(jīng)過了多少 tick。每發(fā)生一次 timer interrupt，Jiffies 變數(shù)會被加 1。

3. CPU 使用率

在 Linux 系統(tǒng)下，CPU 利用率分為用戶態(tài)、系統(tǒng)態(tài)和空閑態(tài)，他們分別代表的含義為：用戶態(tài)表示 CPU 處于用戶態(tài)執(zhí)行的時(shí)間，系統(tǒng)態(tài)表示系統(tǒng)內(nèi)核執(zhí)行的時(shí)間，空閑態(tài)表示空閑系統(tǒng)進(jìn)程執(zhí)行的時(shí)間。

而一個(gè) App 的 CPU 使用率 = CPU 執(zhí)行非系統(tǒng)空閑進(jìn)程時(shí)間 / CPU 總的執(zhí)行時(shí)間，也可以表示為 App 用戶態(tài) Jiffies + App 系統(tǒng)態(tài) Jiffies / 手機(jī)總 Jiffies。

4. CPU 過高會帶來的影響

可能會使整個(gè)手機(jī)無法響應(yīng)，整體性能降低，引起 ANR，導(dǎo)致手機(jī)更耗電，降低用戶體驗(yàn)等。

三. 流量

1. 定義

我們的手機(jī)通過運(yùn)營商的網(wǎng)絡(luò)訪問 Internet，運(yùn)營商替我們的手機(jī)轉(zhuǎn)發(fā)數(shù)據(jù)報(bào)文，數(shù)據(jù)報(bào)文的總大?。ㄗ止?jié)數(shù)）即流量，數(shù)據(jù)報(bào)文是包含手機(jī)上下行的報(bào)文。

2 統(tǒng)計(jì)測試法

讀取 linux 流量統(tǒng)計(jì)文件

利用 Android 自身提供的 TCP 收發(fā)長度的統(tǒng)計(jì)功能，獲取 App 的 tcp_snd 和 tcp_rcv 的值，測試一段時(shí)間后再分別統(tǒng)計(jì)一次，用 tcp_snd

兩者的差值得到發(fā)送流量，用 tcp_rcv 兩者的差值得到接受流量。

利用 Android 流量統(tǒng)計(jì) API

TrafficStats

Android 2.2 版本開始加入 android.net.TrafficStats 類來實(shí)現(xiàn)對流量統(tǒng)計(jì)的操作。

部分方法如下：

static long getMobileRxBytes() //獲取通過移動(dòng)數(shù)據(jù)網(wǎng)絡(luò)收到的字節(jié)總數(shù)

static long getMobileTxBytes() //通過移動(dòng)數(shù)據(jù)網(wǎng)發(fā)送的總字節(jié)數(shù)

static long getTotalRxBytes() //獲取設(shè)備總的接收字節(jié)數(shù)

static long getTotalTxBytes() //獲取設(shè)備總的發(fā)送字節(jié)數(shù)

static long getUidRxBytes(int uid) //獲取指定uid的接收字節(jié)數(shù)

static long getUidTxBytes(int uid) //獲取指定uid的發(fā)送字節(jié)數(shù)

NetworkStatsManager

Android 6.0 版本開始，為了打破了原本 TrafficStats 類的查詢限制，官方又提供了 NetworkStatsManager 類，可以獲取更精準(zhǔn)的網(wǎng)絡(luò)歷史數(shù)據(jù)，也不再是設(shè)備重啟以來的數(shù)據(jù)。部分方法如下：

NetworkStats.Bucket querySummaryForDevice(int networkType, String subscriberId, long startTime, long endTime) // 查詢指定網(wǎng)絡(luò)類型在某時(shí)間間隔內(nèi)的總的流量統(tǒng)計(jì)信息

NetworkStats queryDetailsForUid(int networkType, String subscriberId, long startTime, long endTime, int uid) // 查詢某uid在指定網(wǎng)絡(luò)類型和時(shí)間間隔內(nèi)的流量統(tǒng)計(jì)信息

NetworkStats queryDetails(int networkType, String subscriberId, long startTime, long endTime) // 查詢指定網(wǎng)絡(luò)類型在某時(shí)間間隔內(nèi)的詳細(xì)的流量統(tǒng)計(jì)信息（包括每個(gè)uid）

四. 電量

1.耗電場景

定位，尤其是調(diào)用 GPS 定位。

網(wǎng)絡(luò)傳輸，尤其是非 Wifi 環(huán)境。

屏幕亮度

CPU 頻率

內(nèi)存調(diào)度頻度

wake_locker 時(shí)間和次數(shù)

其他傳感器

優(yōu)化方法

CPU 時(shí)間片：當(dāng)應(yīng)用退到后臺運(yùn)行時(shí)，盡量減少應(yīng)用的主動(dòng)運(yùn)行，當(dāng)檢測到 CPU 時(shí)間片消耗異常時(shí)，深入線程進(jìn)行分析。

wake lock：前臺運(yùn)行時(shí)不要注冊 wake lock。后臺運(yùn)行時(shí)，在保證業(yè)務(wù)需要的前提下，應(yīng)盡量減少注冊 wake lock。

降低對系統(tǒng)的喚醒頻率， 使用 partial wake lock 代替 wake lock。

傳感器：合理設(shè)置 GPS 的使用時(shí)長和使用頻率。

云省電策略：考慮到用戶使用場景的多樣性，導(dǎo)致很難定位用戶異常耗電的根源，所以為了更深一層弄清楚這些問題，可以考慮定期上報(bào)灰度用戶手機(jī)電量數(shù)據(jù)的方式來分析問題。

五. 啟動(dòng)時(shí)間

可使用命令 adb shell am start -W packagename/activity 查看 App 啟動(dòng)耗時(shí)，查看了一下我們自己的 App Android 版本的啟動(dòng)耗時(shí)如下：

注釋：

WaitTime：總的耗時(shí)，包括前一個(gè)應(yīng)用 Activity pause 的時(shí)間和新應(yīng)用啟動(dòng)的時(shí)間

ThisTime：一連串啟動(dòng) Activity 的最后一個(gè) Activity 的啟動(dòng)耗時(shí)

TotalTime：新應(yīng)用啟動(dòng)的耗時(shí)，包括新進(jìn)程的啟動(dòng)和 Activity 的啟動(dòng)，但不包括前一個(gè)應(yīng)用 Activity pause 的耗時(shí)

最后，App性能問題會直接影響產(chǎn)品體驗(yàn)：耗流量、掉電快、卡頓、崩潰等現(xiàn)象會給用戶造成不良的體驗(yàn)和印象，不利于產(chǎn)品的活躍及用戶留存。許多經(jīng)驗(yàn)豐富的程序員也會經(jīng)常忽視這些不起眼的性能問題，因此作為測試人員，在版本發(fā)布前及早關(guān)注并發(fā)現(xiàn)上述性能問題就顯得尤其重要。但真正做起App性能測試才發(fā)現(xiàn)這條路并不容易走，抓取內(nèi)存、CPU 等一些項(xiàng)目的指標(biāo)容易，但對一些數(shù)據(jù)的敏感度和處理方式都是要靠經(jīng)驗(yàn)的慢慢積累。

推薦閱讀：

如何進(jìn)行H5前端頁面測試？H5前端頁面需要注意的測試點(diǎn)

APP的UI測試點(diǎn)及接口測試點(diǎn)總結(jié)

Android客戶端性能測試常見指標(biāo)及關(guān)注點(diǎn)

測試iOS APP時(shí)需要注意什么？iOS APP需要關(guān)注的測試點(diǎn)

移動(dòng)測試之H5頁面性能測試點(diǎn)總結(jié)

APP軟件常見的性能測試都包含了哪些方面？

移動(dòng)端自動(dòng)化測試工具都有哪些？