【Android场景化性能测试】UI流畅度篇

作者：陈帅

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

一、背景介绍

UI流畅度测试，是笔者设计整个框架的最初的痛点，前述的耗电、内存等属于框架拓展功能。

在本框架之前，部门一直使用GT工具来获取流畅度数据，并使用SM量化模型(一种收集丢帧，并通过合适算法得到最终分数的评估模型)评估流畅度，使用页面驱动的UI自动化来编写用例。但执行了多轮测试后，发现存在一些问题：

1、原方案测试流畅度依赖于ROOT手机，如果需要对某款手机做专门评测，存在局限；

2、由于是借助GT方案收集SM数据，UI驱动中需要先拉起被测应用，以确保GT拿到被测应用的pid，然后拉起GT工具开始收集SM数据，再拉起被测应用开始测试。这样的流程将被重复多次，导致进行一轮性能测试的周期在1小时以上；

3、方案为页面驱动方案，特点是以用户点击为分界点，将流畅度数据拆分成不同页面的数据；

4、UI驱动方案主要是点击文本，在UI自动化中，text点击是需要经过查找、点击，这样会导致每次点击的间隔并不一致。流畅度数据建立在大样本之上才更为准确（反复执行被测场景），但该框架对这种用例逻辑的支持力度不够。

二、GT原理分析

GT工具是腾讯开源的用于测试各类性能数据的工具，分析下它收集流畅度数据的原理。如下图，GT所做的工作有4部分：

1、将系统丢帧告警log的阈值从30修改为1。这个只能在root手机上才操作有效；

2、SMLogService：收集系统中Choreographer打出的丢帧日志，并过滤掉非被测应用的日志，将被测应用的丢帧offer到一个BlockingQueue< Integer >中；

3、SMDataService：控制时间间隔为1s，将丢帧数分配到各个秒中去，统计出各秒的SM值。如果出现某一秒的SM值超过60，需要做前序SM值修正；

4、输出SM值序列到文件或log中。

[1509093444371_5957_1509093679437.png]

图一GT输出SM数据原理

简而言之，GT在流畅度上，其实就是将丢帧换算成SM值给到测试人员了。至于为什么要用ROOT手机才能测试，是因为系统为了减少无必要的日志，将SKIPPED_FRAME_WARNING_LIMIT值默认设置为30。导致UI线程doFrame时，只要丢帧不高于30帧，就不会通过log告警。

[1509093457928_7006_1509093692860.png]

图二Choreographer doFrame源码

三、数据收集

借用GT工具，既限制了测试场景，又将测试操作复杂化了，那是不是可以不借用GT工具，收集到SM数据呢？答案是肯定的。

使用logcat收集Choreographer丢帧数据。

命令：logcat -v time Choreographer:I *:S

日志行示意如下，其中包括信息：

1）该丢帧信息属于哪一秒；

2）该丢帧信息属于哪一个进程pid；

3）本次丢帧具体数值为1。

=> 08-0817:43:29.715 I/Choreographer(25459): Skipped 1 frames! The application may be doing too much work onits main thread。

这些信息有什么用呢？

（1）知道了丢帧属于哪一秒，我们可以摒弃GT自己来控制时间间隔，再gather丢帧数据的方案。换成新方案：直接将手机系统log吹按的不同秒的丢帧数据gather到一起，方法更为简单；

（2）该丢帧数据的进程信息，只统计被测程序的流畅度；

被测应用插桩替代ROOT手机方案。

执行命令（setpropdebug.choreographer.skipwarning1）是从系统全局上将Choreographer的SKIPPED_FRAME_WARNING_LIMIT修改为1。而使用如下图的反射set方式，可以将直接将被测应用的SKIPPED_FRAME_WARNING_LIMIT修改为1。

[1509093482988_9217_1509093717845.png]

图三反射修改SKIPPED_FRAME_WARNING_LIMIT

需要注意的是，方案收集到的日志行可能是如下图四的序列。有以下三种情况：

（1）14:55:52时刻的丢帧是：3 + 1 = 4，所以SM值为56；

（2）14:55:53时刻无丢帧，所以SM值为60；

（3）14:56:00时刻的丢帧是：89，但同一秒内最多丢帧60个，所以需要对前序时刻的SM值做修正，得到14:55:59时刻SM为31，14:56:00时刻SM为0。

[1509093493138_8916_1509093728018.png]

图四丢帧日志序列

根据上述三种情况的逻辑，可以得到如下图五，计算SM值的核心逻辑。至于如何从日志行中取出时间、pid、skipped frame值，无非是正则表达式，不再赘述。

[1509093502424_5842_1509093737342.png]

图五SM值计算核心逻辑

四、UI自动化用例

本篇需要特意提一下UI自动化的逻辑，需要注意两个点：

1、主路径循环执行多次，保证收集到的场景性能数据有较大样本，避免数据波动；

2、如下图六，click_by_coordinate()的逻辑是，第一次点击时保存该按钮的绝对坐标信息，后续点击都使用绝对坐标进行点击。使用非坐标点击，由于需要进行查找，PC和手机通信，所以操作间隔 = 用例逻辑sleep时长 + 查找控件时长 + 通信耗时。而使用坐标点击，就可以做到自己控制操作间隔，尽量做到每次测试的流畅区间vs卡顿区间波动较小，数据更加稳定。

[1509093513079_13_1509093748173.png]

图六UI用例逻辑

五、数据使用（算法）

拿到较大样本的数据后，可以有多种方案体现在报告中。

1、表格体现

如下SM值大的范围占比越高，代表流畅度性能越好。

[1509093525744_2098_1509093760674.png]

图七表格示意

2、柱状图体现

优点在于更为直观，可以看到上部的深蓝色和绿色区间越长，代表流畅度越好。

[1509093537388_2115_1509093772599.png]

图八图形示意

上述数据处理的算法，可以直接使用excel的公式来搞，也可以使用如下图的代码处理。

[1509093562539_5981_1509093797434.png]

图九获取测试报告结果的算法

3、SM打分评估

首先需要介绍两个概念：流畅区间、卡顿区间。用户使用一个APP，对于静态页面，一般流程是看一个页面，然后点击某处，等待响应，再接着看，以此循环。在此过程中，只有“点击某处”会触发新的UI线程操作，有可能导致卡顿，这个卡顿的时间区域，可称之为卡顿区间。而没有用户操作的区间则称之为流畅区间。

加入获取到的流畅度数据样本中有100秒的数据，其中可能只有10秒的卡顿区间数据。如果直接将100组数据取平均值，会发现10秒卡顿完全被90组流畅抹平。为了提高卡顿区间占比，可以加快操作速率，但这就不是真实的用户场景了。可以从另一个方向思考——算法：为了弱化流畅区间的数据，执行算法以下三步：

（1）每五秒取一个最小值，获取一个最小值序列；

（2）将最小值序列中的每个值，使用抛物线函数将SM值0~60对应到分值 0~100分，这是为了让丢帧多的值打分低，从而突出丢帧高的点；

（3）最后取分数平均值。

[1509093592552_5829_1509093827470.png]

图十SM换算评分方程曲线

最终得到的报告：

[1509093601992_8520_1509093836896.png]

图十一SM评分对比

算法代码：

[1509093611683_7688_1509093846576.png]

图十二SM换算评分算法代码

总结，流畅度测试三要素：

（1）UI驱动需要严格控制流畅区间、卡顿区间的占比，取决于用户操作密度；

（2）数据收集，样本要足够；

（3）报告使用的算法或图表，要更为科学些，不能直接用平均值了事。

搜索微信公众号：腾讯移动品质中心TMQ，获取更多测试干货！