This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
英特尔® 技术期刊 | 2012 年,第 4 期,第 16 卷
移动操作系统架构的趋势
作者
Xiao-Feng Li英特尔软件与服务事业部
Yong Wang英特尔软件与服务事业部
Jackie Wu英特尔软件与服务事业部
Kerry Jiang英特尔软件与服务事业部
Bing Wei Liu英特尔软件与服务事业部
世界是平的,因为它正变得日益移动化,越来越快速、互联和安全。人们
期望携带自己的移动设备自由移动,同时与他们的合作伙伴和家人保持密
切的沟通,享受灵活多变的使用模型和多种多样的内容,而无需担心设备
和数据管理。所有这些都对移动设备提出了要求,而移动操作系统是移动
设备的灵魂。基于我们在移动操作系统设计上的多年经验,和对当前行业
形势的广泛调查,我们相信未来的移动操作系统架构中存在一些共同特征,
比如用户体验、电源管理、安全设计、云支持和开放性设计。我们开发了
一个分析模型来指导我们的调查。本文中,将介绍我们对移动操作系统架
构未来十年趋势的调查情况,重点关注主要的共同特征。基于调查结果,
我们还会从架构趋势的角度总结当今移动操作系统的特征。
引言
移动操作系统设计在过去十年中经历了三个阶段的演化过程:从基于 PC 的
操作系统发展到嵌入式操作系统,再到如今面向智能手机的操作系统。在
整个演化过程中,移动操作系统架构从复杂变得简单,再到介于二者之间。
这个演化过程受硬件、软件和互联网技术进步的自然推动:
• 硬件。业界在不断缩小微处理器和外围设备的尺寸,以设计真正的移动
设备。在尺寸足够小之前,移动设备无法同时兼顾小尺寸和高处理能力。
我们或者拥有一个 PC 大小的笔记本电脑,或者拥有一个电话大小的性
能弱得多的 PDA(personal data assistant,个人数据助理)。PDA 的移
动操作系统通常没有完整的多任务或 3D 图形支持。过去的移动操作系
统不支持像传感器(比如加速计)和电容式触摸屏这样的特性。
• 软件。在笔记本电脑中,软件主要专注用户的生产力,支持键盘和鼠标,
拥有精确的输入必不可少。正如设备名称所暗示的,用于 PDA 的软件
可以帮助用户管理个人数据,比如联系人信息、电子邮件等。移动操作
系统并非设计用于支持包含触摸屏和其他传感器的富用户界面 (UI) 并为
其提供良好的响应能力或流畅性。
• 互联网。随着互联网的发展,尤其自 Web 2.0 诞生之后,网络中拥有丰
富的信息,等待人们去搜索、整理、挖掘并带给用户。人们的生活越来
越离不开互联网,他们不再只是浏览网页。越来越多的人参与到开发之
中,包括信息贡献、应用程序开发和社交。移动操作系统无法自给自足,
必须是开放的系统。
过去的移动设备的使用模型很有限。用户主要运行设备应用程序来进行数
据管理和玩本地游戏,只偶尔浏览互联网上的静态网页,或访问电子邮件
1 | 移动操作系统架构的趋势
移动操作系统架构的趋势 | 2
等特定服务。换句话说,设备的可能用途取决于在用户购买它时预先安装
的应用程序。这在新移动设备中发生了巨大变化,新移动设备几乎是各种
使用模型的一个入口。所有参与方,比如服务提供商、应用程序开发人员
和其他设备用户,不断在做出贡献,并通过设备与其所有者互动。图 1 显
示了过去的移动设备与新移动设备之间的高级使用模型的区别。
英特尔® 技术期刊 | 2012 年,第 4 期,第 16 卷
图 1:移动设备的高级使用模型(来源:英特尔公司,2012 年)
当前的移动操作系统的代表包括苹果的 iOS* 5.0、Google Android* 4.0、
Microsoft Windows* Phone 7.0 和其他一些操作系统。在使用模型方面,除
了区别之外,它们还具有更多的相似性:
• 它们都有一个已备案的软件开发工具包 (SDK),其中包含定义良好的
API,让普通开发人员能够为这些系统开发应用程序。
• 它们都拥有在线应用商店,可供开发人员发布应用程序并允许用户对
程序进行下载,比如苹果的 App Store、Google Play 和 Windows Phone
Marketplace。
• 它们都在一定程度上提供了多任务和 3D 图形支持。触摸屏和传感器很
容易使用。它们都投入了大量心血来使用户交互变得更加流畅和灵敏。
• 浏览体验不再仅限静态网页。HTML5 正成为默认标准,以运行基于
Web 的应用程序。
• 所有这些操作系统都支持基于设备的支付。再加上企业应用程序和隐私
信息,系统安全性始终是设备用户担忧的一个重要问题。
• 作为移动操作系统,与非移动操作系统的一个重要的设计区别在于对电
池寿命的关注。这些系统尽力减少设备组件的有源电力消耗,尽可能让
它们处于空闲状态。
当前移动操作系统的共性反映了硬件、软件和互联网的发展趋势。因为预
3 | 移动操作系统架构的趋势
料到移动操作系统的这些趋势,我们相信以下领域是下一代移动操作系统
设计的重点,包括用户体验、电池寿命、云就绪性、安全性和开放性。在
很大程度上,它们实际上是相互冲突的目标:
• 用户体验和电池寿命。要获得最佳的响应能力和流畅性,系统要求所有
可用的硬件资源都能够发挥它们的最佳性能。与此同时,为了维持移动
设备的电池寿命,硬件组件应尽可能处于空闲状态。
• 安全性和开放性。人们不希望向外部实体公开其系统的所有功能,因为
这会使系统处于安全威胁之下。另一方面,如果不能公开足够多的系统
API,开发人员无法创造革新的用途。
• 云就绪性。随着云计算提供的服务和应用程序越来越多,人们自然会想
到一种瘦客户端设备模型,信任云,并分载计算到云平台。但时至今日,
瘦客户端模型在用户体验和安全性上仍然面临技术挑战。
在本文中,我们尝试分析移动操作系统设计的各个方面,并总结出我们对
于移动操作系统架构未来发展趋势的观点。
本文安排如下。基于本节中给出的框架,我们使用独立的章节来讨论下面
给出的各个主体。具体章节分为用户体验、电源管理、安全性、开放性和
云就绪性。最后,我们展开讨论并进行总结。
用户体验 (UX)
传统的性能不足以描述现代客户端设备的特征。性能更多的是指软件栈的
稳定执行状态,而且通常会使用处理器或其他子系统中的总吞吐量的最终
分数来报告性能。用户体验更多的是指由用户输入所触发的动态转换。用
户体验的质量取决于许多因素,比如用户可感知的响应速度、流畅性、连
贯性和准确性。传统性能可度量用户交互链中的每一个环节,而它无法评
估完整的用户交互链。因此,传统的性能优化方法无法简单地应用于用户
体验优化。现在是时候投资于设备的用户交互优化,为最终用户带来愉悦
的体验。
用户与移动设备的交互
在近期面对市面上一些 Android 设备进行性能测试的过程中,我们发现在
对图形、媒体和浏览器进行的通用基准测试,设备 X 的表现普遍比另一种
设备 Y 更差一些。但设备 X 的用户可感知体验却优于设备 Y。我们认为此
问题的根源在于,传统基准测试或以传统方式设计的基准测试没有真正反
映用户交互的特征,只是度量了系统和子系统的计算能力(比如执行的指令)
或吞吐量(比如处理的磁盘读取次数)。
以视频评估为例。传统的基准测试仅通过一些指标来度量视频回放性能,
比如 FPS(每秒帧数)或帧丢弃率。用此方法评估用户体验至少存在两个
问题。第一个问题是,视频回放只是播放视频过程中用户交互的一部分。
用户交互的一个典型的生命周期通常至少包含以下几个环节:“启动播放
器” “开始播放” “寻找进度” “视频回放” “返回到主屏幕”。
英特尔® 技术期刊 | 2012 年,第 4 期,第 16 卷
英特尔® 技术期刊 | 2012 年,第 4 期,第 16 卷
然而,视频回放的良好性能无法体现播放视频过程中真实用户体验的特征。
用户交互评估是传统性能评估的一个超集。
另一个问题是,使用 FPS 作为关键指标来评估用户交互的流畅性,不能始
终反映良好的用户体验。例如,当我们在 Gallery3D 应用中抛出一张图片时,
设备 Y 在图片滚动期间存在明显的停顿,但设备 Y 的 FPS 值比设备 X 更高。
为了量化两个设备的差别,我们收集了在设备 X 和设备 Y 上的 Gallery3D
应用中的一个图片抛扔操作中的每一帧的数据,分别如图 2 和图 3 所示。
每一帧的数据使用一条竖线表示,其中 X 轴是绘制该帧的时刻,竖线的高
度是系统绘制这幅帧所花的时间。我们可从图中看到,设备 X 显然具有比
设备 Y 更低的 FPS 值,但具有更小的最大帧时间,长于 30 毫秒的帧数更少,
而且帧时间波动更小。这意味着,要描述图片抛扔操作的用户体验的特征,
还应该考虑最大帧时间和帧时间波动等指标。
图 2:设备 X 上的 Gallery3D 应用中的抛扔操作的帧时间(来源:英特尔公司,2011 年)
图 3:设备 Y 上的 Gallery3D 应用中的抛扔操作的帧时间(来源:英特尔公司,2011 年)
移动操作系统架构的趋势 | 4
英特尔® 技术期刊 | 2012 年,第 4 期,第 16 卷
作为对比,图 4 显示了在我们优化了设备 Y 之后抛扔操作的帧数据。显然,
所有指标都已改进,并且帧的时间分布变得更加均匀。
用户体验更多是用户输入所触发系统的动态转换。良好的用户体验通过用
户可感知的响应速度、流畅性、连贯性和准确性来实现。传统性能可以度
量用户交互链中的每个环节,而不能评估整个用户交互链。
图 3:优化之后设备 Y 上的 Gallery3D 应用中的抛扔操作的帧时间(来源:英特尔公司,2011 年)
需要注意的另一个重要事项是,用户体验是一个主观过程;只需想想在观
看影片或欣赏音乐时的体验。目前的学术研究使用了多种方法(比如眼球
跟踪、心跳监视或者仅仅投票)来理解用户体验。出于我们的软件工程用途,
为了系统地分析和优化用户交互,我们将交互场景分为 4 类:
• 从用户、传感器、网络等向设备的输入。此类别会评估输入是否可以触
发设备按预期的方式进行准确或模糊的操作。对于触摸屏输入,它计量
触摸速度、压力、范围等。
• 设备对输入的响应。此类别会评估设备对输入的响应能力。
• 系统状态转换。此类别专门评估屏幕上图形转换的流畅度。它可作为设
备响应某些输入的后续。
• 对设备的连续控制。人们操作设备不仅会提供单一的输入,而且有时还
会控制屏幕中的图形对象,比如控制一个游戏喷气飞机,或者拖动一个
应用程序图标。此类别用于评估设备的可控性。
在这些类别中,“该设备的输入”和“对设备的控制”与用户如何控制设
备的用户体验相关。“设备对输入的响应”和“系统状态转换”与设备如
何对用户做出反映相关。我们可将一个用户交互的生命周期与属于上述类
别建立对应关系;然后,针对每个案例,我们可识别软件栈中的关键指标
来进行度量和优化。
5 | 移动操作系统架构的趋势
移动操作系统架构的趋势 | 6
英特尔® 技术期刊 | 2012 年,第 4 期,第 16 卷
用户交互优化
正如上一小节中所述,没有明确的客观方法来度量用户体验。我们在用户
交互度量中设定了以下标准:
• 可感知。指标必须可被人类感知。否则,它与用户体验是不相干的。
• 可度量。指标可以由不同团队进行测量。它不应依赖于只能由某些团队
测量的某些特殊的基础设施。
• 可重复。测试的结果应该能在不同测试中进行重复。测量中出现大的偏
差意味着不是一个好的指标。
• 可对比。度量的数据应可在不同系统之间进行对比。软件工程师可使用
这些指标对比不同的系统。
• 合理性。指标应有助于推断软件栈行为的因果关系。换句话说,指标应
与软件行为相对应,并可基于软件栈的执行进行计算。
• 可验证。可以使用指标来验证优化。优化之前和之后的度量结果应该能
够反映用户体验的变化。
• 可自动化。出于软件工程用途,我们要求指标能在大体上无人参与的情
况下进行度量。这在回归测试或预提交测试中特别有用。这条标准并不
严格要求,因为它与用户体验分析和优化没有直接关系。
以度量标准为引导,我们重点关注以下具互补性的用户体验:用户如何控
制设备以及设备如何对用户做出反应。用户如何控制设备主要有以下两个
测量范畴:
• 准确性 / 模糊性。该测量范畴评估了系统对来自屏幕、传感器和其他来
源的输入支持的准确性、模糊性、分辨率和范围。例如,系统能支持多
高的压力水平,抽样的触控事件坐标与指尖在屏幕上的移动轨迹能有多
接近,同时最多能抽样出多少个手指的操作,等等。
• 连贯性。该测量范畴评估了指尖与被拖动图形对象在屏幕中的拖动滞后
距离,还评估了用户操作与传感器控制的对象之间的连贯性,比如倾斜
控制的水流和设备斜角之间的角度差。
设备如何对用户做出反应有以下两个测量范畴:
• 响应速度。它评估输入传递到设备与设备显示可见响应之间的时间。它
还包括完成某项操作所花的时间。
• 流畅性。该范畴通过最大帧时间、帧时间波动、FPS 和帧丢弃率等来评
估图形转换的流畅性。正如我们所讨论过的,单独的 FPS 本身无法准
确反映用户体验的流畅度。
对于这 4 个测量范畴,当确定了一个要使用的具体指标后,我们需要理解
此指标与“好的”用户体验有何关联。因为用户体验是一个主观命题,很
大程度上取决于人类的生理状态和个人品味,所以在一个指标的哪些值能
构成“好的”用户体验方面并不总能得出科学的结论。对于这些情形,我
们采用的是行业经验值。表 1 提供了行业经验值的一些示例。
7 | 移动操作系统架构的趋势
英特尔® 技术期刊 | 2012 年,第 4 期,第 16 卷
表 1:用户体验的行业经验值的示例(来源:英特尔公司,2011 年)
由于人类的本性,在用户体验优化方面,软件工程师应注意以下两点。
指标的值通常在“好的”用户体验的范围内。比该范围“更好的”值不一
定会带来“更好的”用户体验。超出该范围限制的改进通常无法被用户感
知到。
这里的值仅是面向典型人群和常见情形的大致指导方针。例如,一位经验
丰富的游戏玩家可能无法满足于 120 fps 的动画。而另一方面,一个精心
设计的卡通影片可通过 20 fps 的动画提供完美的流畅性。
现在我们可为用户体验优化设定自己的方法。这些方法可概括为以下步骤。
第 1 步:从用户处收到用户体验观察报告或通过手动操作识别交互问题。
这可以在高速照相机或其他可用技术的帮助下完成。
第 2 步:定义能将用户体验问题转换为系统症状的软件栈场景和指标。
第 3 步:开发一个软件工作负载,以可度量和可重复的方式再现该问题。
该工作负载记录的度量标准值能反映用户体验的问题。
第 4 步:使用该工作负载和相关的工具分析和优化软件栈。该工作负载也
可以用来验证优化。
第 5 步:从用户那里获取反馈,使用该优化试用更多应用程序,以确保用
户体验的改进。
基于此方法,我们开发了一个 Android Workload Suite (AWS)[33],它包含一