在我们所有的“屏幕”之中,轻型通知的理念正变得日益普遍。起初,Windows 小工具能够提供这一类型的功能 — 迅速向您提供一些关键信息(如新闻、天气预报、体育比分或行业动态等)的提示性显示。然而这些小工具的启动时间与模式并不能很好地实现整体功耗降低(这对于台式计算机和便携式计算机较为重要),或为开发人员提供全屏幕平台。此外,Windows 8 的“开始”屏幕能够提供一个包含更多此类通知的更大界面,以及一个用于管理更新(包括网络资源使用)的用户控制界面。在现代用户体验中,越来越多的信息由推送获得,或存在于结构化的代码段中,这为开发人员和最终用户提供了一个独特的机会。本篇博文中,Ryan Haveson 将向您讲述 Metro 风格动态磁贴的开发过程,以及该体系结构在降低整体功耗与系统负载的同时,向更多数量磁贴扩展的方式。
–Steven Sinofsky

我们都知道性能与电池使用时间对于 Windows 的成功发布至关重要,用户在评论中也不断强调了这些属性。@KISSmakesmeSMILE 将其总结得非常到位:

“……试图达到,甚至超越……【竞争者的】电池在轻/低负载使用方面的运行时间效果。”

与此同时,我们知道所有现代环境(从 PC 到电视再到电话)中都有各种形式的小工具、小组件或插件模型,您可利用它们迅速一览各项消耗情况的信息。电视新闻、体育赛事或天气预报将显示一个结构化的信息屏,其中许多信息源实时汇集至一块。人们希望在开始手头工作之前,能够在数秒钟内迅速查询其股票、天气预报、电子邮件数量、下一次约会、业务状况,甚至包括社交网络的状态。在很多方面,有些人会提出相比其他设备,PC 在这一领域仍有许多地方需要改进。当我们着手设计通知基础结构时,我们所面临的挑战是应如何让 PC 包含活动且显得富有活力,同时又确保电源与带宽使用方面的高效性。@AndyCadley 所说的内容清晰地表达了这一目标:

“可以将所有 'Metro' 应用程序视为始终在运行,但又丝毫不会影响您的电池/性能”

“开始”屏幕可在不影响您正在使用的桌面或 Metro 风格应用程序的同时,为您提供一个全屏提示性显示,这种从用户模式的视角出发的做法让一切变得非常高效。此外,我们不仅仅希望提高其效率,还希望保证您可以在不必担心性能或电池使用时间受影响的前提下,安装任意数量的通知应用程序。

我们内部在使用 Windows 8 时注意到了一个现象,即面向业务线应用程序,将“开始”屏幕用作统一、高可读性的提示性显示可大幅提高生产效率。我们观察到很多用户对主要功能为通知的应用程序产生了浓厚的兴趣。借助我们全新推送通知平台的可扩展性,Windows 8 能够在最大程度降低对系统影响的前提下提供这一功能,这对于当今 Windows 中所存在的众多机制而言,是一个重大突破。这一现象并不罕见,特别是在早期,即使是那些仅使用台式计算机的“顽固分子”也将从“开始”屏幕中受益匪浅,因为“开始”屏幕可作为一个集中化的、显示(与控制)良好的通知区域,且仅需一次按键即可进入。

通知平台的目标

让数以百计的应用程序磁贴包含活动且充满活力,同时确保不会降低性能,这会让用户误认为这两个目标是背道而驰的。毕竟,“活动”,顾名思义需要消耗资源:从云获得通知需要使用网络,在磁贴中呈现通知需要使用 GPU/CPU 资源,等等。为了获得心仪的设计,我们知道必须紧扣我们最初的目标:

  • 在不影响性能的前提下启用数以百计的动态磁贴
  • 利用精美图像,而不仅仅是气球、徽章和文字
  • 为开发人员提供便利,因而他们能够“一劳永逸”
  • 实现实时传递,因此“即时信息”传递可在瞬间完成

基于这些目标,我们所做出首个基本结构决定是该平台应为数据驱动型平台,即后台中没有运行任何应用程序代码为“开始”屏幕提供支持。

谈及通知传递系统的具体结构,其包括以下几个部分:连接时的逻辑、身份验证、本地缓存、呈现、错误处理、回退算法、限制等。此外,该系统需要处理服务方面的问题,例如您何时处于连接或未连接状态,进而缓存未传递的内容,并处理复杂情形以便重试。您能想象每个包含动态磁贴的应用程序都拥有其自身的客户端/服务器代码吗?不仅将在每次执行过程中遇到不同的错误,而且对于内存中所加载的每个应用程序,您将遇到代码实质相同的副本,其代码将被不断分页进入和脱离磁盘。这一过程将非常低效,因为它意味着您所有的应用程序时刻处于运行状态,而您的“开始”屏幕也一直处于活动状态。即使对于内存较大的计算机而言,其系统性能最终也将不断遭受“侵蚀”。

如果您阅读过 Bill Karagounis 减少 Windows 8 中的运行时内存的博文,那么您一定了解,当您增加运行中进程、DLL、服务的数量时,性能将有所降低。如果每个动态磁贴均以其自有的代码运行,那么我们将无法实现我们的首要目标 — 在不降低性能的前提下启用数以百计的动态磁贴。

我们的解决方案是构建一个数据驱动型的模型。这意味着开发人员可以使用一套预定义的属性和模板(本例中为使用一个 XML 架构)来呈现其磁贴。XML 磁贴数据随后将由一个简单的 HTTP POST 而被发送至 Windows 推送通知服务 (WNS),之后我们将处理余下步骤。用于连接、重试、身份验证、缓存、呈现、错误处理等活动的所有代码将以一种统一、节能的方式完成。

以下显示了众多磁贴模板中的一个例子,开发人员可将其运用于 Windows 8 应用程序。该磁贴由文本字段和一个单一图像构成,但其提供了许多其他模板以供选择。

一位冲浪者的图像,并包含 RSS 源图标和文字 "First ever surfboard kickflip recorded in Santa Cruz"
图 1:模板示例 (TileWideImageAndText)

以下是用于描述上述磁贴相应的 XML 代码:

<?xml version="1.0" encoding="utf-8"?>
<tile>
<visual lang="en-US">
<binding template="TileWideImageAndText">
<image id="1" src="http://www.fabrikam.com/kickflip.png"/>
<text id="1">First ever surfboard kickflip recorded in Santa
Cruz</text>
</binding>
</visual>
</tile>

使用数据驱动型模型的决定让我们实现了前两个目标(性能与高保真的用户体验),但是我们仍希望解决实时传递和“一劳永逸”提高效率的问题。

在客户端/服务器的内容传递中有两个高级别的设计模式:轮询与推送。轮询是指客户端定期(如每隔 90 分钟)检查服务,以查看是否有新内容出现。推送是指当有新内容出现时,服务将直接把该数据发送至客户端。

利用轮询模式支持即时通知的唯一方式是以极高的频率(如每隔 5 秒)进行轮询,这样,一旦有新消息到达,您便可立即收到。但是这样将与我们的性能目标背道而驰 — 将轮询间隔设置为 5 秒会让网络无线通信堆栈始终无法空闲,电池使用时间也将大打折扣,而且台式计算机亦将始终处于通电状态。这与我们的手机有些类似,如果您整天使用手机通话,那么您手机电池的使用时间必定不长。最重要的是,让服务器每隔 5 秒检查一次新内容将产生极大的浪费,因为绝大多数情况下 5 秒内将不会收到任何新内容。在过去,Vista 所引入的系统任务栏通知和桌面小工具一直使用轮询机制而得以实施。但是在所有轮询机制中,其轮询间隔相对于当今瞬间更新的实时服务而言仍不够短。

因此,我们为 Windows 8 设计了一款基于推送的服务。这是一项重大决定,因为它意味着我们需要在全球范围内构建一个平台,并最终为成百上千的应用程序磁贴和十亿多人提供支持。但其价值不言而喻:开发人员可免费为其客户提供极为高效的实时通知,且无需构建或维护其与客户端的永久连接。

推送通知平台

让我们具体来看看该平台的几个组件,从而向您解释该设计中几个更微妙的部分。在以下图表中,您将看到三个关键实体:

  1. Windows 推送通知服务 (WNS):这可支持动态磁贴和提示通知。
  2. 应用程序服务:这是 Metro 风格应用程序(如从现有网站)所运行的 web 服务,该服务可通过 WNS 发送提示通知和磁贴更新。例如开发人员预览版中推出的天气预报应用程序后端服务,或社交网络应用程序中托管照片的后端服务。
  3. Windows 8 客户端平台:这代表了实际 PC 和操作系统中形成端到端用户体验管道的子组件。

三幅图表显示了:应用程序后端服务、Windows 推送通知服务 (WNS) (同时包括一个“缓存”)、Windows 8 客户端平台(同时包含“磁贴呈现器”、“图像缓存”和“WNS 连接”盒)。标注着“1.推送通知”的箭头是指从应用程序后端服务至 WNS 的方向。标注着“2.通知”的箭头是指从 WNS 至客户端平台 WNS 连接的方向。标注着“3.获取图像”的双向箭头是指应用程序后端服务和客户端平台中的图像缓存间的双向关系。
图 2:推送通知平台

让我们通过浏览一个典型的使用场景来说明其工作原理。假设该应用程序服务是一个社交网站,如果有人评论了您的照片,该服务便将发送一个磁贴更新(其简单程度与业务线应用程序类似,该程序将在我收到分配的缺陷或需要引起我注意的费用报告时向我更新)。当出现一个更新时,应用程序服务将向 WNS 发送一个通知(上述图表中的步骤 1)。在那里,WNS 将推送通知至客户端(步骤 2)。当需要在“开始”屏幕上显示磁贴更新时,操作系统将基于该通知 XML 中所包含的 URL 从应用程序服务中获取图像(步骤 3)。当通知和图像下载结束后,应用程序将基于 XML 中指定的模板显示动态磁贴,并将其呈现于“开始”屏幕中。

正如此前所述,我们的目标之一是实现“一劳永逸”。因此,为确保开发人员不必在 PC 未连接时(如一台休眠状态下的便携式计算机),编写复杂的缓存并重试各项机制,我们在 WNS 云中为每个应用程序缓存了一个通知,直至下次 PC 再次联机。

我们在设计客户端平台组件时,希望确保我们所设计的所有内容都具备高性能和低功耗的特点。其中一个关键部分便是将通知负载与图像负载分离。一个典型的通知 XML 通常是小于 1KB 的数据,但是一个图像却可高达 150KB。将通知与图像分离可让我们在包含大量重复图像的情形中大幅节省网络带宽。例如,某个磁贴的图像可能是您朋友的照片,而您的 PC 可以仅下载一次,然后在本地进行缓存,便于日后重复使用。将通知与图像分离可让我们在分析下载图像的“成本”之前放弃未使用的通知。当我在工作时,如果我的设备的屏幕已经关闭,并放于我的卧室,那么我的设备不会为磁贴下载图像,而是被我下次重新使用该设备之前的后续更新所取代。

身份验证模式

由于动态磁贴和通知代表了应用程序用户体验中的一个关键部分,因此确保通信通道(从应用程序服务至您“开始”屏幕上磁贴的所有方式)经过验证且安全可靠十分重要。如果一个应用程序或恶性网络服务恰巧能更新您计算机中的任意磁贴,那么后果将不堪设想。基于这个原因,我们使用了一个匿名身份验证机制,该机制能够识别出 PC 与 WNS 间的唯一连接。应用程序和应用程序服务在与 WNS 通信时同样可以验证身份。验证与 WNS 两项连接的身份有助于避免动态磁贴更新的不良行为(如欺骗攻击)。WNS 所使用的身份验证机制明确地将应用程序和服务连接至一起,其连接方式可避免其他应用程序(或恶意个人)向不属于自身的磁贴发送内容。当然,所有的通信均发生于一个安全可靠的通道内。

无论您是否使用 Windows Live ID 登录 Windows,所有这些工作均可照常完成。当然,正如 Katie Frigon 在其博文使用 Windows Live ID 登录 Windows 8 中所提到的一样,当您拥有一个连接帐户时,Windows 8 将堪称完美。因为您的帐户将为您提供一些列增强的用户体验,如应用程序云存储,漫游 Windows 与应用程序设置,以及单点登录多个应用程序等。由于推送通知平台使用了一个匿名的身份验证机制,因此,即便您使用 Windows Live ID 登录,应用程序的开发人员也无法使用通知管道识别出您的 Windows Live ID、系统信息或位置。

构建服务,以进行扩展

在本博客前面的内容中,我们提到了需要设计一个平台来支持数量庞大的用户和应用程序。为了让您理解其规模,以下图表显示了应用程序每天发送给 Windows 8 的通知数量。数周前,我们每天发送了大约 9000 万个磁贴更新,而目前我们甚至尚未推出试用版!

图表显示 2011 年 9 月 12 日的通知数量为 0,2011 年 9 月 16 日攀升至 6400 万,9 月 18 日回落至 3600 万,并在 10 月早期逐渐上升至 8000 万至 8500 万的范围。
图 3:每天发送至 Windows 8 开发人员预览版的通知数量

股票应用程序是开发人员预览版中一个热门的测试驱动应用程序。以下图表显示了自开发人员预览版发布以来的第一个月中该应用程序登记的动态磁贴总数。

股票应用程序动态磁贴总数
图 4:开发人员预览版股票应用程序中所登记的动态磁贴

开发人员预览版发布以后,我们便开始观测数据中心的流量变化,并密切监控我们的横向扩展。以下具体显示了 //build 发布开发人员预览版数天后通知的实际地理分布情况。请注意,这些数据显示了每平方英里中的单位数量,且其坐标刻度以对数形式进行了调整,以充分显示大范围内的密度值。


请下载此视频在您常用的媒体播放器中进行观看:
高质量 MP4 | 低质量 MP4

WNS 的设计是基于 Windows Live Messenger 服务体系结构而完成,事实上,该通知平台的服务部分是由同一团队构建而成。世界范围内,目前尚没有多少团队具备该专业技能和知识,构建一个全球可扩展的服务,并让其规模如此迅速地攀升至如此高的水平。以下为您提供了一些统计数据,让您了解 Windows Live Messenger 服务每天的规模:

  • 每月 3 亿名活动用户
  • 每天 6.3 亿次登录
  • 每天 100 亿项通知
  • 高峰时期 SOC (同时在线连接)超过 4000 万次
  • 超过 3000 台计算机在全球传递消息

通过任务管理器清晰了解磁贴资源使用情况

我们急切渴望了解通知平台的性能,因此我们在新的任务管理器中添加了几个指标,以追踪磁贴平台为每个应用程序而使用了多少带宽。总体来说,磁贴的资源使用率应该相对较低。各位中正在运行开发人员预览版的用户,请前往任务管理器的应用程序历史选项卡中查看“磁贴”列,以了解过去 30 天中您每个动态磁贴所使用的带宽情况。

从 2011 年 9 月 17 日至 2011 年 10 月 17 日 Metro 风格应用程序使用历史的热度地图。根据显示,“新闻”应用程序使用了 71.9 MB 网络流量,按流量计费的网络使用了 57.2 MB,但磁贴仅使用了 0.1 MB。任务管理器中一共列出了 18 个应用程序,在“磁贴”列中所有程序的使用量均显示为 0 或 0.1 MB。
图 5:显示于资源管理器应用程序历史中的动态磁贴资源使用情况

总结

在 Windows 8 中,我们正着手设计一个通知平台,利用该平台您可以迅速一览各项信息,且无需担心过去插件和基于小工具的模式所经常面临的性能和电池使用时间问题。为此,我们所决定的每一项设计方案均考虑了性能与电池使用时间问题。为方便应用程序开发人员参与,我们构建了 Windows 推送通知服务,因此开发人员可在不编写复杂的网络连接代码的前提下创建动态磁贴。此外,由于 WNS 使用了标准的 Web 技术,如 HTTP POST,因而开发人员可基于其现有网络服务轻松集成通知。

最终,我们推出了这样的一个通知平台,它可让您迅速一览各项信息,同时让您安装任意数量的应用程序,且无需担忧对性能和电池使用时间的影响。

--Ryan Haveson