腾讯移动品质中心TMQ [腾讯 TMQ] APP 省流量更新监控最佳实践

tmq · 发布于 2017年12月06日 · 最后由 codeskyblue 回复于 2017年12月07日 · 119 次阅读

一、前言

移动分发市场竞争已进入炽热化,已不再是当年野蛮生长阶段。各大分发市场都在走精细化与差异化路线。其中,省流量更新(增量更新)成为提升用户体验,增加用户留驻粘性的一项重要指标。所谓增量更新是指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,获取更多测试干货!

共收到 1 条回复
6853

介绍的好详细

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册