【MIG专项测试组】如何量化Android应用的“卡”？---流畅度原理&定义篇

MIG专项测试组

致力于为腾讯移动互联网事业群(MIG)提供专项评测及深度优化（性能、功能、安全等）；同时负责探索新的测试理论和方法，研发评测工具及基础组件。

背景

在手机App竞争越来越激烈的今天，Android App的各项性能，如CPU、内存消耗等都有了客观的衡量指标。但对于App使用过程是否流畅，一直没有一个可靠的指标将用户的客观感受和数据一一对应。虽然之前有FPS(每秒帧数)作为游戏或视频类App的性能指标，但对于那些界面更新不多的App来说，仍不是一个合适的衡量数据。

应QQ浏览器业务团队需求（要做最快的浏览器同时，也要做最流畅的浏览器），MIG专项测试组开始着手研究Android自身UI更新机制，并通过数学建模，逐步摸索出一个客观数据指标SM(SMoothness)，用来量化流畅度。

原理分析

在确定衡量指标之前，我们先来研究一下Android的UI更新机制。

1、Android如何绘制UI？

关于Android是如何更新UI，相信已经有很多文章介绍其中的步骤以及过程，大体上可以用下图来展示:

从图中可以看到无论那条路走下去始终都由SurfaceFlinger来控制最后的更新。

在Android版本更新过程中，发现在Jelly Bean中Google加入了一个Project Butter，用来解决严重影响Android口碑的问题之一“UI流畅性差”的问题。而ProjectButter中主要引入了三个核心元素：VSYNC(垂直同步)、Triple Buffer和Choreographer。

2、从VSYNC开始

VSync是VerticalSynchronization(垂直同步)的缩写，是一种在PC上很早就广泛使用的技术，可以简单的把它认为是一种定时中断。而在Android 4.1(JB)中已经开始引入VSync机制。

上图所示是VSync机制下的绘制过程。从上图可以看出，CPU和GPU的处理时间都少于一个VSync的间隔，即16.6ms。如果每个间隔都有绘制的情况下，当前的FPS即为60帧。

当CPU和GPU处理时间都很慢，或因为其他的原因，如在主线程中干活太多，那么就会出现如下图这样的状况。

从上图可以看到，CPU和GPU的处理时间因为各种原因都大于一个VSync的间隔（16.6ms），所以在第二个VSync还在处理A区域的绘制时，不可能实现理论上的FPS60，同时也出现了丢帧(SF: Skipped Frame)情况。

为了便于理解，上图用的是双Buffer机制的情况，实际上Android 4.1引入了Triple Buffer，所以当双Buffer不够用时，Triple Buffer丢帧的情况如下图所示。

Oh my ladygaga！

这些都把洒家看晕了！那打个比方讲得通俗点吧！

VSync机制就像是一台转速固定的发动机(60转/s)。每一转会带动着去做一些UI相关的事情，但不是每一转都会有工作去做(就像有时在空挡，有时在D档)。有时候因为各种阻力某一圈工作量比较重超过了16.6ms，那么这台发动机这秒内就不是60转了，当然也有可能被其他因素影响，比如给油不足(主线程里干的活太多)等等，就会出现转速降低的状况。我们把这个转速叫做流畅度。

3、从FPS&丢帧到流畅度(SM: SMoothness)

实际上在很多Android的App中，很少有需要不断地去绘制的场景，很多时候页面都是静态的。也就是会出现这样的状况，虽然1s中VSync的60个Loop不是每个都在做绘制的工作，FPS会比较低，但并不代表这个时候程序不流畅(如我将App放着不动，实测FPS为1)。所以FPS较低并不能代表当前App在UI上界面不流畅，而1s内VSync这个Loop运行了多少次更加能说明当前App的流畅程度。所以，下面这2个指标比FPS更能代表当前的App是否处于流畅的状态。同样这2个指标更加能够量化App卡顿的程度：

·        丢帧(SF: Skipped Frame)：如上图2所示情况应该在16.6ms完成工作却因各种原因没做完，占了后n个16.6ms的时间，相当于丢了n帧。

·        流畅度(SM: SMoothness)：和丢帧相对，在VSync机制中1s内Loop运行的次数。

1） 和丢帧相对1s内有60个Loop因为某几次工作时间超过了16.6ms（丢帧），这样Loop就无法运行60次（理论最大值）；

2） 当流畅度越小的时候说明当前程序越卡顿。

4、数数：如何得到流畅度(SM:SMoothness)

接着上面的结论，如果在这样的机制下每次Loop运行之前进行通知，记个数就好了。

很幸运我们在新的Android的那一套机制中找到了一个画图的打杂工Choreographer这个对象。根据Google的官方API文档描述中，它是用来协调animations、input以及drawing时序的，并且每个Loop共用一个Choreographer对象。

下图为Choreographer的定义和结构。

结论

通过如上原理分析可以得出结论：

1. Android 4.1引入了VSync机制后，可以通过其Loop来了解当前App最高绘制能力。

·        固定每隔16.6ms执行一次(这个值是一个静态变量，会根据系统版本不同而采用不同的值，目前测试版本是16.6ms这样最高的刷新的帧率就控制在60FPS以内)；

·        如果没有以上事件的时候同样也会运行这样一个Loop；

·        这个Loop在1s之内运行了多少次，即可以表示当前App绘制的最高的能力，也就是Android App卡顿的程度；

·        另外，在一次Loop时如果执行时间超过了16.6ms，那么用多于16.6ms的时间除以16.6ms，即是当前App的丢帧(SF:Skipped Frame)。

2. 可以在Choreographer的回调FrameCallback中，按秒计数表示当前App的流畅程度，即流畅度SM(SMoothness)。

采用这样方式就可以在App内部观测当前App的流畅度了。

小编有话说

作为专业的质量跟踪平台，除了移动终端各种崩溃问题的分析，腾讯Bugly还将陆续跟大家分享鹅厂的移动质量之道，更有效地跟踪移动应用的质量！

本文属于【MIG专项测试组】开篇文，后续还会继续跟大家分享关于流畅度的测试验证数学建模评分等方法，欢迎大家关注！

不总结哪来经验，不分享经验何用？

同时小编也号召大家多总结，互分享，踊跃给我们投稿，把自己踩过并爬出来的坑树个指示牌警醒后人，让猿们的开发生活更加美好！

投稿方式：将文章和个人介绍邮件到 bugly@tencent.com，字数不限。

本文系腾讯Bugly特邀文章，转载请注明作者和出处“腾讯Bugly(http://bugly.qq.com)”