APP省流量更新监控最佳实践

作者：马国俊

团队：腾讯移动品质中心TMQ

一、前言

移动分发市场竞争已进入炽热化，已不再是当年野蛮生长阶段。各大分发市场都在走精细化与差异化路线。其中，省流量更新(增量更新)成为提升用户体验，增加用户留驻粘性的一项重要指标。所谓增量更新是指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/<pid>//stat, 包含了所有CPU的相关详情信息。

该文件中的所有值都是从系统启动开始累计到当前时刻。CPU不是一个瞬时态，而是一个过程态的体现，这一点和内存不同，大家要清楚明白。CPU的时间计数单位是jiffies，为Linux核心变数(unsigned long)，它被用来记录系统自开机以来，已经过了多少tick。每发生一次timer interrupt，Jiffies变数会被加一。我们利用process jiffies的消耗，来计算CPU值。即Delta T时间段内消耗的平均jiffies，即为该时间范围内的CPU值的大小。下图是获取某一时刻的CPU详情。

我们所需要的process jiffies，具体是/proc/<pid>/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/<pid>//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，获取更多测试干货！