阿里巴巴 Android 效能測試工具 mobileperf 開源 (天貓精靈 Android 效能測試 - 線下篇)

官方首發 阿里巴巴技術質量：Android 效能測試工具 mobileperf 開源 (天貓精靈 Android 效能測試 - 線下篇)

背景

Android 效能穩定性測試工具mobileperf github 如果您覺得有幫助，請給個 star，有問題歡迎加入文底釘釘群交流

露客 2018 年加入天貓精靈，之前有過一些效能 穩定性測試經驗，但天貓精靈跟我之前的專案經驗不太一樣，之前大多服務於單獨的 APP，比如測手淘就只是測手淘，而天貓精靈業務更復雜一些，主要有如下挑戰：

1、除了天貓精靈手機 APP，還有帶屏天貓精靈上很多 APP 都需要支援，比如天貓精靈 CC 上有 13 個 app，每個 app 使用場景各有不同，涵蓋了通訊錄、影片、音樂、購物等各種場景

2、相比手機 app，除了點選操作的觸屏鏈路，天貓精靈還有語音鏈路

3、手機 app monkey test 一般可能也就雲測平臺上跑幾個小時，語音壓測需要連續測試 72 個小時以上，測試時長遠超雲測工具，對工具的穩定性提出了新的要求

4、相對現在定價動輒幾千塊，均價 2 千左右的手機，天貓精靈定價只有幾百，硬體配置差些，所遇到的效能 穩定性挑戰會更嚴峻

需求

本著前期先能發現問題，再深入定位問題，所以確定了線下、線上分步走的策略

1、線下方案，能方便採集效能資料，工具要支援 Android 手機、天貓精靈各種 Android 定製裝置，支援 Android 全版本，輕量化，使用低門檻，儘可能少侵入甚至零侵入裝置

2、線上效能指標 問題定位

本文是 Android 線下篇

線下方案選型

工具選型

• Android App

​ 代表：開源工具騰訊 GT、網易 Emmagee

​ 劣勢：Android 低版本有些功能需要 root，Android 高版本跨程序獲取資料，許可權限制，不相容

• PC adb 工具

​ 優勢：非侵入，許可權高，能發現問題

​ 劣勢：需要連線資料線，便攜性差點

• SDK

劣勢：侵入式，需整合 SDK，不利於做競品測試

GT github 上已表示 Android GT 後續不再支援 GT APP 版本，只支援 GT SDK

由於 Android 許可權控制越來越嚴格，透過 APP 跨程序獲取效能資料在 Android 高版本已越來越困難，由於 adb shell 許可權比較高，相信 Android 會一直開放開發者許可權，故方案選型階段，採用了依賴 adb 的方案，開發了一套 Android 效能資料採集工具 mobileperf

還有一種思路，仍然是 app 形態，但用了 adb wifi 通道，露客之前也有過一些測試工具 app 的經驗，相比採用 adb usb 方式 mobileperf 的擔憂：

• 測試工具 app，應用程序優先順序，還是會受 Android 限制，擔心繫統資源不足，測試程序優先順序不高，被系統 kill 機率大，在 IOT 低端裝置上被 kill 機率更大，程序保活是業界難題，黑科技手段層出不窮，並且存在隨時被官方封殺的風險，路只會越走越窄，mobileperf 是 PC 程式，除非 adb usb 方式不能用了，裝置失聯，關機等惡劣情況，都 OK，與其花費很大精力探索各種黑科技上，還不如把精力放在 Android 允許範圍內倒騰
• 帶屏天貓精靈都是定製 Android 系統，測試工具 app 可能要做單獨的適配，相容性成本高點，這點 mobileperf 不用擔心，只要是 Android 系統、adb 能用就可以，在各種 Android 定製裝置，使用成本更低

• 由於是 APP，系統需要單獨分配資源，比如工具發現的 anr，開發童鞋一看 cpu 佔用資訊，如果發現測試工具 app 佔用 cpu 較高，就很容易受到挑戰，找工具的鍋（不排除有些 ANR 確實是工具導致的），而 mobileperf 採集都依賴系統命令，這種影響小些

• 長時間測試，比如 72 小時以上，adb wifi 擔心會有點不穩定，畢竟要依賴網路

工具對比

mobileperf 跟 GT APP 對比如下：

架構

mobileperf 整體架構圖：

工具自身影響

mobileperf 對 PC 的影響

測試 PC:MacBook Pro (Retina,15-inch, Mid 2015) 2.2 GHz 四核 Intel Core i7

工具穩定性：mobileperf 能支援跑 72 個小時以上，adb 斷開重連都能繼續採集

工具適用性：支援 mac linux windows 平臺

工具 Android 相容性驗證

mobileperf Android 版本相容性驗證結果如下

phone model	Android version	result
HUAWEI Mate20 HMA-AL00	10	pass
HUAWEI Mate10 ALP-TL00	10	pass
Xiaomi MI 8	10	pass
HUAWEI Mate20 HMA-AL00	9	pass
HUAWEI Mate10 ALP-TL00	9	pass
HUAWEI Mate9 MHA-AL00	9	pass
HUAWEI P10 Plus	9	pass
HUAWEI Honor AL10	9	pass
samsung Note9 SM-N9600	8.1.0	pass
Oppo R15 PACM00	8.1.0	pass
VIVO X23	8.1.0	pass
XiaoMi Note3	8.1.0	pass
RedMi note5	8.1.0	pass
Xiaomi MI 5	8.0.0	pass
smartisan OD103	7.1.1	pass
HUAWEI TRT-AL00	7.0	pass
vivo Y66	6.0.1	pass
XiaoMi Mi2	5.0.2	pass

#

效果

mobileperf 在專案中使用 1 年半，天貓精靈總共發現了效能 穩定性類問題幾百個，bug 解決率都是 100%

採集原理

cpu

方案調研

1、dumpsys cpuinfo

2、top 命令

3、透過 proc/stat 計算 cpu 使用率

兩者區別：Android CPU 使用率：top 和 dump cpuinfo 的不同，看網上一番討論，top 更準

透過實驗發現採集頻率非常快時，top 有點耗 cpu，對手機本身效能有影響，自測，採集頻率 1s，top 在低端手機上（紅米）會佔到 7%（100% 統計方式）的 cpu 使用率，天貓精靈採集頻率 5s，會有 20% 佔用（400% 統計方式），發現 top 的底層實現是讀取 proc 檔案，top 對每個程序都有計算

網上提供了一種計算方式，原理上跟 top 一樣，如果計算指定程序的 cpu 使用率，只需讀對應的 proc 檔案，透過 jiffies 計算就可以了，這樣比 top 方式佔用 cpu 低，計算方式如下

整機 cpu 使用率

透過讀取/proc/stat ，這個檔案包含了所有 cpu 核的彙總情況，所以後面計算不用考慮核數，佔用率不會超過 100%

cpu 使用時間 = user+nice+system+iowait+irq+softirq

CPU 總時間=user+nice+system+idle+iowait+irq+softirq = cpu 使用時間 +cpu idle 時間

總 cpu 使用率=（cpu 使用時間 2-cpu 使用時間 1）/(cpu 總時間 2-cpu 總時間 1)*100%

程序 cpu 使用率

透過讀取/proc/pid/stat

程序 cpu 使用時間 = utime+stime

程序 cpu 使用率=（程序 cpu 使用時間 2-程序 cpu 使用時間 1）/(cpu 總時間 2-cpu 總時間 1)*100%

選定方案

採集時間間隔 ，配置檔案中預設 5 秒，由於對採集頻率要求不高，top 支援同時採集多程序，結果簡單易處理，實時性 可信度高，決定採用 top 的方式

測試過程中會生成 cpuinfo.csv，可以測試過程中檢視，表中各列解釋

彙總 xlsx 檔案會在測試結束後生成，xlsx 資料跟 csv 資料完全一致，xlsx 彙總是根據 csv 的資料畫的曲線（csv 沒有畫圖功能）

記憶體

整機記憶體 可用記憶體透過 dumpsys meminfo 獲取 Total RAM 、Free RAM

各程序 pss 透過 dumpsys meminfo package 獲取 TOTAL 行 Pss Total 所在列的值，各程序 PSS 也可以透過 dumpsys meminfo 獲取，只是拿不到各程序更詳細的記憶體佔比情況，比如堆大小、native、system、so 大小等

經在 CC 上測試發現 dumpsys meminfo 比 dumpsy meminfo package 耗時長，dumpsys meminfo 耗時 6s 多，dumpsys meminfo package 能在一秒內完成，採集頻率 5s，dumpsy meminfo 會導致 CC 上 system_server 系統程序 cpu 由 2% 增高到 80%，所以降低了 dumpsys meminfo 採集頻率，採用 10 倍設定頻率採集（比如 dumpsys meminfo package 5s，dumpsy meminfo 則 50s）

由於要支援多程序的情況，現在各程序 pss 透過解析 dumpsys meminfo 結果得到，dumpsys meminfo package 來獲取各個程序的詳細記憶體情況

在測試過程中會生成一個 meminfo.csv 檔案，可以檢視，表中各列解釋

這個 csv 表格是用 dumpsys meminfo 得出的，彙總 xlsx 檔案會在測試結束後生成，對應 meminfo 這個表格

每個程序會有 pss_部分包名的 csv 表格，這個表格是用 dumpsys meminfo package 得出的

能把每個程序的詳細記憶體展示出來

彙總 xlsx 中對應 pss_部分包名這個表格

如果程序發生了記憶體洩露，根據曲線，很方便一眼就看出是哪部分導致洩漏

為了幫助定位記憶體洩漏問題，工具每隔一個小時會執行 am dumpheap package ，dump 程序記憶體，但不能像 LeakCanary 直接翻譯出 GC 引用鏈，仍需人工分析下

流暢度（fps/丟幀）

fps 透過 dumpsys SurfaceFlinger 或 dumpsys gfxinfo(android8.0 之後) 獲得最近 128 幀資料計算得出，fps=幀數/耗費時間

如果以上兩種方式都不 OK，機器有 root，用 service call SurfaceFlinger 1013 獲取幀數

透過 dumpsys SurfaceFlinger 的方式還會計算丟幀 janky 值

丟幀：相鄰兩次繪製之間的丟幀數，丟幀數越多，說明問題越嚴重，mobileperf 預設丟幀數超過 10 幀算是嚴重丟幀

流暢度資料在 fps.csv 中

表中各列解釋

頁面開啟耗時

mobileperf 從 logcat 日誌中抓取 am_activity_fully_drawn_time 和 am_activity_launch_time（大多數情況）日誌，

會生成 launch_logcat.csv

不過這種方式有個弊端，日誌的耗時不能完全反饋真實的體驗耗時，我們內部已有其他方案測試啟動耗時

monkey（可限制 activity）

mobileperf 呼叫了 Android 原生的 monkey，如果您想限制在指定內 activity 內跑 monkey ，可以透過配置項，開啟 monkey 後，會在測試目錄下生成 monkey.log

#如果需要在限定activity內做monkey test，main_activity是模組的幾個主入口，用分號; 分隔
#main_activity=com.alibaba.ailabs.genie.contacts.MainActivity
#activity_list是准許的activity，main_activity開啟前提下有效
activity_list=com.alibaba.ailabs.genie.contacts.MainActivity;
        com.alibaba.ailabs.genie.contacts.cmd.CmdDispatchActivity;
        com.alibaba.ailabs.genie.contacts.cmd.transform.VoipToPstnActivity;
        com.alibaba.ailabs.genie.contacts.add.AddContactsActivity;
        com.alibaba.ailabs.genie.contacts.avatar.TakePhotoActivity;
        com.alibaba.ailabs.genie.contacts.details.DetailsActivity;
        com.alibaba.ailabs.genie.contacts.add.RelationshipActivity;
        com.alibaba.ailabs.genie.contacts.details.DownloadTipsActivity;
        com.alibaba.ailabs.genie.contacts.details.DownloadTipsMiniActivity;
        com.alibaba.ailabs.genie.contacts.cmd.selectlist.call.VCallListActivity;
        com.alibaba.ailabs.genie.contacts.cmd.selectlist.contacts.VContactListActivity;
        com.alibaba.ailabs.genie.contacts.message.VoiceDetailsActivity

logcat 日誌（支援異常日誌檢測）

工具會保留全量 logcat 日誌，每隔 60 萬行會新建檔案，輔助定位問題

如果配置檔案中配置了異常日誌

會將 logcat 中出現的異常日誌都儲存在 exception.log 中

根據異常彙總日誌，再去 logcat 日誌檢視詳細上下文資訊，可以快速定位問題

流量

透過讀取/proc/net/xt_qtaguid/stats 檔案獲取，因為 Android 提供的流量統計 API – TrafficStats 中，對 uid 進行流量統計的方法，能區分應用，底層就是讀取了該檔案

Android 效能測試之網路流量

流量資料在 traffics_uid.csv 中，表中各列解釋

<=android9 讀取/proc/net/xt_qtaguid/stats 獲取流量

Android10,/proc/net/xt_qtaguid/stats not found,用/proc/net/dev /proc/pid/net/dev 獲取流量

電量

先透過 dumpsys batteryproperties 獲取，如果獲取不到，再透過 dumpsys battery 獲取（Android9）

問題：插著 usb，這兩種方式獲取到的並不精準，並非專業級電流電量測試，只能作為參考

電量資料在 powerinfo.csv 中，表中各列解釋

由於功耗軟體測試方式不太精準，我們內部已用硬體方案測試功耗，此項 mobileperf 中預設關閉

常駐程序 pid 監控

天貓精靈是整機，跟很多手機 app 不一樣，是應用級別 app，可能會被使用者手動 kill 掉，天貓精靈上有些系統優先順序程序，不能掛掉，一旦掛掉，會導致無法使用，所以 mobileperf 新增了常駐程序 pid 監控，一旦 pid 發生了變化，認為發生了異常

#常駐程序，需要關注pid變化,多個程序，英文分號分隔
pid_change_focus_package=com.alibaba.ailabs.genie.smartapp;com.alibaba.ailabs.genie.smartapp:core

磁碟剩餘空間檢查

天貓精靈跟很多手機 app 不一樣，隨便壓測就是 3 天以上，如果有寫檔案不正常，佔滿磁碟空間，會導致機器徹底無法使用，影響使用者體驗，所以測試結束時，新增了對磁碟剩餘空間檢查，如果使用空間超過 80%，則自動提單

程序執行緒數

透過程序名獲取 pid，ls -lt /proc/pid/task，統計多少行數即執行緒數

答疑

為了方便大家更容易的接入 mobileperf 或討論相關技術，大家可加入釘釘交流群 32266824。為了方便大家交流，入群請註明姓名與公司等資訊。