背景
天貓精靈業務主要有如下挑戰：
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 通道，look 之前也有過一些測試工具 app 的經驗，相比採用 adb usb 方式 mobileperf 的擔憂：
1、測試工具 app，應用進程優先級，還是會受 Android 限制，擔心繫統資源不足，測試進程優先級不高，被系統 kill 概率大，在 IOT 低端設備上被 kill 概率更大，進程保活是業界難題，黑科技手段層出不窮，並且存在隨時被官方封殺的風險，路只會越走越窄，mobileperf 是 PC 程序，除非 adb usb 方式不能用了，設備失聯，關機等惡劣情況，都 OK，與其花費很大精力探索各種黑科技上，還不如把精力放在 Android 允許範圍內倒騰
2、帶屏天貓精靈都是定製 Android 系統，測試工具 app 可能要做單獨的適配，兼容性成本高點，這點 mobileperf 不用擔心，只要是 Android 系統、adb 能用就可以，在各種 Android 定製設備，使用成本更低
3、由於是 APP，系統需要單獨分配資源，比如工具發現的 anr，開發童鞋一看 cpu 佔用信息，如果發現測試工具 app 佔用 cpu 較高，就很容易受到挑戰，找工具的鍋（不排除有些 ANR 確實是工具導致的），而 mobileperf 採集都依賴系統命令，這種影響小些
4、長時間測試，比如 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 版本兼容性驗證結果如下
效果
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 文件，可以查看，表中各列解釋
mem table
這個 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.VoiceDetailsActivitylogcat 日誌（支持異常日誌檢測）
工具會保留全量 logcat 日誌，每隔 60 萬行會新建文件，輔助定位問題
如果配置文件中配置了異常日誌
會將 logcat 中出現的異常日誌都保存在 exception.log 中
根據異常彙總日誌，再去 logcat 日誌查看詳細上下文信息，可以快速定位問題
流量
通過讀取/proc/net/xt_qtaguid/stats 文件獲取，因為 Android 提供的流量統計 API – TrafficStats 中，對 uid 進行流量統計的方法，能區分應用，底層就是讀取了該文件，參考Android 性能測試之網絡流量
流量數據在 traffics_uid.csv 中，表中各列解釋
電量
先通過 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 的 github 地址：https://github.com/alibaba/mobileperf 如果您覺得有幫助，請給個 star！同時如果有疑問的話，可以加入該釘釘答疑群。
