APP性能測試中的幾個重要概念

轉載一篇文章，關於app性能測試的幾個概念，對於想要接觸app測試的朋友或許有些幫助。

咱們在使用各類 App 的時候基本會關注到：這款軟件挺耗流量的？運行起來設備掉電有點快嘛？切換頁面的時候還會有卡頓等現象？若是遇到有這些問題的 App 咱們基本會將它請出咱們的愛機。因而可知軟件是否受歡迎除了提供必要的功能外，流暢性、流量/電池消耗也是很重要的指標。

　　今天就來從咱們 測試人員的角度，談一談 App 驗收測試過程當中須要關注到一些指標項目：

　　●內存佔用

　　●CPU 佔用

　　●流量耗用

　　●電量耗用

　　●啓動時間

　　由於最近就着 騰訊 TMQ 團隊出版的《移動 App 性能評測與優化》這本書在看 App  性能測試這一塊的東西，看着看着發現有些名詞或者概念不是很明白，因此在看這塊東西的時候，還要一邊去查詢一些其餘的點，如今將這些點 記錄下來，也算是一篇讀書筆記了吧，下面針對每個方面的一些重要知識點進行了整理。

　　一. 內存

　　1. 內存泄漏

　　說到內存方面，最經典的內存問題當數內存泄漏。 百度上對內存泄漏的定義是這樣的：內存泄漏（Memory Leak）是指程序中己動態分配的堆內存因爲某種緣由程序未釋放或沒法釋放，形成系統內存的浪費，致使程序運行速度減慢甚至系統崩潰等嚴重後果。通俗點講，在大部分應用中，會有一類功能是須要加載附加資源的，好比顯示從網絡下載的文本或圖片。這類功能每每須要在內存中存放要使用的資源對象，退出該功能後，就須要將這些資源對象清空。若是忘了清理，或者是代碼緣由形成的清理無效，就會造成內存泄漏。

　　 2. 垃圾回收

　　說到了內存泄漏，又不得不提到垃圾回收（Garbage Collector，簡稱 GC），內存中的垃圾，主要指的是內存中已無效但又沒法自動釋放的空間，除非是重啓系統否則永遠也不會還給 操做系統。這樣以來，時間久了當程序運行的時候就會產生不少垃圾，一方面浪費了很多內存空間，另外一方面若是同一個內存地址被刪除兩次的話，程序就會不穩定，甚至奔潰。

　　在 Java 程序運行過程當中，一個垃圾回收器會不定時地被喚起檢查是否有再也不被使用的對象，並釋放它們佔用的內存空間。但垃圾回收器的回收是隨機的，可能在程序的運行的過程當中，一次也沒有啓動，也可能啓動不少次，它並不會由於程序一產生垃圾，就立刻被喚起而自動回收垃圾。因此垃圾回收也並不能徹底避免內存泄漏的問題。

　　另外一方面，垃圾回收也會給系統資源帶來額外的負擔和時空開銷。它被啓動的概率越小，帶來的負擔的概率就越小。

　　 3. 內存指標

　　內存指標有 VSS、RSS、PSS、USS，他們的含義分別是：

　　VSS：Virtual Set Size 虛擬耗用內存（包含共享庫佔用的內存）

　　RSS：Resident Set Size 實際使用物理內存（包含共享庫佔用的內存）

　　PSS：Proportional Set Size 實際使用的物理內存（按比例分配共享庫佔用的內存）

　　USS：Unique Set Size 進程獨自佔用的物理內存（不包含共享庫佔用的內存）

　　通常來講內存佔用大小有以下規律：VSS >= RSS >= PSS >= USS，通常測試中關注的比較多的是 PSS 這個指標。

　　 4. 監控與分析工具

　　如下是幾種常見的內存分析工具，具體使用方法這裏就不詳述了。

　 　4.1 Memory Monitor

　　該工具位於  Android Monitor 下面，Android Monitor 是 Android Studio 自帶的一個強大的性能分析工具，裏面一共包含 5 個模塊：Logcat、Memory、CPU、Network 及 GPU。

　　Memory Monitor 能夠實時查看 App 的內存分配狀況，判斷 App 是否因爲 GC 操做形成卡頓以及判斷 App 的 Crash 是不是由於超出了內存。

　 　4.2 Heap Viewer

　　該內存檢測工具位於 DDMS 下面，在 Android Studio 裏面能夠經過 Tools-Android-Android Device Monitor 打開，Heap Viewer 能夠實時查看 App 分配的內存大小和空閒內存大小，而且發現 Memory Leaks。

　 　4.3 MAT

　　MAT（Memory Analyzer Tool），是一個被老生常談的 Android 內存分析工具，它能夠清楚的獲知總體內存使用狀況。雖然是 Eclipse 的工具，但也能夠單獨運行，不須要安裝 Eclipse。

　 　二. CPU

　　1. 時間片

　　時間片即 CPU 分配給各個程序的時間，每一個線程被分配一個時間段，稱做它的時間片，即該進程容許運行的時間，使各個程序從表面上看是同時進行的。

　　 2. Jiffies

　　2.1 Jiffies的概念

　　要講 Jiffies 須要先提到這兩個概念：HZ 和 Tick

HZ： Linux 核心每隔固定週期會發出 timer interrupt (IRQ 0)，HZ 是用來定義每一秒有幾回 timer interrupts。例如 HZ 爲 1000，就表明每秒有 1000 次 timer interrupts。 　　Tick：HZ 的倒數，Tick = 1/HZ，即 timer interrupt 每發生一次中斷的時間。如 HZ 爲 250 時，tick 爲 4 毫秒（millisecond）。

　　而 Jiffies 爲 Linux 核心變量，是一個 unsigned long 類型的變量，被用來記錄系統自開機以來，已通過了多少 tick。每發生一次 timer interrupt，Jiffies 變數會被加 1。

　　 2.2 查看 Jiffies 的方法

　　Linux 下使用命令cat /proc/stat，查看具體整機的 Jiffies，如圖：

　　Linux 下使用命令cat /proc/<進程id>/stat，查看具體某個進程的 Jiffies：

　　 3. CPU 使用率

　　在 Linux 系統下，CPU 利用率分爲用戶態、系統態和空閒態，他們分別表明的含義爲：用戶態表示 CPU 處於用戶態執行的時間，系統態表示系統內核執行的時間，空閒態表示空閒系統進程執行的時間。

　　而一個 App 的 CPU 使用率 = CPU 執行非系統空閒進程時間 / CPU 總的執行時間，也能夠表示爲 App 用戶態 Jiffies + App 系統態 Jiffies /  手機總 Jiffies。

　 　4. CPU 太高會帶來的影響

　　可能會使整個手機沒法響應，總體性能下降，引發 ANR，致使手機更耗電，下降用戶體驗等。

 

三. 流量

　　1. 定義

　　咱們的手機經過運營商的網絡訪問 Internet，運營商替咱們的手機轉發數據報文，數據報文的總大小（字節數）即流量，數據報文是包含手機上下行的報文。

　 　2. 經常使用流量測試方法

　　2.1 抓包測試法

　　主要是利用工具 Tcpdump 抓包，導出 pcap 文件，再在 wireshark 中打開進行分析。

　 　2.2 統計測試法

　　2.2.1 讀取 linux 流量統計文件

　　利用 Android 自身提供的 TCP 收發長度的統計功能，獲取 App 的 tcp_snd 和 tcp_rcv 的值，測試一段時間後再分別統計一次，用 tcp_snd

　　二者的差值獲得發送流量，用 tcp_rcv 二者的差值獲得接受流量。

　　2.2.2 利用 Android 流量統計 API

　　TrafficStats

　　Android 2.2 版本開始加入 android.net.TrafficStats 類來實現對流量統計的操做。

　　部分方法以下：

static long getMobileRxBytes() //獲取經過移動數據網絡收到的字節總數  　　static long getMobileTxBytes() //經過移動數據網發送的總字節數  　　static long getTotalRxBytes() //獲取設備總的接收字節數  　　static long getTotalTxBytes() //獲取設備總的發送字節數  　　static long getUidRxBytes(int uid) //獲取指定uid的接收字節數  　　static long getUidTxBytes(int uid) //獲取指定uid的發送字節數

　　●NetworkStatsManager

　　Android 6.0 版本開始，爲了打破了本來 TrafficStats 類的查詢限制，官方又提供了 NetworkStatsManager 類，能夠獲取更精準的網絡歷史數據，也再也不是設備重啓以來的數據。部分方法以下：

NetworkStats.Bucket querySummaryForDevice(int networkType, String subscriberId, long startTime, long endTime) // 查詢指定網絡類型在某時間間隔內的總的流量統計信息 　　 NetworkStats queryDetailsForUid(int networkType, String subscriberId, long startTime, long endTime, int uid) // 查詢某uid在指定網絡類型和時間間隔內的流量統計信息 　　 NetworkStats queryDetails(int networkType, String subscriberId, long startTime, long endTime) // 查詢指定網絡類型在某時間間隔內的詳細的流量統計信息（包括每一個uid）

　　四. 電量

　　1.耗電場景

　　定位，尤爲是調用 GPS 定位。

　　網絡傳輸，尤爲是非 Wifi 環境。

　　屏幕亮度

　　CPU 頻率

　　內存調度頻度

　　wake_locker 時間和次數

　　其餘傳感器

　 　2.測試方法

　　2.1 經過系統文件獲取電量記錄

　　使用命令 adb shell dumpsys batterystats> batterystats.txt 能夠打印出詳細的耗電相關信息並保存統計的電量信息到 batterystats.txt 這個文件裏。

　　 2.2 經過導入 batterystats.txt 到 Google 開源工具 battery historian 進行分析

　　由於這個工具是 Go 語言開發，因此須要預裝Go語言開發環境，固然若是你不想配置Go語言環境，官方還提供了一種更方便的方案，經過安裝 docker 環境來使用這個工具。具體這個工具的配置安裝和具體使用方法以及參數的表明含義，我會單獨再寫一篇文章記錄，先拋磚引玉放一張這個工具的運行截圖。

　 　3.優化方法

　　3.1 CPU 時間片

　　當應用退到後臺運行時，儘可能減小應用的主動運行，當檢測到 CPU 時間片消耗異常時，深刻線程進行分析。

　　 3.2 wake lock

　　前臺運行時不要註冊 wake lock。

　　後臺運行時，在保證業務須要的前提下，應儘可能減小注冊 wake lock。

　　下降對系統的喚醒頻率， 使用 partial wake lock 代替 wake lock。

　 　3.3 傳感器

　　合理設置 GPS 的使用時長和使用頻率。

　　 3.4 雲省電策略

　　考慮到用戶使用場景的多樣性，致使很難定位用戶異常耗電的根源，因此爲了更深一層弄清楚這些問題，能夠考慮按期上報灰度用戶手機電量數據的方式來分析問題。

　 　五. 啓動時間

　　可以使用命令 adb shell am start -W packagename/activity 查看 App 啓動耗時，查看了一下咱們本身的 App Android 版本的啓動耗時以下：

　　註釋：

　　WaitTime：總的耗時，包括前一個應用 Activity pause 的時間和新應用啓動的時間

　　ThisTime：一連串啓動 Activity 的最後一個 Activity 的啓動耗時

　　TotalTime：新應用啓動的耗時，包括新進程的啓動和 Activity 的啓動，但不包括前一個應用 Activity pause 的耗時

　 　六. 總結

　　App性能問題會直接影響產品體驗：耗流量、掉電快、卡頓、崩潰等現象會給用戶形成不良的體驗和印象，不利於產品的活躍及用戶留存。許多經驗豐富的程序員也會常常忽視這些不起眼的性能問題，所以做爲測試人員，在版本發佈前及早關注並發現上述性能問題就顯得尤爲重要。但真正作起App性能測試才發現這條路並不容易走，抓取內存、CPU 等一些項目的指標容易，但對一些數據的敏感度和處理方式都是要靠經驗的慢慢積累。總之，性能測試算是一項比較繁瑣的工做，但難者不易，易者不難，但願已經行走在這條路上的或者準備踏上這條路的同行都能不斷提升自身素養，堅持到底。

 

原文地址：http://www.51testing.com/html/64/n-3724964.html