Windows Phone 7 墓碑机制

原文地址：http://msdn.microsoft.com/en-us/magazine/hh148153.aspx

一个优秀的移动平台需要意识到移动能力所带来的诸如硬件限制一类的负面影响。相比于

桌面应用， 移动设备有着更小的内存，更低的处理能力，受限的屏幕显示以及受限的电池

容量。考虑到以上这些限制可以得到如下结论：在一台非专注（多用途）的设备上会有许多

应用程序运行，他们最终都会被关闭，这样才能给其他应用程序腾出运行所需要的资源。

Windows Phone 用一种叫做“墓碑”的机制来处理这个问题。 尽管表面上看“墓碑”是一个非常

直白的命题， 但实际上在开发者中它是颇具争议的。 有些人觉得它（墓碑）没有存在的必要。

还有一些人说它太难了。剩下的一些人仅仅只是讨厌“墓碑”这样一个名字。然而，尽管有着这么多的诟病

移动设备的限制还是使得它（墓碑）成为了一种必须品，一款好的移动应用不得不跟“墓碑”打交道。

Windows Phone应用的生命周期

大多数 Windows Phone开发者第一次接触到这个平台的时候都会这么定义一款应用程序的生命周期：

1.Start

2.Run

3.Exit

4.Go back to 1 and start again

Windows Phone 7重新定义了这样一个生命周期，使得它更加的面向会话而更少的去面向过程。

在Windows Phone 7中 你应该这么来考虑应用程序的生命周期

1.Start

2.Run

3.Interrupted execution or exit

4.If interrupted, come back-or, even if interrupted, start anew

5.If exited, start anew

这种面向会话的模型的好处在于：用户在各个应用程序之间切换的时候不需要考虑操作系统是如何来管理

系统资源的。譬如说，用户暂停游戏去查看一条短信的时候不会担心系统会直接终止游戏进程。用户期望

的是看完短信能够继续刚在正在进行的游戏。如果这种机制工作的很完美的话，底层的机制就无所谓了。

当然这种机制也有它的负面影响，譬如说开发者要考虑更多的东西来保证会话（ session）的持续性，因为

这些会话（ session)依然运行在一个传统的以处理为核心的操作系统上。 为了在这样一个以处理为核心的

环境中容纳多个会话，我们需要为会话定义一些逻辑状态： Launched, Activated, Running,
Deactivated,

Tombstoned以及Closed(or
Ended);

图1 展示的是 Windows
Phone 7应用程序的生命周期。生命周期中的一些 event事件会在图2 中给出，这些是

在 the Microsoft.Phone.Shell.PhoneApplicationService 这样一个类中给出的。

 



                                             图1Windows Phone 7的生命周期



                                              图2 Application Lifecycle Events

墓碑状态稍微复杂一点， 它跟PhoneApplicationService event并没有直接的关系。当一个应用应用程序被deactivated，

操作系统并不会马上终止这个应用程序的进程。理论上来说，操作系统只有在需要更多系统资源的情况下才会这么做。

这时应用程序甚至都完全没有察觉，它就这么被赤裸裸的干掉了。

当控制转向另外一个应用程序的时候， Windows Phone 7会立马杀死进程，但是千万不要百分百指望这样一个细节。

去年2月份的时候， 微软已经在 Mobile
World Congress上发表声明称：一些改进措施例如 Fast App Switching （快速

应用切换）就快面世了， 不要根据一些细枝末节的描述就断定“墓碑”是否发生了。作为替代措施，我们应该做好准备，

在deactivation的时候做一些工作。

Deactivated vs. Tombstoned

一部手机同一时刻会有许多进程在运行（shell, phone and so on), 但是在统一时刻， 手机的前台只应该有一个应用程序
（没有应用程序运行的时候可以为0）。

当一个前端应用程序把控制权转交给另外一个应用程序或者是操作系统组件本身的时候，它就被deactivated了。当一个
进程被deactivated的时候， 操作系统就会杀死进程，释放相应系统资源。这个就叫做“墓碑”。

正如你所了解的那样， “墓碑”并不总是在每一次应用程序被deactivated的时候就发生，但是如果发生了，“墓碑”一定是
紧随一次deactivated事件发生的。事实上Deactivated是PhoneApplicationService在"墓碑"之前的最后一个动作，所以这
里才是每次应用程序被重新激活的时候你需要操作的部分。

图3 展示了能够导致deactivation的不同事件， 以及对墓碑是否发生了的一些猜测



                                                            图3 Deactivation Tasks

有一些列的chooser不会立即触发“墓碑”， 他们只会在用户采取了一些特定操作的时候才会触发”墓碑“。这些chooser
包括PhotoChooserTask(除非用户指定了数量)， CameraCaptureTask, MediaPlayerLauncher, EmailAddressChooserTask
以及PhoneNumberChooserTask。
所有其他的choosers和launchers都会在调用show方法之后立即触发“墓碑”。

想要看看Windows Phone 7应用程序生命周期的实例代码，可以登录LWP.TombStoning上下载相关代码。

Saving and Restoring State

基于会话的导航根本目的是为了让用户能够在不同的应用程序之间实现无缝切换，你必须在Deactivated事件中保存所有的
相关状态，并且在Activated事件中恢复这些状态。大多应用程序都有如下的三种状态需要管理：

Persistent application state 

Session-specific application state 

UI- or page-specific state

* 持久应用程序状态，必须要持久化，包括应用程序的设定参数，用户数据等等
* 会话相关的应用程序状态， 包括临时状态例如缓存以及ViewModels，它们都需要在activation中进行存储，但是在第一次运行
     应用程序的时候重新赋值
* 用户界面或页面相关状态，当应用程序被activated的时候需要存储在PhoneApplicationPage中。当墓碑触发的时候Windows Phone 7
     有一个应用程序状态的栈。在activation的时候，它会恢复在“墓碑”的时候的最后一个活动页面。如果用户按下Back按钮，前一个页面

     会被实例化。