1、前言

很多時(shí)候在使用APP的時(shí)候，手機(jī)可能會(huì)發(fā)熱發(fā)燙。這是因?yàn)镃PU使用率過高，CPU過于繁忙，會(huì)使整個(gè)手機(jī)無法響應(yīng)用戶，整體性能降低，用戶體驗(yàn)就會(huì)很差，也容易引起ANR等等一系列問題。以下會(huì)根據(jù)實(shí)際app性能測試案例，展開進(jìn)行app性能評測之CPU使用率的分析和總結(jié)。

CPU使用率原理理解

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

平時(shí)所說的CPU利用率是指：CPU執(zhí)行非系統(tǒng)空閑進(jìn)程的時(shí)間 / CPU總的執(zhí)行時(shí)間。

那么我們來看看這個(gè)時(shí)間究竟是什么？

先介紹幾個(gè)和Linux時(shí)間有關(guān)的名詞：HZ、tick與jiffies。

HZ：Linux 核心每隔固定周期會(huì)發(fā)出timer interrupt (IRQ 0)，HZ是用來定義每一秒有幾次timer interrupts。例如HZ為1000，就代表每秒有1000次timer interrupts。
Tick ：Tick是HZ的倒數(shù)，Tick = 1/HZ 。即timer interrupt每發(fā)生一次中斷的時(shí)間。如HZ為250時(shí)，tick為4毫秒(millisecond)。
Jiffies ：在Linux的內(nèi)核中，有一個(gè)全局變量：Jiffies。 Jiffies代表時(shí)間。它的單位隨硬件平臺(tái)的不同而不同。jiffies的單位就是 1/HZ。Intel平臺(tái)jiffies的單位是1/100秒，這就是系統(tǒng)所能分辨的最小時(shí)間間隔了。每個(gè)CPU時(shí)間片，Jiffies都要加1。 CPU的利用率就是用執(zhí)行用戶態(tài)+系統(tǒng)態(tài)的Jiffies除以總的Jifffies來表示。

CPU利用率計(jì)算公式也就是：
CPU使用率＝（用戶態(tài)Jiffies＋系統(tǒng)態(tài)Jiffies）／總Jiffies

2、CPU測試方法

2.1 CPU占用率數(shù)據(jù)獲取--第三方測試工具

騰訊GT
平安云測試助手+評測中心(http://fit-stg1.jryzt.com/Hyperion-server/html/index.html) ---極力推薦
安測試
騰訊APT
網(wǎng)易Emagee

CPU測試大家一般都使用外部提供的第三方工具來輔助測試，類似上方列舉的這些、這些工具的原理都是基于調(diào)用 android 底層的一些 api 來獲取到測試所用到的值，當(dāng)然我們也可以采用其他方法，如使用 android 本身提供的一套 adb 即可完成上述測試。

2.2 CPU占用率數(shù)據(jù)獲取方法--adb命令

CPU是系統(tǒng)非常重要的資源，在Android中/proc/stat, 包含了所有CPU的相關(guān)詳情信息，查看CPU使用情況，CPU不是一個(gè)瞬時(shí)態(tài)，而是一個(gè)過程態(tài)的體現(xiàn)，一般可以使用top命令和dump cpuinfo命令進(jìn)行CPU占用率獲取。

一般獲取Android CPU數(shù)據(jù)的有兩個(gè)命令：top和dump cpuinfo

2.2.1 top命令獲取方法

（1）top命令方式獲取原理了解：

top是比較經(jīng)典的CPU計(jì)算方法，top的代碼在androidm/system/core/toolbox/top.c下面，輸出process的cpu使用率在print_procs里面，CPU的計(jì)算是proc->delta_time * 100 / total_delta_time

先看total_delta_time由：

    total_delta_time = (new_cpu.utime + new_cpu.ntime + new_cpu.stime + new_cpu.itime + new_cpu.iowtime + new_cpu.irqtime + new_cpu.sirqtime)
  - (old_cpu.utime + old_cpu.ntime + old_cpu.stime + old_cpu.itime
  + old_cpu.iowtime + old_cpu.irqtime + old_cpu.sirqtime);

而這些變量的值，是在read_procs通過讀取/proc/stat的jiffies得到：
所以總的cpu時(shí)間 = user + nice + system + idle + iowait + irq + softirq ，例如：User 147 + Nice 11 + Sys 79 + Idle 408 + IOW 1 + IRQ 0 + SIRQ 6 = 652
而proc->delta_time是兩次讀取/proc/pid/stat相減得到，可見，top是一段時(shí)間內(nèi)，計(jì)算process的cpu jiffies與總的cpu jiffies差值得到。

附注釋：

（2）top命令獲取CPU占用率實(shí)例：

adb shell top -m 100 -n 1 -s cpu | grep 包名

adb shell top -m 100 -n 1 -s cpu | grep com.pafinancialtech.fuzhoubank

zhangmeiyuan-5:~ zhangmeiyuan$ adb shell top -m 100 -n 1 -s cpu | grep com.pafinancialtech.fuzhoubank
18540  0  42% S   108 2102520K 317264K  fg u0_a858  com.pafinancialtech.fuzhoubank

CPU占用率_實(shí)時(shí)打印.png

CPU占用率_每隔5s打印一次.png

2.2.2 dump cpuinfo命令獲取方法

（1）dump命令方式獲取原理了解：

dump cpuinfo是Android特有的命令，dump cpuinfo命令的實(shí)現(xiàn)在androidm/frameworks/base/core/java/com/android/internal/os/ProcessCpuTracker.java類里面，方法是printCurrentState:
而printProcessCPU輸出process CPU的使用情況：

private void printProcessCPU(PrintWriter pw, String prefix, int pid, String label,
            int totalTime, int user, int system, int iowait, int irq, int softIrq,
            int minFaults, int majFaults) {
        pw.print(prefix);
        if (totalTime == 0) totalTime = 1;
        printRatio(pw, user+system+iowait+irq+softIrq, totalTime);
...
}

user+system+iowait+irq+softIrq就是totalTime。 st變量的賦值，在collectStats里面，st.rel_utime 和 st.rel_stime還是通過讀/proc/pid/stat相減得到，而st.rel_uptime卻是通過 SystemClock.uptimeMillis()差值，并不是跟top一樣，通過proc/stat得到總CPU jiffies,

所以，進(jìn)程的總Cpu時(shí)間processCpuTime = utime + stime + cutime + cstime，該值包括其所有線程的cpu時(shí)間。（例外，一般cpu按100%計(jì)算，如果是多核情況下還需乘以cpu的個(gè)數(shù))

附注釋：
/proc/pid/stat文件:
該文件包含了某一進(jìn)程所有的活動(dòng)的信息，該文件中的所有值都是從系統(tǒng)啟動(dòng)開始累計(jì) 到當(dāng)前時(shí)刻。
Utime(39) 該任務(wù)在用戶態(tài)運(yùn)行的時(shí)間，單位為jiffies
Stime(25) 該任務(wù)在核心態(tài)運(yùn)行的時(shí)間，單位為jiffies
Cutime(0) 所有已死線程在用戶態(tài)運(yùn)行的時(shí)間，單位為jiffies
Cstime(0) 所有已死在核心態(tài)運(yùn)行的時(shí)間，單位為jiffies

（2）dump命令獲取CPU占用率實(shí)例

adb shell dumpsys cpuinfo |grep 包名

zhangmeiyuan-5:~ zhangmeiyuan$ adb shell dumpsys cpuinfo |grep com.pafinancialtech.fuzhoubank
  117% 16322/com.pafinancialtech.fuzhoubank: 106% user + 11% kernel / faults: 45403 minor 99 major
  0.5% 14032/com.pafinancialtech.fuzhoubank:pushservice: 0.5% user + 0% kernel / faults: 1610 minor
 +0% 16547/com.pafinancialtech.fuzhoubank:remote: 0% user + 0% kernel

CPU_dump方式獲取的占用率.png

從上圖我們可以看出：80%是針對這個(gè)CPU的占用率是80%，其中72%占用率是用戶使用的，8.4%是內(nèi)核的占用率，這個(gè)數(shù)只是針對1核來說，現(xiàn)在手機(jī)都是多核的了，那這樣的值也不會(huì)太準(zhǔn)確，如果是多核情況下還需除以cpu的個(gè)數(shù)。

綜上：top跟dump cpuinfo的區(qū)別在于：top分母是總測CPU jiffies，而dump cpuinfo是是時(shí)間，而并非jiffies，也能解釋為什么top出來的cpu，大部分時(shí)間會(huì)比dump cpuinfo小的原因。

2.3 CPU問題分析思路及工具

如果APP某場景進(jìn)行操作時(shí)出現(xiàn)發(fā)燙、卡頓、ANR現(xiàn)象時(shí)，可以懷疑出現(xiàn)CPU問題，一般解決思路如下：

a. 如果已經(jīng)導(dǎo)致ANR, 則去log里面搜索"ANR in"
b. 沒有導(dǎo)致ANR則基于以上方法獲取到的CPU占用率，如果某場景的CPU占用率走勢異常、峰值存在異常、均值大于基線，則可以利用DDMS查看分析Trace文件，或者使用Android studio里面的Android Monitor根據(jù)Monitor中的CPU可以看出目前CPU明細(xì)使用。
c.查找程序中有沒有特殊布局或者特殊操作（GPS定位，一直刷新類的服務(wù)等），特殊加載（Gif圖片加載，視頻，音頻加載等）

2.3.1 Android Monitor監(jiān)控分析

拿到APP源碼，在Android studio中構(gòu)建測試DEBUG包進(jìn)行調(diào)試如下截圖：

cpu_monitor.png

image.png

雙擊我綠色框標(biāo)記的這個(gè)按鈕，就會(huì)生成這么一個(gè)文件，如圖：

image.png

上圖就一目了然的看到了耗費(fèi)CPU 都有哪些方法。此時(shí)點(diǎn)擊黑色的文本，幾秒鐘后studio會(huì)生成.trace文件，我們就可以分析各方法使用cpu的情況了。

2.3.2 分析TraceView文件查找CPU問題

TraceView 是 Android SDK 中內(nèi)置的1個(gè)工具，它可以加載 trace 文件，用圖形的情勢展現(xiàn)代碼的履行時(shí)間、次數(shù)及調(diào)用棧，便于我們分析。

（1）使用Android Studio工具DDMS

生成Traceview 進(jìn)行分析查看具體Trace期間各方法調(diào)用關(guān)系，調(diào)用次數(shù)以及耗時(shí)比例

DDMS_查看各方法調(diào)用及CPU信息.png

附注釋：
Traceview 面板分上下兩部分
上面是時(shí)間軸面板 (Timeline Panel)
左側(cè)顯示的是線程信息
右側(cè)黑色部分是顯示執(zhí)行時(shí)間段、白色是線程暫停時(shí)間段，
右側(cè)鼠標(biāo)放在上面會(huì)出現(xiàn)時(shí)間線縱軸，在頂部會(huì)顯示當(dāng)前時(shí)間線所執(zhí)行的具體函數(shù)信息
下面是分析面板(Profile Panel) - 每一列內(nèi)容
Inclusive time - 函數(shù)本身運(yùn)行花費(fèi)時(shí)間 + 函數(shù)調(diào)用其他函數(shù)時(shí)間
Exclusive time - 函數(shù)本身運(yùn)行花費(fèi)時(shí)間。
Calls + RecurCall/Total 調(diào)用 + 重復(fù)調(diào)用次數(shù) / 函數(shù)總調(diào)用次數(shù)
Cpu Time/Call 總的Cpu時(shí)間與總的調(diào)用次數(shù)之比

附： Profile Panel各列作用說明

（2）使用代碼生成 trace 文件

  Debug.startMethodTracing("shixintrace");   
 //開始 trace，保存文件到 "/sdcard/shixintrace.trace"
    // ...
    Debug.stopMethodTracing();    //結(jié)束

代碼很簡單，當(dāng)你調(diào)用開始代碼的時(shí)候，系統(tǒng)會(huì)生產(chǎn) trace 文件，并且產(chǎn)生追蹤數(shù)據(jù)，當(dāng)你調(diào)用結(jié)束代碼時(shí)，會(huì)將追蹤數(shù)據(jù)寫入到 trace 文件中。
下1步使用 adb 命令將 trace 文件導(dǎo)出到電腦：

adb pull /sdcard/shixintrace.trace /tmp

使用代碼生成 trace 方式的好處是容易控制追蹤的開始和結(jié)束，缺點(diǎn)就是步驟略微多了一點(diǎn)。

2.3 CPU測試場景

一般cpu檢測我們要分4種情況：
1.在空閑時(shí)間的消耗，基本沒大應(yīng)用使用cpu

如果APP在退出界面后還有進(jìn)程長期運(yùn)行，那需要關(guān)注下待機(jī)場景的CPU。待機(jī)場景下CPU的消耗一般不會(huì)很大，例如福州直銷銀行APP在后臺(tái)運(yùn)行時(shí)，可能消耗經(jīng)常是0%，長時(shí)間平均下，可能只有0.1%、0.2%，看看競品，也是差不多，好像沒有太大區(qū)別。那么CPU消耗這么少是不是就不用管CPU了呢，然而即使是平均值很小，但是長時(shí)間待機(jī)，例如安全類工具，CPU的消耗還是不容忽視。
這種場景下我們測試時(shí)常用的單位有：消耗XX jiffies/分鐘；半/1小時(shí)共增加XX jiffies。

2.在運(yùn)行一些應(yīng)用的情況下，cpu已占50%的情況下，觀察應(yīng)用程序占用cpu的情況

簡單說這種情況就是后臺(tái)已經(jīng)有幾個(gè)應(yīng)用在運(yùn)行已經(jīng)并且消耗了系統(tǒng)的一些資源的情況下進(jìn)行測試。

3.在高負(fù)荷的情況下看CPU的表現(xiàn)，我定義這個(gè)高負(fù)荷，cpu占用應(yīng)是在80%以上

滿規(guī)格狀態(tài)下的應(yīng)用CPU消耗情況

4.觀察App 相同/不同場景下CPU走勢、峰值情況

對比不同場景頁面CPU占用大小
對比不同時(shí)間段同一場景頁面CPU占用走勢情況

3、XX銀行性能評測-CPU測試結(jié)果分析

3.1 總覽

此次質(zhì)量開放平臺(tái)-評測中心（http://fit-stg1.jryzt.com/Hyperion-server/html/index.html）的性能測試的采集的CPU占用數(shù)據(jù)主要是針對場景頁面的CPU占用測試，CPU占用數(shù)據(jù)獲取原理是CPU執(zhí)行非系統(tǒng)空閑進(jìn)程的時(shí)間 / CPU總的執(zhí)行時(shí)間。

從CPU消耗對比來看，行業(yè)競品均值為8.4%，90分位約4.9%，75分位約7.8%，中位數(shù)約9.3%，25分位約16.2%。

CPU占用對比.png

【榕商Bank】和10家競品分析對比，CPU占用12.0%，表現(xiàn)較差，不及行業(yè)平均水準(zhǔn)。但是從APP本品各場景CPU占用率來看，占用率最大的為理財(cái)產(chǎn)品詳情頁22.7%，主要原因是該頁面存在6個(gè)不同時(shí)段近七日和萬份收益率曲線走勢圖繪制，但是仍然未超過CPU占用率基線30%，且目前大部分手機(jī)是四核、八核系統(tǒng)，所以目前測試數(shù)據(jù)表明整體表現(xiàn)良好不存在瓶頸，但是從行業(yè)標(biāo)準(zhǔn)來看，理財(cái)產(chǎn)品詳情頁仍然有優(yōu)化空間，建議優(yōu)化。

理財(cái)產(chǎn)品詳情頁性能曲線.png

4、App端CPU問題排查思路：

（1）是否有非常多的網(wǎng)絡(luò)請求
（2）是否開了很多進(jìn)程OR 應(yīng)用，嘗試關(guān)閉其他應(yīng)用再查看CPU是否降下來
（3）是否有大量大圖片、視頻處理跟加載或布局
（4）查找程序中有沒有特殊布局或者特殊操作（GPS定位，一直刷新類的服務(wù)等），特殊加載（Gif圖片加載，視頻，音頻加載等）
（5）當(dāng)前頁面是否有過多的圖表、曲線圖等繪制操作
（6）通過Android Studio 自帶的monitor查找是哪個(gè)Activity或者哪個(gè)方法有一直不停止的運(yùn)算消耗CPU（比如：不停止的while 或者for 循環(huán)）