一、前言
移動分發市場競爭已進入熾熱化，已不再是當年野蠻生長階段。各大分發市場都在走精細化與差異化路線。其中，省流量更新(增量更新)成爲提升用戶體驗，增加用戶留駐粘性的一項重要指標。所謂增量更新是指app可以通過增量apk的方式進行更新，而不用每次都下載應用全量apk包，該技術可以大大提升app升級效率，提升用戶體驗。
基於以上的背景和考量，應用寶測試團隊，進行了增量更新監控專項，監控自己的增量更新能力。下面撰文，簡述流程與技術棧，以饗讀者。
省流量更新在本文中按照業界術語統稱爲——“增量更新”。
二、增量更新方案
1、增量更新方案總體設計
該增量更新監控，旨在監控實際熱門app的增量更新指標（包括是否有增量更新，更新包大小，更新下載速度等），同時監控增量更新下載階段的CPU,內存是否有異動。
根據市場表現，在PC開發機上，從應用寶市場，批量自動獲取top100（最活躍下載app）作爲待測app。然後100個app循環，依次推送並安裝到指定測試的安卓手機至上，並使用UI自動化技術作爲按鍵控制和app頁面元素監控，成功獲取是否增量更新以及增量更新大小和相關合成/下載速度等指標。與此同時，測試機端上同步開啓CPU,內存等多維度監控手段，並存儲到本地sd卡中，更全面衡量監控期間應用寶的增量更新相關指標。測試完畢，將本地sd卡存儲的相關指標數據，推送回PC端開發機，結合自動腳本實現結果分析與處理，最終結果講入數據庫存儲，並提供WEB端展示相關結果。監控流程自動實現。
下文是增量更新監控方案圖：
2、本文主線
接下來，將以單元方式展開主線敘述。包括——UI監控(UIAutomator端上監控)、CPU監控、內存監控、數據分析處理與結果展示。
主要涉及：
（1）UI監控：java，UIAutomator；
（2）CPU,內存監控: 安卓底層數據獲取，java；
（3）數據分析處理與結果展示：python，numpy，Django框架。
三、UI監控
我們在應用寶上批量獲取典型熱門top100 app作爲待測對象。然後在測試機上進行增量更新監控。
先來確定下UI監控框架。端上UI自動化框架較多，如Appium、Robotium等，本次工程我們我們採用UIAutomator。UIAutomator是爲數不多的安卓官方支持的自動化框架之一。其API簡明而高效，被廣大測試同學所鍾愛。尤其UIAutomator非常適合App間協作所需的跨進程測試，本專項正是此場景。
UI監控部分使用Android Studio和UIAutomator開發，基於篇幅限制，作者默認讀者已有對工具和框架已有了解，新人請參見TMQ已有介紹Android Studio和UIAutomator使用的文章，本文不再複述。
1、UIAutomator精度問題
UIAutomator掃描精度默認是1000ms，而增量更新對時間精度要求嚴格，希望達到百ms級別。所以，需要通過反射更改底層掃描間隔，即WaitMixin類中的DEFAULT_POLL_INTERVAL，其被定義爲 private static final long DEFAULT_POLL_INTERVAL = 1000; 經筆者實踐，在本項目場景中，DEFAULT_POLL_INTERVAL爲200是其精確上限，故而採用200ms作爲UIAutomator掃描間隔精度。
反射機制部分核心代碼：
2、UI操作舉例
該專項中UI操作主要分爲幾類：
（1）模擬按鍵
主要是應用市場調起後，模擬人類按鍵，使得進行相關測試操作。如進入應用市場後，根據resource-id, 來點擊“管理”按鈕，下圖是操作實例。下圖模擬點擊”管理”。
核心代碼如下所示：
（2）獲取頁面元素的值
我們可以通過resouce-id，來獲取頁面元素的值。如圖所示，在應用寶中，可以看到測試手機自帶的豌豆莢軟件是舊版本的，且在應用寶市場是存在增量更新的。我們可以通過獲取resouce-id的value來判斷是否有增量更新以及增量更新包的大小。
如下是核心代碼實現，僅供參考：
（3）狀態檢測
上圖步驟中，點擊”省流量更新”，即可進入增量更新下載增量包階段。檢測進度條尾端的狀態欄，進度條滿且狀態值爲100%更新下載結束。這一段時間，是時間的增量更新時間，之後按鈕會變爲“合成中”。由於100%出現的時間極其的短暫，所以，終止態採用“合成中”出現時間作爲終止態。
代碼片段示意:
上文相關操作，最後將待測app在分發市場上是否有增量更新，增量大小，更新 時間，記錄在SDCARD並推送到PC端聚合彙總。
四、內存監控
增量更新期間，我們會關注應用市場的內存增長情況，以期更好更全面評價性能指標。所以，UI監控同時，我們還在測試機上進行了內存監控和CPU監控，監控增量更新下載期間是否有異常強情況。
由於安卓內核是剪裁的linux基本核。所以，安卓內存底層數據規律和linux是一致的。筆者研究了其內存機制，並找到了一種合適的監控方法。先說操作，再講原理。
Adb shell登錄安卓測試機：
PS應用名，得到pid（進程ID）。
紅色方格爲進程ID。
cat/porc/PID/status可以得到詳細的內存情況。如下圖所示：
各個字段的含義：
VmPeak:表示進程所佔用最大虛擬內存大小
VmSize:表示進程當前虛擬內存大小
VmLck:表示被鎖定的內存大小
VmHWM:表示進程所佔用物理內存的峯值
VmRSS:表示進程當前佔用物理內存的大小(與procrank中的RSS)
VmData:表示進程數據段的大小
VmStk:表示進程堆棧段的大小
VmExe:表示進程代碼的大小
VmLib:表示進程所使用共享庫的大小
VmPTE:表示進程頁表項的大小
在本專項中，VmRSS字段即爲我們所需要的內存大小。通過java實現該腳本，並集成在UIAutomator工程之中，按時間間隔調用即可實現按間隔調用。所獲取數據記錄到測試手機SDCARD之中，監控測試結束推送到PC端聚合。當然，也可以top來找內存信息，不過其精度較差並且刷新有滯後性，所以，建議以本文的方式來獲取進程的內存消耗情況較好。
五、CPU監控
同4，基於安卓出自於linux剪裁的先天條件，我們依然可以從linux底層找CPU的監控規律。當然，我們也可以用top來測試手機上看cpu使用情況。
不過，我們還是希望能更專業一些，去從底層數據，更精準的衡量CPU規律。
/proc///stat, 包含了所有CPU的相關詳情信息。
該文件中的所有值都是從系統啓動開始累計到當前時刻。CPU不是一個瞬時態，而是一個過程態的體現，這一點和內存不同，大家要清楚明白。CPU的時間計數單位是jiffies，爲Linux核心變數(unsigned long)，它被用來記錄系統自開機以來，已經過了多少tick。每發生一次timer interrupt，Jiffies變數會被加一。我們利用process jiffies的消耗，來計算CPU值。即Delta T時間段內消耗的平均jiffies，即爲該時間範圍內的CPU值的大小。下圖是獲取某一時刻的CPU詳情。
我們所需要的process jiffies，具體是/proc//stat文件的第14-17 列。14－17列分別是utime, stime, cutime, cstime。cutime/cstime分別是該進程spawn的子進程在用戶態和內核態消耗jiffies。
process jiffies = utime + stime + cutime + cstime
注意stat中的jiffies是一個絕對累計值，所以要取兩個時間點，算Delta T中消耗的jiffies。(cpu value)= ((current process jiffies) - (last process jiffies) )*100%/(Delta T )。
綜上所述，我們在T1，T2時刻分別/proc///stat,然後提取出process jiffies並與|T1 -T2|做商，即可獲取該時間段內的CPU使用情況。本專項中，採用5S的時間間隔，時間太短會影響CPU的真實值，因爲抖動毛刺的緣故。
六、數據分析處理與結果展示
應用寶增量更新監控做完之後，我們利用python科學計算庫numpy處理下文件。總共100個app，計得100份文件結果，對結果進行清洗和過濾（去異常和髒數據），之後得到詳情數據和最總指標數據，並將結果入庫。
得到mysql中的結果後，爲了直觀展示與管理，我們將統計數據以直觀的形式WEB展現出來。WEB採用Django框架。
最後得到我們需要的結果。結果如下所示：
七、總結
本文以應用寶增量更新監控爲例，向廣大讀者提供幾點借鑑。
1、UIAutomator框架的監控使用方法；
2、安卓CPU和內存的監控方法。
八、思考
本文除了介紹andorid的UI監控，還介紹了內存,cpu管理原理與監控方法。引申一下，如果要做android的IO監控和網絡監控，應該怎麼做呢？
關注微信公衆號騰訊移動品質中心TMQ，獲取更多測試乾貨！
