移動端效能測試--CPU資源
一、背景
在很多場景下我們去使用 App,可能會碰到手機會出現發熱發燙的現象。這是因為 CPU 使用率過高、CPU 過於繁忙,會使得整個系統無法響應使用者,整體效能降低,使用者體驗變得相當差,也容易引起 ANR 等等一系列問題
二、效能指標獲取的方法
1、Android 效能指標 CPU 主要關注兩點:
(1)CPU 總體使用率
(2)應用程式 CPU 佔用率
2、獲取App CPU 指標值的幾種不同方式:
(1)讀取 Linux proc 檔案系統(精確、方便自動化整合)
(2)使用外部第三方工具來輔助測試,比如:
# 騰訊 GT,網易 Emagee 等(其實這些工具的原理就是基於呼叫 Android 系統底層的 API 完成)
# 掌握 adb 或者第三方工具獲取方法都可以。(精確,易獲取,推薦)
(3)Linux top 命令(有誤差,易獲取)
三、proc 檔案獲取
/proc 檔案系統是一個偽檔案系統,它只存在記憶體當中,而不佔用外存空間。它以檔案系統的方式為核心與程序提供通訊的介面。
使用者和應用程式可以通過 /proc 得到系統的資訊,並可以改變核心的某些引數。
由於系統的資訊,如程序,是動態改變的,所以使用者或應用程式讀取 /proc 目錄中的檔案時,/proc 檔案系統是動態從系統核心讀出所需資訊並提交的。
我們關注的安卓效能指標 CPU 總體使用率和應用程式 CPU 佔用率主要與兩個 proc 檔案相關,分別是 /proc/stat
通過 adb shell 進入到手機內部 shell 模式,再通過 cat /proc/stat 檢視結果如下:
/proc/stat 命令下資料解析:
前面三行 CPU cpu0 cpu1 是我們需要關注的重點,cpu0、cpu1 表示當前 CPU 的核心(雙核),CPU 為總的 Jiffies,這裡引入了 Jiffies(時間片)的概念
Jiffies 的介紹如下:
(1)Jiffies 為 Linux 核心變數,
(2)是一個 unsigned long 型別的變數,
(3)它被用來記錄系統自開機以來,已經過了多少 tick。每發生一次 timer interrupt,Jiffies 變數會被加 1
從上面每一列的數值含義如下:
user :從系統啟動開始累計到當前時刻,使用者態的 jiffies ,不包含 nice 值為負程序;
nice :從系統啟動開始累計到當前時刻,nice 值為負的程序所佔用的 jiffies;
system :從系統啟動開始累計到當前時刻,系統態的 jiffies;
idle :從系統啟動開始累計到當前時刻,除硬碟 IO 等待時間以外其它等待的 jiffies;
iowait : 從系統啟動開始累計到當前時刻,硬碟 IO 等待的 jiffies;
irq : 從系統啟動開始累計到當前時刻,硬中斷的 jiffies;
softirq :從系統啟動開始累計到當前時刻,軟中斷的 jiffies。
總的 Jiffies 就是上面所有項加起來的總和。因此我們計算一段時間的 CPU 佔用率的時候就可以使用:
total = user+system+nice+idle+iowait+irq+softirq
*CPU usage=[(user_end +sys_end+nice_end) - (user_begin + sys_begin+nice_begin)]/(total_end - total_begin)100
上述方法統計的是當前系統所有程序的 CPU 總和使用率
如果我們要統計某個 App 的使用率可以進入到/proc/程序 id/stat 目錄,其中就有包含某程序的 CPU 資訊
> 首先,我們需要查詢到 App 的程序 ID,以 App 舉例
> 其中的程序 ID 為 1228,再查詢 stat 檔案資訊
在第 14 行、15 行有記錄當前程序的 Jiffies 資訊
utime=448 該任務在使用者態執行的時間,單位為 jiffies
stime=2380 該任務在核心態執行的時間,單位為 jiffies
所以當前程序的 Jiffies 計算方式為 utime+stime
> 通過 shell 指令碼獲取的方式:
cat /proc/程序 id/stat | awk -F " " '{print $14,$15}'
要計算出一段時間內該程序的 CPU 使用率資訊即可通過:
utime+stime(當前時間點)-utime+stime(舊時間點)/ total CPU Jiffies
四、top 命令獲取 CPU 使用率
解釋:
(1)top 命令是 Linux 下常用的效能分析工具,能夠實時顯示系統中各個程序的資源佔用狀況,類似於 Windows 的工作管理員。
(2)top 是一個動態顯示過程,即可以通過使用者按鍵來不斷重新整理當前狀態。如果在前臺執行該命令,它將獨佔前臺,直到使用者終止該程式為止。
(3)top 命令提供了實時的對系統處理器的狀態監視
使用方式:
# 可檢視佔用 CPU 最高的前 10 個程式(-t 顯示程序名稱,-s 按指定行排序,-n 在退出前重新整理幾次,-d 重新整理間隔,-m 顯示最大數量):
top -m 10 -s CPU
# 如果你想篩選出你自己的應用的話可以用下面這一命令:
adb shell top -n 1| grep PackageName
五、問題分析
如果 APP 某場景進行操作時出現發燙、卡頓、ANR 現象時,可以懷疑出現 CPU 問題,一般解決思路如下:
(1)如果已經導致 ANR, 則去 logcat 檔案裡面搜尋 "ANR in" ,以及 adb pull 拉取 trace 檔案。
(2)沒有導致 ANR 則基於以上方法獲取到的 CPU 佔用率,
(3)如果某場景的 CPU 佔用率走勢異常、峰值存在異常、均值大於基線,則可以利用 traceview 檢視分析 Trace 檔案,
(4)或者使用 Android studio 裡面的 Android Monitor 根據 Monitor 中的 CPU 可以看出目前 CPU 明細使用,由開發負責定位解決