使用 Windows Azure 和 Windows Phone 7 构建数据驱动的应用程序

在过去 30 年，我们经历了计算机硬件行业的爆炸式增长。 从大型机到台式机再到手持设备，虽然硬件的体积缩小了，但功能却越来越强大。 开发人员在某种程度上有点被计算能力的这种持续增长宠坏了，现在他们希望自己为其编写应用程序的每台设备都拥有无限的计算机资源。 过去，代码的大小和效率曾经是编程的重要考虑因素，很多年轻的开发人员对这段历史没有任何印象。

最新的开发趋势是追随智能手机日益流行的脚步。 在为智能手机设备编写代码时，许多开发人员必须适应这样一个现实：尽管今天的手机功能要比几年前的设备强大很多，但还是面临限制。 这些限制与大小、处理器能力、内存和连接性有关。 您需要了解在创建移动应用程序时如何突破这些限制，从而确保提供良好的性能和最佳的用户体验。

导致应用程序的性能不甚理想的某些原因与开发人员糟糕的设计决策有直接的关系。 但在其他情况下，其中有些因素不受开发人员的直接控制。 第三方服务较慢或脱机、移动宽带连接断开或您所处理数据的特性（如流媒体文件或大型数据集）可能会导致应用程序性能较差。

无论原因是什么，应用程序最终用户感知的性能必须是任何软件开发人员所关注的头等大事之一。 在本文中，我们将介绍一些有关以一种可提供完美用户体验和轻松缩放功能的方式设计可靠的数据驱动 Windows Phone 7 应用程序的首要注意事项。

让我们先花一点时间设置一种方案，我们可以在这个方案中考察一些设计和编码选择。 举个例子，我们将使用一个虚构的旅行信息应用程序，该应用程序提供有关用户选择的航班的信息。 如图 1 所示，该应用程序的主屏幕上显示一些数据元素，包括当前的天气和航班状态。 您可以看到，随着应用程序变得更具表现力且越来越以数据为中心，开发这样的应用程序也变得更具挑战性。 在越来越多的方面，您的代码已经无能为力了。

图 1 航班信息示例应用程序

UI 线程阻塞

首先，我们来看一下 UI。 如果像对台式机编码那样设计应用程序，那么很容易就会将模式搞错，因此让我们先了解一些手机特定的 UI 问题。

当应用程序未按预期对用户命令做出响应时，此时给整体用户体验带来的影响是显著的。 对滑擦、点按或挤压操作响应缓慢可能会对应用程序的整体吸引力不利。 但这些是可以预期并解决的相当简单的问题，正如您将要看到的。

考虑使用 ListBox。 当 ItemTemplate 包含图像或从源加载数据时，UI 线程很有可能将被阻塞，UI 在请求或计算完成前将一直暂停。 因此，当您开发 UI 时，一种方法就是在 UI 线程外执行长时间计算（包括 WebRequest）。 实际上，这对任何应用程序（移动或非移动）来说都是一种好方法。

当您将大量的项目绑定到 ItemSource 而对注入 ListBox 控件的项目数没有限制时，也可能会产生性能问题。 一种更好的方法是绑定一个 ObservableCollection，然后每隔 20 至 30 毫秒向该集合填充一些项。 这将解除 UI 线程的锁定以响应用户。

在我们的示例应用程序中，我们还在屏幕上使用了大量图像。 ListBox 需要实际下载图像才能显示相应数据。 这种方法看似不错，但在 UI 线程上执行此工作将阻止用户进行任何手势输入。 在后台线程上加载图像将解决很多内存要求和释放 UI 线程方面的问题，同时也使应用程序速度加快。

必须呈现我们向用户显示的全部内容。 呈现需要布局、对齐和计算才能正确显示。 随着越来越多的层添加到 UI 中，计算和整体呈现成本也随之增加。 尽管 Silverlight 已虚拟化 UI，但未虚拟化要绑定的数据。 这意味着，如果我们将 10,000 个项目绑定到 ListBox，Silverlight 将需要实例化所有 10,000 个 ListItem，然后它们才会呈现出来。

请注意您正在数据绑定的项目并保持绑定集尽可能小。 如果需要处理大型数据绑定项目集，请考虑在后台动态处理呈现。 当然，桌面应用程序同样如此，只是这些选择的影响在手机上有所扩大而已。

ValueConverter 可能会对呈现性能产生巨大的影响，因为它们是使用自定义代码定义的，无法在实际元素呈现和布局之前预先确定和缓存呈现。

处理数据

接下来，我们需要讨论 Windows Phone 7 中的数据存储。 让我们直奔主题：没有任何关系数据库引擎可供开发人员使用。 SQL Server Compact (SQL CE) 随 Windows Phone 7 操作系统一起安装，但当前没有任何 API 可供开发人员使用。 因此，创建一个数据库用来存储应用程序数据（在我们的示例中为旅行信息）行不通。

也就是说，可使用各种不同的选项使数据进出我们的应用程序。 常用方法是使用云服务（如 Windows Azure）来持久保留数据。 用于生成应用程序的服务层的技术有很多，REST 和 SOAP 是最受欢迎的。 很多开发人员都首选 SOAP，但我们认为 REST 可提供一种更高效且更易于实现的方法用来生成数据请求。

我们采用几种方法向应用程序提供数据，通过使用下面这样的 REST 表达式可以访问这些方法：

/Trip/Create/PHL-BOS-SEA/xxxx/2010-04-10
/Flight/CheckStatus/US743
        

处理网络故障

移动设备使用的网络可能有各种可变的连接，有时会因位置、拥塞甚至是用户手动断开连接而变得完全不可用（例如，当使用航班模式时）。 作为生活中的现实情况，您必须接受这一点。 作为移动应用程序开发人员，我们必须在生成应用程序时将这点考虑在内。

另一种类型的网络故障是服务层失败。 很多移动应用程序都使用第三方服务的数据。 这些服务可能没有附带服务级协议，这样您的应用程序就受控于提供商了。 换句话说，它不受您的控制，您必须准备好处理中断情况。

无论网络故障的来源是什么，您都仍然需要尽可能提供最佳用户体验。 发生任意类型的网络故障时，您都需要提供某一级别的功能。 对于我们的航班状态应用程序，这意味着我们希望允许用户访问尽可能多的信息，即使在服务器或客户端的网络连接断开的情况下。

可通过多种方法实现这一点。 现在，我们将集中讨论三种可用来实现这一点的简单方法：在数据可用时获取数据，本地缓存数据，在您控制的服务器上缓存数据。

使用推送通知

当用户将旅行信息输入到应用程序时，该信息将上载到云服务。 然后，该服务将不断轮询提供其航班和天气数据的各种服务。 它还查找随时间变化的数据更改，如航班状态更改或报告延误的机场。

发现更改时，您需要尽可能迅速高效地将该信息提供给用户。 为此，一种方法是让该服务将信息推送至客户端应用程序。 这将在数据变得可用时为用户提供对最新可用数据集的访问。 由于将数据推送至了客户端，因此即使用户丢失其网络连接，数据也可用。

我们可借助 Windows Azure 服务通过使用 Windows Phone 推送通知实现这一点。 Windows Phone 推送通知功能由三部分组成：监视服务、Microsoft 推送通知服务和消息处理方法。

监视服务是一种云服务，它不断查找有关我们的应用程序的新信息。 我们将在稍后详细讨论这个问题。

推送通知服务是 Microsoft 托管服务的一部分，用于将消息中继到 Windows Phone 7 设备。 该服务可供所有 Windows Phone 7 应用程序开发人员使用。

消息处理程序方法执行其名称所暗示的操作：只接收来自推送通知服务的消息。

Windows Phone 7 中存在三种默认通知类型：Tile、Push 和 Toast 通知。 通知是用户体验中的重要组成部分，您需要仔细考虑它的使用方式。 重复通知或侵入式通知会降低您的应用程序及设备上运行的其他程序的性能。 这些通知还会打扰用户。 请考虑发送通知的频率以及您希望引起用户注意的事件类型。

在 Windows Phone 7 中，通知是通过批处理方式传递的，因此事务可能不是即时的。 通知的及时性将得不到保证，而且将由该服务决定如何将通知传递给客户端；该服务会尽力确定要多快才能将消息传递到手机。

推送通知的工作流是：

1. 客户端应用程序请求与推送通知服务建立通道连接。
2. 推送通知服务使用通道 URI 响应。
3. 客户端应用程序向监视服务发送包含推送通知服务通道 URI 以及负载的消息。
4. 当监视服务检测到信息更改时（在我们的示例应用程序中为航班取消、航班延期或天气警报），它会终止向推送通知服务发送消息。
5. 推送通知服务将消息中继到 Windows Phone 7 设备。
6. 消息处理程序处理设备上的消息。

本地缓存数据

使数据可用于应用程序的另一种方法是本地缓存数据，这样 UI 中将始终存在一些数据。 然后，您可以通过其他方式在后台更新本地数据（如果可能）。 此方法的好处是，应用程序在加载后迅速可用，即使必须在后台以异步方式更新信息也是如此。

简而言之，使用“独立存储”可保存最新的数据集。 当应用程序打开时，它立即获取本地“独立存储”中可用的所有数据并进行呈现。 与此同时，应用程序还调用 Windows Azure 服务来获取更新的信息。 如果发现新信息，则序列化新信息并传送至设备，独立存储得到更新，而您再次用更新后的信息呈现 UI。 为了获得更好的用户体验，您可能需要在 UI 中指定刷新信息的时间和日期。

顺便提下，如果应用程序使用的是 Model-View-ViewModel (MVVM) 设计模式，则可通过 Silverlight 数据绑定功能自动更新 UI。 有关 MVVM 和 Silverlight 的详细信息，请参阅 Robert McCarter 的文章“使用 Model-View-ViewModel 的问题和解决方案”（位于 msdn.microsoft.com/magazine/ff798279 上）。

在服务器上缓存数据

在数据变得可用时将数据直接推送到应用程序与将数据存储在设备上之间还有一个中间过程：从第三方服务获取数据，并将数据缓存在云应用程序中，直到 Windows Phone 7 应用程序请求数据。

这项技术要求在应用程序中有一个新的抽象层。 实际上，这里的目标是从应用程序中删除第三方服务的依赖项。 您的服务提取并缓存第三方服务依赖项的数据。 如果第三方服务出现故障，您至少在缓存中有一些数据可提供给设备上的应用程序。

像这样的服务很容易克隆或扩展，以便从各种服务中提取数据，这样可减少对任一供应商或数据源的依赖，从而使得更换供应商容易多了。

有关如何在 Windows Azure 中设置注重数据的解决方案的详细信息，请参阅 Kevin Hoffman 和 Nathan Dudek 发表的“使用 Windows Azure 存储增强应用程序的引擎”(msdn.microsoft.com/magazine/ee335721)。 此外，Paul Stubb 的文章“创建用于 SharePoint 2010 的 Silverlight 4 Web 部件”虽然未直接重点介绍 Windows Phone 7 方案，但对于了解 Silverlight 和 Web 服务的数据绑定设计来说也是一篇好文章 (msdn.microsoft.com/magazine/ff956224)。

监视服务

前面曾提到，通知功能是航班状态应用程序的重要组成部分。 这项功能实际由该应用程序中的几种不同服务组成。 监视服务对于该应用程序发挥作用可能最为重要，该服务定期轮询第三方数据服务，并将像航班延期、机场延误和天气警报这样的信息中继到设备。

在我们的应用程序中，监视服务读取航班和机场代号的当前列表并使用此信息来收集相关数据。 然后，将此信息作为缓存项存储回 SQL Azure 数据库中，以便可由前面所示的 /Flight/CheckStatus 服务检索。 我们的监视服务是使用 Windows Azure 工作者角色实现的。 此工作者角色的主要目标是获取有关航班延误和机场状态的状态信息，方便每个用户收集航班信息。 随着安排的航班接近起飞时间，更新频率随之增加。

有关如何实现这类服务的一些经验，请务必查看 CodePlex (azurepubsub.codeplex.com) 上的“Azure 发布-订阅”项目，或者阅读 Joseph Fultz 的博客文章“将 Windows 服务迁移到 Azure 工作者角色：使用存储的映像转换示例”(bit.ly/aKY8iv)。

综合讲述

希望我们已经向您综述了设计数据驱动的 Windows Phone 7 应用程序时需要考虑的问题。 UI 响应和及时访问数据源有助于实现完美的应用程序用户体验。

若要更深入学习，请先阅读 Joshua Partlow 的文章“Windows Phone 开发工具入门”(msdn.microsoft.com/magazine/gg232764)。 您还需要查看 Jim Nakashima、Hani Atassi 和 Danny Thorpe 发表的文章“如何在 Visual Studio 2010 中开发和部署 Windows Azure 应用程序”(msdn.microsoft.com/magazine/ee336122)。

若要将 Windows Azure 和 Windows Phone 7 开发结合在一起，请阅读 Ramon Arjona 的文章“Windows Phone 与云 - 简介”(msdn.microsoft.com/magazine/ff872395)。