AWS：用于测量用户体验的Android工作负载套件

 

(本文为作者李晓峰原创，英文版原文发表在 http://software.intel.com/en-us/articles/aws-android-workload-suite-for-user-interaction-measurement/)

摘要

用户体验评估不同于传统的性能评估。许多性能基准的得分不能描述真实的用户体验，因为它们仅仅测量了系统的稳定状态。用户交互通常涉及到系统状态转变。本文中，我们将介绍 Android工作负载套件 (AWS)。该套件包含一系列 Android 工作负载，用于将用户交互映射到系统行为，然后使用软件堆栈指标来测量交互场景。我们期望 AWS 能够反映Android 客户端设备的典型用途，并可用于评估和验证性能、功耗和用户体验方面的 Android 优化。

客户端设备的用户交互场景

要系统地评估客户端设备的用户体验，我们需要使用一系列标准工作负载来代表典型使用场景并将指标值返回给用户。要构建一个这样的工作负载套件，我们需要执行以下步骤：

1.       确定典型使用场景

2.       将用户行为映射到系统软件操作

3.       构建工作负载

为了确定用户交互场景，我们调查了广泛的可用材料，包括来自行业主要厂商的公共文档、来自市场的常见应用、来自发运设备 (shipping devices) 的内嵌应用，以及平板电脑和智能手机的外形使用 (form-factor usages)。我们还调查了用户交互生命周期和 Android 源代码的软件设计。我们将客户端用途分为四类，如图 1 所示。对于综合型工作负载套件，这四类用途很重要。

 

 

图 1. 客户端设备用途分类

根据系统计算性质，所有使用模式均包含多个使用场景。例如，浏览器使用生命周期的使用场景可以用图 2 中的状态转变图表来表示。

注意此浏览器交互生命周期不包含 HTML5 技术，但是包含常见的一般浏览技术。否则，这些场景应当仅限于在 HTML5 中开发的具体web 应用。

 

图 2. 浏览器使用场景

客户端使用模式中的所有场景大致可分为以下三类场景：

• 用户操作。
       此类场景主要包括常见的交互场景，如浏览、游戏、编写、设置和配置等。此类场景中触摸屏和传感器为主要的输入设备。此类场景还包括 I/O 和通信场景。
• 加载和渲染。
       此类场景主要包括系统计算场景，如浏览器加载网页、打开电子文档和在图库中查看图像等。渲染场景包括 HTML5 渲染、媒体渲染、图形渲染等，通常是加载场景的一部分，有时被视作加载流程之后的一个单独场景。
• 任务管理。
       前两类场景包括常见的应用场景。最后一类场景包含应用管理场景，如应用启动、任务切换、通知警告、来电和多任务管理。.

每种场景均可能显示系统中的特定行为，因此需要采用特定指标来测量。我们认为对于用户体验而言非常重要的主要指标可分为两类，其中每类包含两大测量领域。

1.       用户对设备的控制性。这一方面主要涉及两个测量领域。

a.       准确性/模糊性。用于评估对于来自触摸屏、传感器和其它来源设备的输入，系统支持的准确性、模糊性、分辨率和范围。例如，系统支持多少个压力级，采样触摸事件坐标与指尖在屏幕上的移动轨迹有多接近，以及同一时间可对多少个手指进行采样等。

b.       一致性。用于评估屏幕中指尖与拖放图形目标之间的拖放滞积距离。它还可用于评估用户操作与感应式对象之间的一致性，例如，倾斜受控的水流与设备倾斜角之间的角度差。

2.       设备对用户的响应性。这一方面也涉及两个测量领域：

c.       响应性。用于评估将输入提交至设备与设备作出明显响应之间的时间。它还包括完成一次操作所花费的时间。

d.       顺畅度。这一测量领域利用最大帧时间、帧时间差异、FPS 和丢帧率等指标来评估图形转换顺畅度。如前所述，仅凭 FPS 一项指标无法判断与顺畅度有关的所有用户体验。

基于上述方法，我们可以利用图 3 中所示的每种场景的测量领域对浏览器交互生命周期进行改进。

 

图 3. 浏览器在每种场景中各个测量领域的使用场景

为了使工作负载套件对于平板电脑和智能手机均具有代表性，我们调查了平板电脑和智能手机的用途差异。毫无疑问，两者之间的主要差别在于它们的尺寸。智能手机通常用作便捷的小工具（如瑞士军刀），提供以下特性：

• 电话，语音和视频电话
• 音乐播放器，用于播放音乐和播客
• 照相机，用于拍摄照片和视频、扫描条形码、脸部识别
• 导航，包含 GPS、AGPS 和指南针等
• 通讯工具，用于文本和多媒体聊天
• 书籍/新闻阅读器
• 其它工具，如手电筒和夜视镜等。

在应用设计方面，智能手机应用用于配合较小的屏幕尺寸。许多智能手机游戏为漫画风格，并包含轻量级动画。游戏中的传感器控件通常很简单，且许多基于加速计。智能手机游戏更多地利用“摇动”进行控制，因为用手摇动电话非常容易。相比之下，平板电脑游戏更常利用陀螺仪传感器，通过慢速“倾斜”实现控制。除了传感器用途差别之外，带有较大屏幕的平板电脑还具有以下附加特性：

• 更逼真的图形和动作查看体验
• 通过触摸屏/传感器进行控制的控件更简单或更多，如游戏中的虚拟控制器、富文本编辑器和手写
• 更大的空间，可用于存放更多新闻、培训和电子书等内容
• 支持多余一个人玩游戏和参加交互式培训
• 在浏览器和其它信息门户（如 RSS 阅读器）上获得电脑一般的网络访问体验
• 用户桌面上具有更多日常使用的小型工具应用，访问起来很便捷。相比之下，智能手机更常在用户的口袋中使用

由于智能手机和平板电脑之间的差别，在一种外形下具有代表性的某些场景在另一种外形下可能并不具有代表性。例如，智能手机通常带有状态栏，而平板电脑则使用系统栏。智能手机中的浏览器应用通常在打开一个新的网页时会切换窗口，而平板电脑则通常在新的选项卡中打开新网页。

同时，有些场景在两种外形上均存在，但采用的设计元素却各不相同。例如，与智能手机中的2D 游戏相比，平板电脑中的 2D 游戏具有更多的动画精灵。平板电脑中的浏览器可加载 PC 网页，而智能手机则使用移动网页。

构建用于评估 Android 用户交互的工作负载

确定了使用场景和测量领域后，我们即可构建工作负载以反映这些有趣的场景和测量用户体验。

在真正开发工作负载之前，我们应当了解工作负载与工具之间的关系。工作负载用于描述系统的典型使用模式，而工具则用于分析系统行为。工具本身并不代表设备的一种使用案例，而是用于分析该使用案例。同时，可将多个工作负载的共同部分抽象为一个工具，以便在这些工作负载中重复使用。下图显示了各种不同的工作负载。

图 4 的上半部分显示了 Android 系统中的常见用户交互场景。“输入”触发了“活动 1”的执行，“活动 1”反过来又调用“服务 1”。然后，“服务 1”与“服务 2”通信，启动“活动 2”。“输出”提取自“活动 2”。

图 4 的下半部分显示了我们测量系统的四种情况。

• 独立工作负载。可在无需用户输入的情况下作为完整的工作负载运行，并在执行结束时输出结果
• 微工作负载。仅包含     (tresses) 堆栈的特定执行路径，不是平台的完整应用
• 测量工具。支持工程师提供输入，然后返回指标结果。它实际上是一种能够处理不同输入的工具
• 内嵌应用的场景驱动程序。为触发器提供输入，并从内嵌应用中提取输出。下面将提供一种使用场景，旨在为不同的设备提供标准输入，以便测量它们的浏览器用户体验

 

图 4. 工作负载和工具套件之间的关系

我们为评估 Android 用户体验而构建的工作负载涵盖以上用作不同用途的全部四种工作负载类型。通常，我们期望最终的工作负载套件包含第 1 种和第4 种工作负载，这是因为第 1 种工作负载可方便地用于白盒调查，第 4 种工作负载可作为黑盒来研究不同设备。

确定工作负载及其场景后，我们需要深入了解每种场景的 Android 软件堆栈，然后针对每种场景选择合适的指标。

由于我们的目的是为工程师评估和优化 Android 用户体验提供工程工具，因此我们期望我们的评估方法具有客观性。为此，我们为用户体验测量设置了以下标准。

• 可感知。该指标必须由人类感知，否则，该指标与用户体验无关。
• 可测量。该指标应当有不同的组来测量。该指标不能采用只能由特定组测量的特殊基础设施。
• 可重复。测量结果应当能够在不同次测量中重复。不同次测量结果中如果发生较大差异，则意味着该指标不是一个好指标。.
• 可比较。测量出来的数据应当能够在不同的系统中进行比较。软件工程师能够利用此指标来比较不同的系统。
• 合理。该指标应当有助于分析特定软件堆栈行为的起因。换言之，该指标应当能够映射到软件行为，并能够通过执行软件堆栈计算出来。
• 可验证。该指标可用于验证优化。优化前后的测量结果应当能够反映出用户体验的变化。
• 自动。出于软件工程的目的，我们期望该指标能够在几乎无人值守的情况下进行测量。这对于回归测试或预提交测试非常有用。不过，该指标并非硬性要求，因为它并不与用户体验分析和优化直接相关。

下面以视频播放评估为例进行说明。传统的性能基准仅通过诸如 FPS（每秒帧数）或丢帧率等指标来测量视频播放性能。这种方法在评估用户体验时至少存在两个问题。第一个问题是视频播放仅仅是播放视频过程中用户交互的一部分。用户交互的典型生命周期通常至少包括以下环节：“启动播放器”→ “开始播放” → “搜索进度” → “视频播放”→ “返回主屏幕”，如图 5 所示。 但是，仅凭视频播放的良好性能不能描述视频播放过程中的真实用户体验。用户交互评估是传统性能评估的一个超集。另一个问题是 FPS 不足以评估视频播放的顺畅度。下一节中，我们将利用一个案例研究来描述工作负载构建中的常见挑战。

 

图 5. 视频播放工作负载的使用场景

 

工作负载构建案例研究

下面，我们将利用在浏览器中滚动页面的场景来讨论工作负载构建过程。图 6 显示了在浏览器中自上而下滚动页面时产生的用户交互。

 

图 6. 在浏览器中滚动页面时产生的用户交互

如图 6 所示，在 T0 时间时，手指按在屏幕上并开始从 P0 位置滚动页面。当手指在 T1 时间到达P1 位置时，页面内容开始在手指滚动后开始移动。当页面内容在 T2 时间到达 P1 位置时，手指已移到P2 位置。也就是说，在手指移动期间，页面内容和手指之间存在滞积距离。在T3 时间时，手指离开屏幕，页面内容最终到达手指离开时的相同位置。

在这种场景下，我们选择对以下三个方面进行测量：

• 响应时间 –     在响应手指滚动这一操作时内容开始移动的速度
• 滞积距离 –     内容移动滞后于手指滚动的距离
• 顺畅度 –     手指在浏览器上滚动时浏览器显示页面的顺畅度

要测量响应时间，我们需要了解页面滚动的软件内部构件。滚动过程如图 7 所示。

 

图 7. 用于滚动的 Android 软件堆栈内部构件

图 7 包含三行，分别用于输入原始事件、浏览器事件和浏览器绘制。屏幕触摸传感器检测到触摸操作，向系统生成原始事件。收到原始事件后，框架将这些事件转变成移动事件，如 ACTION_DOWN、ACTION_UP和 ACTION_MOVE。每个事件均包含相关的坐标对 (X, Y)。浏览器计算出当前移动事件与开始位置（ACTION_DOWN 事件的坐标）之间的距离。如果该距离达到平台指定的阈值，则浏览器会将此移动事件视作滚动手势的一部分，并开始相应地滚动页面内容。通过利用屏幕上已经移动的位置，浏览器绘制新帧，滚动页面内容。随后，用户即可看到页面内容持续滚动。

图 8 显示了我们如何测量浏览器对于滚动的响应速度。浏览器对于滚动的响应时间指的是从发送第一次原始事件到绘制第一个滚动帧之间的时间。

 

图 8. 浏览器滚动响应时间测量

为了测量页面滚动的顺畅度，我们记录了绘制滚动帧时所有滚动帧的时间，如图9 所示。然后，我们计算出最大帧时间、长于 30 毫秒的帧的数量、FPS 以及帧时间差异来表示顺畅度。

 

图 9. 浏览器滚动顺畅度测量

顺畅度测量的复杂之处在于确定哪些帧为滚动帧。确定第一个帧很容易。确定最后一个帧则不简单。当手指离开屏幕时，由于存在滚动惯性（即使手指移动非常慢），有些帧仍在绘制。我们可以利用释放手指之前的帧或利用真正的最后一个帧（当浏览器重新渲染页面时）来计算最后一个帧。基于释放手指之前的顺畅度情况足以反映整个滚动过程的顺畅度这一假设，我们选择了前一种方法以简化设计。

为了测量指尖和页面内容之间的滞积距离，我们记录了所有原始事件和绘制帧的坐标值和时间戳。我们可以计算出一个帧与绘制该帧之前发生的事件之间的最大距离。我们将其表示为 frame k 的Distance[k]。然后，针对整个滚动过程，我们计算出滞积距离，作为所有帧的最大Distance[k]。图 10 对这一方法进行了说明。

 

图 10. 浏览器滚动滞积距离测量

为了使测量具有可重复性，我们使用 Android UXtune* 工具套件来生成标准输入手势。

为了实现不同的目的，我们采用了针对浏览器滚动测量而开发的两种版本。一种版本是独立工作负载，包含一个与场景驱动程序一起封装在工作负载中的浏览器，用于触发自动执行和测量。另一个版本仅包含用于触发设备内嵌浏览器执行测量的场景驱动程序。前者可用于比较不同设备的 Android 框架，而后者则主要用于比较不同的设备内嵌浏览器。

Android 工作负载套件 (AWS) 和用户体验优化

基于前面几节所述的方法，我们开发出 Android 工作负载套件(AWS)，用于推动和验证 Android 用户体验优化。

表 1显示了 AWS 2.0 工作负载。使用案例基于我们对移动设备行业、市场应用和用户反馈的广泛调查选出。

表 1. Android 工作负载套件 (AWS) v2.0



我们已经确立了一个系统的 Android 用户体验优化方法。它包括以下步骤。

步骤 1. 从用户处接收用户体验观测信息/问题，或者通过手动操作或工作负载评估发现交互问题

步骤 2. 确定将用户体验问题转化成为软件症状的软件堆栈场景和指标

步骤 3. 开发软件工作负载，以可测量和可重复的方式重现问题。该工作负载能够报告反映用户体验问题的指标值

步骤 4. 利用工作负载和相关工具来分析和优化软件堆栈。该工作负载还可对优化进行验证

步骤 5. 从用户处获得反馈并将优化应用于更多应用，以便确认用户体验得到提升。

对于步骤 3，我们主要采用Android 工作负载套件 (AWS)。对于步骤 4，我们已经开发出Android UXtune 工具套件，用于帮助分析软件堆栈中的用户交互。

目前，AWS 正在基于用户反馈和 Android 平台的改变而不断发展。

其它资源

以下在线公共网站提供了有关用户交互和体验的有用信息：

• http://ux.stackexchange.com/
• http://www.useit.com/papers/responsetime.html
• http://www.measuringux.com/

致谢

作者在开发优化 Android 用户体验的方法时曾受到同事 Greg Zhu 和Ke Chen 的大力支持。作者在此表示衷心感谢。

作者简介

Xiao-Feng Li 是英特尔公司软件和服务事业部系统优化技术中心的软件架构师。Xiao-Feng 在并行软件设计和运行时技术领域具有丰富的经验。Xiao-Feng 于2001 年加盟英特尔，在此之前他是诺基亚研究中心的一名经理。闲暇时间里，Xiao-Feng喜欢滑冰和中国书法。

User experience evaluation is different from traditional performance evaluation. Thescores of many performance benchmarks are not able to tell of real userexperience, because they only measure the steady state of the system. Userinteractions usually involve system state transitions. In this document, weintroduce Android Workload Suite (AWS), which includes a set of Androidworkloads to map user interaction to system behavior, and then use softwarestack metrics to measure the interaction scenarios. We expect AWS to reflectthe representative usage of Android client devices, and to be used to evaluateand validate Android optimizations in performance, power and user experience.