[[415733]]

Android應用測試點

Android前端APP的性能測試一般針對以下幾個方面：應用啟動時間;CPU的占用;內存的占用;流量的耗用;電量的耗用;流暢度等。一般對App進行性能測試都需要借助不同的工具完成，本章節會向讀者重點介紹針對不同的性能測試指標該選用哪種工具以及工具的具體使用方法。

因為Android 手機是Linux內核，最簡單的命令就是使用top命令查看手機的 cpu、內存的占用情況。

具體操作：

PC中成功安裝Android SDK

手機成功連接PC

Android手機 ->設置 ->開發者選項->USB調試(打上勾)

在cmd窗口中輸入 adb shell ，進入adb shell命令模式

方法1：輸入top 顯示如下：

具體參數含義如下:

CPU占用率：

• User 用戶進程
• System 系統進程
• IOW
• IO等待時間
• IRQ 硬中斷時間
• CPU使用情況(指一個最小時間片內所占時間，單位jiffies。或者指所占進程數)：
• User 處于用戶態的運行時間，不包含優先值為負進程
• Nice 優先值為負的進程所占用的CPU時間
• Sys 處于核心態的運行時間
• Idle 除IO等待時間以外的其它等待時間
• IOW
• IO等待時間
• IRQ 硬中斷時間
• SIRQ 軟中斷時間

進程屬性：

• PID 進程在系統中的ID
• CPU% 當前瞬時所以使用CPU占用率
• S 進程的狀態，其中S表示休眠，R表示正在運行，Z表示僵死狀態，N表示該進程優先值是負數。
• #THR 程序當前所用的線程數

內存：

• VSS
• Virtual Set Size 虛擬耗用內存(包含共享庫占用的內存)
• RSS
• Resident Set Size 實際使用物理內存(包含共享庫占用的內存)
• UID 運行當前進程的用戶id
• Name 程序名稱system_server
• 備注：內存占用大小有如下規律：VSS >= RSS >= PSS >= USS
• PSS Proportional Set Size實際使用的物理內存(比例分配共享庫占用的內存)
• USS Unique Set Size進程獨自占用的物理內存(不包含共享庫占用的內存)

應用啟動時間測試

adb shell am start -W –n /

am命令的詳細使用方法請參考章節am與pm命令

注意：啟動時間需要區分首次啟動和非首次啟動

耗電測試

請參考文章Android App 耗電的測試方法

流暢度和網絡消耗測試

請參考文章詳解移動應用測試神器PerfDog

接下來我來介紹幾款Android sdk中自帶的，可以幫助我們搞定性能問題的工具!

Dumps命令

Dumpsys命令默認打印出當前系統所有服務信息

使用命令dumpsys | grep "DUMP OF SERVICE" 可以查看的內容包括：

• DUMP OF SERVICE DockObserver:
• DUMP OF SERVICE SurfaceFlinger:
• DUMP OF SERVICE accessibility:
• DUMP OF SERVICE account:
• DUMP OF SERVICE activity:
• DUMP OF SERVICE alarm:
• DUMP OF SERVICE android.security.keystore:
• DUMP OF SERVICEandroid.service.gatekeeper.IGateKeeperService:
• DUMP OF SERVICE appops:
• DUMP OF SERVICE appwidget:
• DUMP OF SERVICE assetatlas:
• DUMP OF SERVICE audio:
• DUMP OF SERVICE backup:
• DUMP OF SERVICE battery:
• DUMP OF SERVICE batteryproperties:
• DUMP OF SERVICE batterystats:
• DUMP OF SERVICE bluetooth_manager:
• DUMP OF SERVICE carrier_config:
• DUMP OF SERVICE clipboard:
• DUMP OF SERVICE commontime_management:
• DUMP OF SERVICE connectivity:
• DUMP OF SERVICE consumer_ir:
• DUMP OF SERVICE content:
• DUMP OF SERVICE country_detector:
• DUMP OF SERVICE cpuinfo:
• DUMP OF SERVICE dbinfo:
• DUMP OF SERVICE device_policy:
• DUMP OF SERVICE deviceidle:
• DUMP OF SERVICE devicestoragemonitor:
• DUMP OF SERVICE diskstats:
• DUMP OF SERVICE display:
• DUMP OF SERVICE display.qservice:
• DUMP OF SERVICE dreams:
• DUMP OF SERVICE drm.drmManager:
• DUMP OF SERVICE dropbox:
• DUMP OF SERVICE ethernet:
• DUMP OF SERVICE fingerprint:
• DUMP OF SERVICE gfxinfo:
• DUMP OF SERVICE graphicsstats:
• DUMP OF SERVICE imms:
• DUMP OF SERVICE input:
• DUMP OF SERVICE input_method:
• DUMP OF SERVICE iphonesubinfo:
• DUMP OF SERVICE isms:
• DUMP OF SERVICE isub:
• DUMP OF SERVICE jobscheduler:
• DUMP OF SERVICE launcherapps:
• DUMP OF SERVICE location:
• DUMP OF SERVICE lock_settings:
• DUMP OF SERVICE media.audio_flinger:
• DUMP OF SERVICE media.audio_policy:
• DUMP OF SERVICE media.camera:
• DUMP OF SERVICE media.camera.proxy:
• DUMP OF SERVICE media.player:
• DUMP OF SERVICE media.radio:
• DUMP OF SERVICE media.resource_manager:
• DUMP OF SERVICE media.sound_trigger_hw:
• DUMP OF SERVICE media_projection:
• DUMP OF SERVICE media_router:
• DUMP OF SERVICE media_session:
• DUMP OF SERVICE meminfo:
• DUMP OF SERVICE midi:
• DUMP OF SERVICE mount:
• DUMP OF SERVICE netpolicy:
• DUMP OF SERVICE netstats:
• DUMP OF SERVICE network_management:
• DUMP OF SERVICE network_score:
• DUMP OF SERVICE nfc:
• DUMP OF SERVICE notification:
• DUMP OF SERVICE package:
• DUMP OF SERVICE permission:
• DUMP OF SERVICE persistent_data_block:
• DUMP OF SERVICE phone:
• DUMP OF SERVICE power:
• DUMP OF SERVICE print:
• DUMP OF SERVICE processinfo:
• DUMP OF SERVICE procstats:
• DUMP OF SERVICE restrictions:
• DUMP OF SERVICE rttmanager:
• DUMP OF SERVICE samplingprofiler:
• DUMP OF SERVICE scheduling_policy:
• DUMP OF SERVICE search:
• DUMP OF SERVICE sensorservice:
• DUMP OF SERVICE serial:
• DUMP OF SERVICE servicediscovery:
• DUMP OF SERVICE simphonebook:
• DUMP OF SERVICE sip:
• DUMP OF SERVICE statusbar:
• DUMP OF SERVICE telecom:
• DUMP OF SERVICE telephony.registry:
• DUMP OF SERVICE textservices:
• DUMP OF SERVICE trust:
• DUMP OF SERVICE uimode:
• DUMP OF SERVICE updatelock:
• DUMP OF SERVICE usagestats:
• DUMP OF SERVICE usb:
• DUMP OF SERVICE user:
• DUMP OF SERVICE vibrator:
• DUMP OF SERVICE voiceinteraction:
• DUMP OF SERVICE wallpaper:
• DUMP OF SERVICE webviewupdate:
• DUMP OF SERVICE wifi:
• DUMP OF SERVICE wifip2p:
• DUMP OF SERVICE wifiscanner:
• DUMP OF SERVICE window:

關鍵信息顯示：

activity:顯示所有的activities的信息

cpuinfo:顯示CPU信息

window:顯示鍵盤，窗口和它們的關系

wifi:顯示wifi信息

batteryinfo $package_name:電量信息及CPU 使用時長

package packagename:獲取安裝包信息

usagestats:每個界面啟動的時間

statusbar:顯示狀態欄相關的信息

meminfo:內存信息(meminfo $package_name or $pid使用程序的包名或者進程id顯示內存信息)

diskstats:磁盤相關信息

battery:電池信息

alarm:顯示Alarm信息

例如，輸出某個應用的cpu信息，可以使用命令

dumpsys cpuinfo |your app package

am命令

am全稱activity manager，使用am可以模擬各種系統的行為，例如去啟動一個activity，強制停止進程，發送廣播進程，修改設備屏幕屬性等等。

pm命令

pm全稱package manager，你能使用pm命令去模擬android行為或者查詢設備上的應用等等。

GPU呈現模式分析

GPU：Graphic Processing Unit (圖形處理器)，主要反映應用的卡頓現象。

IOS與Android流暢與否的比較，主要是以下三個原因：

速度曲線

當滑動界面然后松手，這時界面會繼續滑動，然后速度減小，直到速度為0時停止。iOS下速度減小的這個過程比較慢，尤其是快要停的時候是慢慢停的，視覺上有種很順滑的感覺;Android下則從松手到停要快很多，相比之下有種戛然而止的感覺。

從數據/技術角度來看這個事情，我們滑動界面的最終目的不是為了“動”，而是為了“停”，因此只要平滑地到達目的地，似乎越快完成這個過程越好，所以Android的選擇是理所當然的。但事實是，大家普遍更喜歡iOS的方式，這樣做顯得更順滑、更優雅。

幀率

幀率：FPS是圖像領域中的定義，是指畫面每秒傳輸幀數，通俗來講就是指動畫或視頻的畫面數。30FPS是一般錄像的常用幀數，30FPS在快速動作的時候會感覺不流暢。60FPS是一般游戲的常用幀數。

絕大部分時間兩者(Android和IOS)都能保持60FPS左右的滿幀率。但都會有偶爾的掉幀。并且Android上要比IOS上嚴重很多。掉幀導致卡頓，用戶必然會感覺到掉幀那一刻的不流暢。

觸摸響應速度

從手指碰到觸摸屏，到屏幕上顯示處理這次觸摸產生的畫面，是需要時間的。時間越短感覺越跟手。在軟件系統層面，Android的顯示機制是app-->SurfaceFlinger-->Display，這比傳統的app-->Display多了一步，主要基于這個原因，畫面最終輸出到屏幕要比傳統的方式慢一幀(16.7ms)。

綜合分析：

第1點造成的影響最大，恰恰卻是與技術/設備無關的。如果Android app或者Android系統要改變，很容易就可以調得跟IOS一模一樣。但正是由于這是產品形態上的差別而不是純粹技術上的優劣，反倒成了Android最不太可能改變的。

第2點的影響其次，當然是指在目前這個大部分時候都能滿幀的情況下。這方面是Android從早期到現在進步最明顯的方面，使用了很多方法來優化幀率。但就算現在Android進化了很多，硬件性能也進化了很多，卻仍舊不可能徹底消滅掉幀的情況。

第3點通俗的講就是跟手性，跟手性的重要性不言而喻，但現在的差別比較細微。

Debug是否掉幀

前提條件：android系統4.0+

“開發者選項”->“GPU呈現模式分析”->“在屏幕上顯示為條形圖”，如下圖所示：

屏幕上有條綠色線(基準線)大概是16ms，如果超過這條線則很有可能掉幀了

藍色代表測量繪制Display List的時間

紅色代表OpenGL渲染Display List所需要的時間

黃色代表CPU等待GPU處理的時間

過渡繪制

過度繪制指在屏幕的一個像素上繪制多次，我們對于UI性能的優化還可以通過開發者選項中的GPU過度繪制工具來進行分析。在設置->開發者選項->調試GPU過度繪制(不同設備可能位置或者叫法不同)中打開調試后可以看見如下圖2(對settings當前界面過度繪制進行分析)：

顏色的含義：

Device Monitor

Device Monitor是一個用來給Android 程序進行調試和分析的工具

包括：

• DDMS
• Tracerfor OpenGL ES
• HierarchyViewer
• Traceview

啟動方式

Cmd窗口中 進入sdk目錄中的\tools

輸入: monitor

前提條件：手機要root，否則好多功能用不了

Uiautomatorviewer

uiautomatorviewer 是一個圖形界面工具來掃描和分析應用的UI控件。uiautomatorviewer通過ADB向設備側發送一個dump命令，下載一個包含當前界面控件布局信息的xml文件。

Dump view hierarchy for ui automator

Traceview

Traceview是android平臺配備的一個很好的性能分析工具，堪比java的性能調優工具visualvm線程視圖，可以方便的查看線程的執行情況，某個方法執行時間、調用次數、在總體中的占比等，從而定位性能點。

啟動：點擊下圖中的Start method Profiling

如下圖所示：

a.Incl表示將所有子函數耗時也計算在內，Excl則表示不包括子函數的調用時間。對比可以確定耗時操作發生是自身還是子函數中。

b.Cpu Time表示占用cpu執行的時間，Real Time包括Cpu

Time以及等待、切換的時間等，所以一般都大于Cpu Time。對比可以判斷耗時操作是否在cpu執行段內。

c. 上面四個指標對應的%表示函數在總時間的占比。方便查看某個函數的時間占比。

d.Calls+RecurCalls/Total表示被外部調用次數+遞歸次數/總次數。可以查看調用次數是否符合自己預期。

e.Cpu Time/Call, Real Time/Call表示總的Cpu Time及Real Time與總調用次數的比例。查看每次調用的耗時，一般可通過簡單此項確定每個函數的性能。點擊Devices Tab中的Start Method Profiling 按鈕，需要停止時再次點擊該按鈕即可。

DDMS

概念：DDMS 的全稱是Dalvik Debug Monitor Service，它為我們提供例如：為測試設備截屏，針對特定的進程查看正在運行的線程以及堆信息、Logcat、廣播狀態信息、模擬電話呼叫、接收SMS、虛擬地理坐標等等。DDMS將搭建起IDE與測試終端(Emulator或者connected device)的鏈接，它們應用各自獨立的端口監聽調試器的信息，DDMS可以實時監測到測試終端的連接情況。當有新的測試終端連接后，DDMS將捕捉到終端的ID,并通過adb建立調試器，從而實現發送指令到測試終端的目的。

在monitor中啟動DDMS ，打開\Sdk\tools\monitor.bat,如下圖所示：

LogCat

logcat是Android中一個命令行工具，可以用于得到程序的log信息

Android日志信息都有一個標簽和它的優先級.

日志的標簽是系統部件原始信息的一個簡要的標志。(比如：“View”就 是查看系統的標簽)

下列優先級是按照從低到高順序排列的:

• V —Verbose (lowest priority)
• D —Debug
• I —Info
• W —Warning
• E —Error
• F —Fatal
• S —Silent (highest priority, on which nothing is ever printed)

Thread

查看進程包含的線程信息

Heap

查看進程使用的堆情況

點擊GC可以進行對象回收;

判斷內存泄露：一般情況下，在data object行的“Total Size”這個值得大小決定了是否會有內存泄漏。

a) 不斷的操作當前應用，同時注意觀察data

object的Total Size值;

b) 正常情況下Total Size值都會穩定在一個有限的范圍內，也就是說由于程序中的的代碼良好，沒有造成對象不被垃圾回收的情況，所以說雖然我們不斷的操作會不斷的生成很多對象，而在虛擬機不斷的進行GC的過程中，這些對象都被回收了，內存占用量會回落到一個穩定的水平;

c) 反之如果代碼中存在沒有釋放對象引用的情況，則data

object的Total Size值在每次GC后不會有明顯的回落，隨著操作次數的增多Total Size的值會越來越大，

直到到達一個上限后導致進程被殺掉。

參數含義：

1)Data Object：java object.

2)Class Object：object of type Class, e.g. what you'd get fromjava.lang.String.class or myObject.getClass( ).

3)1,2,4,8-byte array：Number of bytes per entry.

1-byte array: byte, boolean

2-byte array: char, short

4-byte array: float, int

8-byte array: double, long

4)non-Java object：A non-Java Object is a piece of memory that isn't actuallyaccessible from code written in Java. Essentially it's a blob of stuff that gotstuck on the virtual heap but has no meaning to interpreted code. Shouldn't bemuch of that.

分析內存是否泄露：

通過mat 打開com.android.browser.hprof，分析內存

在使用mat前必須轉化\tools\hprof-conv input.hprofoutput.hprof

File Explorer

查看Android系統的目錄文件,常用目錄和文件說明如下：

1、/mnt 掛載點目錄

2、/etc 系統主要配置文件

3、/system Android系統文件

4、/sys Linux 內核文件

5、/proc 運行時文件

6、/init.rc 啟動腳本

7、/default.prop 系統屬性配置文件

8、/data 用戶程序目錄

9、/dev 存放與設備(包括外設)有關的文件(unix和linux系統均把設備當成文件)

AllocationTracker

查看線程中對象被分配的內存情況

Systrace

Systrace是Android4.1中新增的性能數據采樣和分析工具。它可幫助開發者收集Android關鍵子系統(如surfaceflinger、WindowManagerService等Framework部分關鍵模塊、服務)的運行信息，從而幫助開發者更直觀的分析系統瓶頸，改進性能。 注意：手機的內核一定要支持trace(可以查看是否存在/sys/kernel/debug/tracing 這個目錄)，

Systrace的功能包括跟蹤系統的I/O操作、內核工作隊列、CPU負載以及Android各個子系統的運行狀況等。在Android平臺中，它主要由3部分組成：

內核部分：Systrace利用了Linux Kernel中的ftrace功能。所以，如果要使用Systrace的話，必須開啟kernel中和ftrace相關的模塊。

數據采集部分：Android定義了一個Trace類。應用程序可利用該類把統計信息輸出給ftrace。同時，Android還有一個atrace程序，它可以從ftrace中讀取統計信息然后交給數據分析工具來處理。

數據分析工具：Android提供一個systrace.py(python腳本文件，位于Android SDK目錄

/tools/platform-tools/systrace中)用來配置數據采集的方式(如采集數據的標簽、輸出文件名等)和收集 ftrace統計數據并生成一個結果網頁文件供用戶查看。

從本質上說，Systrace是對Linux Kernel中ftrace的封裝(ftrace 的作用是幫助開發人員了解 Linux 內核的運行時行為，以便進行故障調試或性能分析。)。應用進程需要利用Android提供的Trace類來使用Systrace。

點擊下圖中的Capture SystemWide trace

可以設置抓取的系統參數如下：

備注：trace.html需要使用google chrome瀏覽器才能打開分析