如何准确评测Android应用的流畅度？

如何准确评测Android应用的流畅度？

做者简介：

叶方正 2008年加入腾讯，就任于无线研发部【专项测试组】。曾经负责多个产品的性能优化工做，积累大量的移动终端平台优化以及评测经验。

---

怎样获取SM值？

经过测量应用的帧率FPS并不能准确评价App的流畅度，FPS较低并不能表明当前App在UI上界面不流畅，而1s内VSync这个Loop运行了多少次更加能说明当前App的流畅程度。

那么咱们能够直接在App代码中经过Choreographer的回调FrameCallback来计算Loop被运行了几回，从而知道应用的流畅度。但在实际状况下咱们不必定能修改代码（实际发布的版本不容许加入测试代码）或者根本拿不到代码（譬如和竞品进行对比）。

今天咱们介绍一种更简单直观测量Android应用流畅度的方法，就是经过开源测试工具GT（http://gt.qq.com）。

一、先启动要测试的应用。

二、启动GT，在插件中选择GT Injector，再选择被测进程，点击“射它”。

三、点击后，Para界面会出现流畅度指标以及被插入程序的CPU占有率，而且会带上被插入的进程名。将流畅度后面小方框勾选（表示须要记录SM值到log文件），而后点击右个角“Gather & Warning”下小红圈（表示开始记录数值）。

四、启动App，开始作相关的测试。

五、完成测试后，在GT界面点击流畅度(SM)，则会出现已经记录的SM值图表，点击右上角磁盘图标，保存log到指定名字的文件夹。

六、最后利用工具（好比应用宝），把log导入到PC端进行后期处理（通常状况下，文件保存路径在：SD卡/GT/GW/进程名/自定义文件夹）。

---

SM测试效果如何？

咱们已经收集了SM的测试数据，但测试数据是否准确？咱们拿一些浏览器产品为例子，来评测下SM的数据和人的感觉是否对应得上。

首先，咱们为了把感官和人的感觉对应上，特把主动感官分数对应到如下几种描述。

一、先看看流畅度(SM)和丢帧(SF)之间的关系

测试场景：浏览器看妹子图

评测手机：Nexus 4

流畅度主观评分(整体)：2.5（界面滑动明显顿挫感，响应用户输入有种慢半拍的感受）

由于丢帧是个不连续的过程，因此图中的丢帧都是以点来表示其离散的状态。从上面图表能够看出：

丢帧(SF)越多，流畅度(SM)越低。

26:16~26:42之间的流畅度很低，而且丢帧最密集。

再总体梳理一下这期间流畅度、丢帧和主观评分的数据：

从这个数据能够看到，丢帧(SF)越多流畅度(SM)越低，而且主观感受比较卡，这个关系是成立的。

二、再引入FPS看看三者关系

测试场景：浏览器看妹子图

评测手机：Nexus 4

流畅度主观评分(整体)：2.5

此次测试引入了FPS数据，从图表中能够看出:

FPS曲线和SM曲线差很少，并且一样受丢帧的影响。

有段比较奇怪的地方：流畅度很高，但FPS比较低，无丢帧状况，将这段数据放大来看：

检查这个时段的测试场景：静置在某个界面没有动，主观评分在4.5左右。

再总体梳理一下这个时间段FPS、流畅度、丢帧和主观的数据：

能够看出，流畅度SM会比FPS更加适合客观描述App卡的程度。

---

如何有效利用SM值判断App流畅度？

肯定了使用SM值来评估手机App的流畅度后，咱们会开始进行一个产品在不一样场景，以及多个产品间在相同场景下的测试对比。场景太多，测试数据巨大，该如何有效使用SM测试结果去判断App流畅状况？

一、一些思路

不能直接用平均值和方差
根据以往经验，经过平均值，方差等一些指标，并很差说明问题。若是卡顿时间出现较短，测试时间较长，则平均值和方差这种指标不容易发现问题，可是又确实有卡顿。平均值和方差适合描述服从正态分布的随机变量，可是测试获得的SM值并非这样的随机变量。

将测试结果按卡顿和流畅分段，对每一个卡顿区间段打分
以前参考了一篇游戏流畅度评分的文章，该文章结合FPS平均值和卡顿的程度以及频率，对游戏总体流畅度打分。可是普通App和游戏的区别比较大。对普通App来讲，用户不是一直在操做，并且不一样的操做差别也较大，所以卡顿的频率通常较低，用平均值和卡顿的频率打分获得的结果可能会偏高。因此把测试过程按照卡顿和流畅分段，计算每一个卡顿区间的打分和持续时间可能更有参考意义。

整体打分时加大卡顿时的权重，下降流畅区间的权重
虽然咱们重点关注的多是卡顿的地方，可是竞品测试，以及两个版本对比须要有整体评判结果，不能只看局部。为了加大结果的区分度，对卡顿区间增长权重，对流畅区间下降权重，来突出卡顿对总体评分的影响。所以，评估结果将包括两部分：整体打分，以及卡顿区间、流畅区间的持续时间和打分。

二、流畅度评估方法

预处理，每5个（秒）一组，取最低值。若是5秒内出现多于一次卡顿（SM低于40），则再乘以一个和卡顿次数有关的权值（小于1）。

【说明】若是卡顿出现次数较少，平均值和方差不容易发现问题。所以没有直接对数据评估，先进行了预处理，突出SM值低的部分，加大卡顿对总分的影响。
处理前的三组数据：

处理后的三组数据：

将处理后的数据按卡顿和流畅分段，针对每段打分。

【说明】若是只有最后总分，且流畅的时间较长，卡顿的数据容易被流畅的数据淹没。并且有些测试场景存在一段流畅，一段卡顿的现象，卡顿并不必定在整个测试过程当中存在。这样分开流畅和卡顿的区间处理，更容易看出卡顿的程度。

根据测试经验，对SM值对应的卡顿严重程度打分。

【说明】根据测试同窗的经验，流畅度指标SM低于40时，用户能感知到卡顿，SM在20如下卡顿比较严重。所以在打分时，SM值在20如下时打分最低，对应0-20，在20-30区间打分低，对应20-60，30-40区间打分较低，对应60-70，40以上打分在70以上。
整体打分时下降流畅区间的权重。

【说明】这样处理的缘由和第一项的缘由同样，咱们更关注的是卡顿，流畅区间过长时会淹没卡顿的数据。

三、对比几个浏览器产品在同一个场景下的测试数据

测试场景：浏览网页

评测手机：Nexus 4

测试方法：打开凤凰网，来回上下滑动，在滑动的过程当中记录流畅度数据

流畅度评估后数据：

从上面的数据能够看出，在滑动浏览网页时，C浏览器略微好于A浏览器和B浏览器。

固然这都是在性能比较好的手机（Nexus 4）上测试，其实主观感觉差距不大，但从量化数据上就能够看出优略。

---

小编有话说

卡顿的问题严重性，可能不像崩溃来得那么强烈，但对于用户的流失影响是潜移默化，慢慢深刻。若想知道本身产品流畅度如何，也能够试试用SM来评测本身产品性能。

---

腾讯Bugly简介

Bugly是腾讯内部产品质量监控平台的外发版本，其主要功能是App发布之后，对用户侧发生的Crash以及卡顿现象进行监控并上报，让开发同窗能够第一时间了解到App的质量状况，及时机型修改。目前腾讯内部全部的产品，均在使用其进行线上产品的崩溃监控。