订阅移动开发RSS CSDN首页> 移动开发

腾讯Bugly干货分享:Android应用性能评测调优

发表于2015-06-17 09:15| 次阅读| 来源CSDN| 0 条评论| 作者叶方正

摘要:Android App各项性能如CPU、内存消耗等都是开发测试中需要关注的指标,如何将App打造的更加“优雅”是开发者们需要不断追求探索的方向,本文作者从内存和流畅度两个纬度来说说如何对Android App进行评测和调优。

7. 那么SM实际的测试效果如何?

所以,我们拿a、b、c三个浏览器为例,对比评测下这样的数据和人感受是否对应得上。首先,我们为了把感官和人的感受对应上特把主动感官分数对应到以下几种描述如下表:


场景1. 浏览妹子图……看看流畅度(SM)和丢帧(SF)之间关系

来看看流畅度(SM)和丢帧(SF)之间关系…这个数据是用浏览器浏览妹子图时采集。因为丢帧是个不连续的过程,所以后面的图中丢帧都是以点来表示其离散的状态。


从上面图可以看出:

  • 丢帧(SF)越多流畅度(SM)越低…
  • 26:16秒后到26:42之间流畅度很低并且丢帧最密集,在这段期间流畅度主观评分在2.5。
  • 再看看这期间流畅度,丢帧和主观的对应关系:


从这个数据可以看到丢帧(SF)越多流畅度(SM)越低,并且主观感觉是比较卡的(界面滑动明显顿挫感,响应用户输入有种慢半拍的感觉)。

场景2. 看妹子图……引入FPS看看这3者关系…

同样这段看妹子的过程中主观感受也是在2.5分:


这个数据里面引入了FPS数据。从上图可以看出:

  • 虽然FPS曲线和SM曲线差不多而且同样受丢帧的影响;
  • 里面有几段比较奇怪的地方:

1)流畅度很高FPS比较低,无丢帧情况…当时静置在某个界面没有动此时主观评分应该在4.5左右;
2)FPS比较高,丢帧很严重流畅度很低…当时在不断刷新很多图片出来主观评分应该在2.0以下。

把这2部分数据放大看:

流畅度很高FPS比较低无丢帧:


本场景数据统计:


这个局部场景虽然画面一直在动,没有丢帧FPS在20以下但是流畅度比较高。So…从次场景可以看出这样流畅度SM比FPS更加适合来客观描述Android App卡的程度。

8. 问题来了:这么多数据实在hold不住

从上面可以看出数据量比较大而且几个产品条曲线之间有交错那如何评定哪个在某些场景下更好呢?于是我们就想:通过SM数据判断App流畅情况,并给出一个定量的结果。

思路:

  1. 不能直接用平均值和方差。根据以往经验,通过平均值、方差等一些指标,并不好说明问题。如果卡顿时间出现较短,测试时间较长,则平均值和方差这种指标不容易发现问题,但是又确实有卡顿。平均值和方差适合描述服从正态分布的随机变量,但是测试得到的SM值并不是这样的随机变量。
  2. 将测试结果按卡顿和流畅分段,对每个卡顿区间段打分。参考了KM上一篇游戏流畅度评分的文章,该文章结合FPS平均值和卡顿的程度以及频率,对游戏整体流畅度打分。但是普通App和游戏区别还是比较大的。对普通App来说,用户不是一直在操作,不同的操作差异也较大,因此卡顿的频率一般较低,用平均值和卡顿的频率打分得到的结果可能会偏高。所以把测试过程按照卡顿和流畅分段,计算每个卡顿区间的打分和持续时间可能更有参考意义。
  3. 总体打分时加大卡顿时的权重,降低流畅区间的权重。虽然我们重点关注的可能是卡顿的地方,但是竞品测试,以及两个版本对比又需要有总体评判结果,不能只看局部。为了加大结果的区分度,对卡顿区间增加权重,对流畅区间降低权重。突出卡顿对整体评分的影响。因此,评估结果将包括两部分:总体打分以及卡顿区间,流畅区间的持续时间和打分。 

流畅度评估方法:

1. 预处理,每5个(秒)一组,取最低值。如果5秒内出现多于一次卡顿(SM低于40),则再乘以一个和卡顿次数有关的权值(小于1)。说明:如果卡顿出现次数较少,平均值和方差不容易发现问题。因此没有直接对数据评估,先进行了预处理,突出SM值低的部分,加大卡顿对总分的影响。

处理前三组数据:


处理后三组数据:


2. 将处理后的数据按卡顿和流畅分段,针对每段打分。说明:如果只有最后总分,且流畅的时间较长,卡顿的数据容易被流畅的数据淹没。而且有些测试场景存在一段流畅,一段卡顿的现象,卡顿并不一定在整个测试过程中存在。这样分开流畅和卡顿的区间处 理,更容易看出卡顿的程度。

3. 根据测试经验,对SM值对应的卡顿严重程度打分。说明:根据测试同学的经验,流畅度指标SM低于40时,用户能感知到卡顿,SM在20以下卡顿比较严重。因此在打分时,SM值在20以下时打分最低,对应0-20,在20-30区间打分低,对应20-60,30-40区间打 分较低,对应60-70,40以上打分在70以上。

4. 总体打分时降低流畅区间的权重。说明:这样处理的原因和第一项的原因一样,我们更关注的是卡顿,流畅区间过长时会淹没卡顿的数据。

然后我们拿同一个测试场景下的测试数据出来对比一下:

1)网页滑动(Nexus 4上测试):

测试方法:打开某网站,来回上下滑动,在滑动的过程中记录流畅度数据。


流畅度评估数据:



从上面的数据可以看出滑动浏览网页的时候,其中c浏览器略微好于其他两个。当然这都是在性能比较好的手机(N4)上测试主观感受差距不大但是从量化数据上可以看出优劣。评分差距就和主观感受拉开分值差不多能对应上,从客观上可以证明这套评分算法某种程度上的准确性。


作者简介:

叶方正 2008年加入腾讯,目前就职于无线研发部专项评测组。曾在微博、手机QQ、浏览器等项目组负责性能优化工作,积累大量的移动终端平台优化以及评测经验,邮箱地址:Michaelye#tencent.com(请把#改成@)。


CSDN移动将持续为您优选移动开发的精华内容,共同探讨移动开发的技术热点话题,涵盖移动应用、开发工具、移动游戏及引擎、智能硬件、物联网等方方面面,如果您有想分享的技术、观点,可通过电子邮件(tangxy#csdn.net,请把#改成@)投稿。

第一时间掌握最新移动开发相关信息和技术,请关注mobilehub公众微信号(ID: mobilehub)。


  • CSDN官方微信
  • 扫描二维码,向CSDN吐槽
  • 微信号:CSDNnews
程序员移动端订阅下载

微博关注

相关热门文章