请选择 进入手机版 | 继续访问电脑版
Ptlogin
 找回密码
 立即注册

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

[复制链接]

该用户从未签到

66

主题

68

帖子

6545

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
6545
发表于 2015-11-6 16:45:43
Bugly 技术干货系列内容主要涉及移动开发方向,是由 Bugly 邀请腾讯内部各位技术大咖,通过日常工作经验的总结以及感悟撰写而成,内容均属原创,转载请标明出处。
怎样获取SM值?
前文我们分析了通过测量应用的帧率FPS并不能准确评价App的流畅度(如何量化Android应用的“卡”?流畅度原理&定义篇),FPS较低并不能代表当前App在UI上界面不流畅,而1s内VSync这个Loop运行了多少次更加能说明当前App的流畅程度。
那么我们可以直接在App代码中通过Choreographer的回调FrameCallback来计算Loop被运行了几次,从而知道应用的流畅度。但在实际情况下我们不一定能修改代码(实际发布的版本不允许加入测试代码)或者根本拿不到代码(譬如和竞品进行对比)。
今天我们介绍一种更简单直观测量Android应用流畅度的方法,就是通过开源测试工具GT([url=]http://gt.qq.com[/url])。
1、先启动要测试的应用。
2、启动GT,在插件中选择GT Injector,再选择被测进程,点击“射它”。

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

4、启动App,开始做相关的测试。
5、完成测试后,在GT界面点击流畅度(SM),则会出现已经记录的SM值图表,点击右上角磁盘图标,保存log到指定名字的文件夹。

6、最后利用工具(比如应用宝),把log导入到PC端进行后期处理(一般情况下,文件保存路径在:SD卡/GT/GW/进程名/自定义文件夹)。

温馨提醒:以上的操作因为涉及到进程注入需要手机Root权限,如有问题,可以加GT交流群咨询(QQ群号:145535035)。
SM测试效果如何?
我们已经收集了SM的测试数据,但测试数据是否准确?我们拿一些浏览器产品为例子,来评测下SM的数据和人的感受是否对应得上。
首先,我们为了把感官和人的感受对应上,特把主动感官分数对应到以下几种描述。
流畅度主观评分
描述
4~5
界面滑动流畅
并且能够快速响应用户输入(各种操作)
3~4
界面滑动顿挫感
并且能够及时响应用户输入(各种操作)
2~3
界面滑动明显顿挫感
响应用户输入(各种操作)有种慢半拍的感觉
1~2
界面滑动明显画面跳跃感
响应用户输入(各种操作)有严重的延迟
0~1
不能动了
1、先看看流畅度(SM)和丢帧(SF)之间的关系
测试场景:浏览器看妹子图
评测手机:Nexus 4
流畅度主观评分(总体):2.5(界面滑动明显顿挫感,响应用户输入有种慢半拍的感觉

因为丢帧是个不连续的过程,所以图中的丢帧都是以点来表示其离散的状态。从上面图表可以看出:
  • 丢帧(SF)越多,流畅度(SM)越低。
  • 26:16~26:42之间的流畅度很低,并且丢帧最密集。

再整体梳理一下这期间流畅度、丢帧和主观评分的数据:
主观评分
流畅度均值
丢帧均值
2.50
25.26
34.15
从这个数据可以看到,丢帧(SF)越多流畅度(SM)越低,并且主观感觉比较卡,这个关系是成立的。
2、再引入FPS看看三者关系
测试场景:浏览器看妹子图
评测手机:Nexus 4
流畅度主观评分(总体):2.5

这次测试引入了FPS数据,从图表中可以看出:
  • FPS曲线和SM曲线差不多,而且同样受丢帧的影响。
  • 有段比较奇怪的地方:流畅度很高,但FPS比较低,无丢帧情况,将这段数据放大来看:


检查这个时段的测试场景:静置在某个界面没有动,主观评分在4.5左右。
再整体梳理一下这个时间段FPS、流畅度、丢帧和主观的数据:
主观分
流畅度均值
丢帧均值
FPS均值
4.5
58.375
0.5
16.333
可以看出,流畅度SM会比FPS更加适合客观描述App卡的程度。
如何有效利用SM值判断App流畅度?
确定了使用SM值来评估手机App的流畅度后,我们会开始进行一个产品在不同场景,以及多个产品间在相同场景下的测试对比。场景太多,测试数据巨大,该如何有效使用SM测试结果去判断App流畅情况?

1、一些思路
  • 不能直接用平均值和方差

根据以往经验,通过平均值,方差等一些指标,并不好说明问题。如果卡顿时间出现较短,测试时间较长,则平均值和方差这种指标不容易发现问题,但是又确实有卡顿。平均值和方差适合描述服从正态分布的随机变量,但是测试得到的SM值并不是这样的随机变量。
  • 将测试结果按卡顿和流畅分段,对每个卡顿区间段打分

之前参考了一篇游戏流畅度评分的文章,该文章结合FPS平均值和卡顿的程度以及频率,对游戏整体流畅度打分。但是普通App和游戏的区别比较大。对普通App来说,用户不是一直在操作,而且不同的操作差异也较大,因此卡顿的频率一般较低,用平均值和卡顿的频率打分得到的结果可能会偏高。所以把测试过程按照卡顿和流畅分段,计算每个卡顿区间的打分和持续时间可能更有参考意义。
  • 总体打分时加大卡顿时的权重,降低流畅区间的权重

虽然我们重点关注的可能是卡顿的地方,但是竞品测试,以及两个版本对比需要有总体评判结果,不能只看局部。为了加大结果的区分度,对卡顿区间增加权重,对流畅区间降低权重,来突出卡顿对整体评分的影响。因此,评估结果将包括两部分:总体打分,以及卡顿区间、流畅区间的持续时间和打分。
2、流畅度评估方法
  • 预处理,每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以上。
  • 总体打分时降低流畅区间的权重。

【说明】这样处理的原因和第一项的原因一样,我们更关注的是卡顿,流畅区间过长时会淹没卡顿的数据。
3、对比几个浏览器产品在同一个场景下的测试数据
测试场景:浏览网页
评测手机:Nexus 4
测试方法:打开凤凰网,来回上下滑动,在滑动的过程中记录流畅度数据

流畅度评估后数据:


从上面的数据可以看出,在滑动浏览网页时,C浏览器略微好于A浏览器和B浏览器。
当然这都是在性能比较好的手机(Nexus 4)上测试,其实主观感受差距不大,但从量化数据上就可以看出优略。

如果你觉得内容意犹未尽,如果你想了解更多相关信息,请扫描以下二维码,关注我们的公众账号,可以获取更多技术类干货,还有精彩活动与你分享~
                                                     

腾讯 Bugly是一款专为移动开发者打造的质量监控工具,帮助开发者快速,便捷的定位线上应用崩溃的情况以及解决方案。智能合并功能帮助开发同学把每天上报的数千条 Crash 根据根因合并分类,每日日报会列出影响用户数最多的崩溃,精准定位功能帮助开发同学定位到出问题的代码行,实时上报可以在发布后快速的了解应用的质量情况,适配最新的 iOS, Android 官方操作系统,鹅厂的工程师都在使用,快来加入我们吧!


+113
使用道具 举报 回复
您需要登录后才可以回帖 登录

本版积分规则