【翻译】Windows Phone运行模型概述
本篇翻译自MSDN Execution Model Overview for Windows Phone
原文链接http://msdn.microsoft.com/en-us/library/ff817008(v=VS.92).aspx
翻译：楼上那个男人
Windows Phone运行模型概述
Windows Phone运行模型管理整个应用程序的生命周期。从应用程序运行一直到结束。
该运行模型意图提供给用户一个任何时刻均可快速响应的用户体验。为此，Windows Phone任何时候仅允许一个应用运行在前台。操作系统将不在前台运行的程序转入休眠状态（dormant state）。当设备可用内存不足以为前台程序的用户体验提供足够的资源时，操作系统会结束一些休眠状态的程序。较早进入休眠状态的程序会被优先结束掉。程序框架将提供对应用程序“激活”(reactivated)，“失效”(deactivated )状态的管理。这将使用户感觉应用程序始终在运行，即使它们已经被“结束”（terminated）或“失效”（reactivated）。
运行模型也负责在不同应用之间提供一致的导航体验。在Windows Phone上，用户向前导航（navigate forward）的操作包括：运行应用程序列表中安装的App，点击开始界面的瓷片(Tile)，以及其他方式比如推送通知关联的应用程序。用户也可以向后导航（navigate backwards），在程序运行页面执行后退的逻辑，或者拖过点击物理的“Back”按钮。Windows Phone 7.5中，按住“Back”按钮，就可以选择之前运行的应用程序。
本节提供了Windows Phone应用程序生命周期详细的解释，以及开发应用程序所需步骤的概述。包括快速响应和一致性导航的用户体验。在阅读这篇概述后，你可以进一步的阅读以后的章节，包括一些样例代码。
尽管操作系统采用同样的方式管理所有的应用程序，但是在处理应用程序中断时，XNA游戏需要一些特别的考虑。如果你正在创建一个基于XNA的游戏，你应该阅读本节，以及Tombstoning for Windows Phone 7 Games.
术语
你应该先熟悉以下的术语和概念，在你阅读剩下的部分之前。
|
Application State |
需要在多个页面重复使用的数据可以存放在Application State中。比如从Web Service获得的数据。你可能想要在不同页面以不同的形式来显示相同的数据,并且这些数据对整个应用程序来说是相同的。一种常见的错误是认为所有的Application State数据都应该在程序关闭时存储。其实在用户从当前页面离开时保存，通常是一个很好的注意。这将减少应用程序关闭时所要做的操作，改善用户体验。 |
|
Page State |
用来存储单个页面的当前可视状态。比如你有一个包含接受用户输入控件的页面, 用户在离开了你的应用程序后，又再次返回。用户希望表单上所有的控件都保持离开前的值。应用程序应该管理Page State，在页面重新加载时恢复控件的值，给予用户应用仍在运行的良好体验。但是当用户运行一个新的应用程序实例时，则不应该用前一个实例的Page State来恢复新的实例。 |
|
Application Events |
这里有四个主要的事件用户于应用程序状态管理: Launching, Deactivated, Activated, 和 Closing。这些事件的处理方法已经在Visual Studio project的Windows Phone applications模板中包括了。如果你需要管理应用程序状态，你应该在App.xaml.cs中相应的事件处理方法中，添加自己的代码。 重要提示: 所有的应用程序事件都有10秒的时间限制，应用程序必须在10秒内完成操作。如果用时超过10秒，程序将会被立即结束掉。因此, 在Application Events中，你应该避免频繁的操作资源, 比如读取和写入isolated storage。这些任务应该在应用程序创建后，在后台线程执行。在整个应用程序生命周期中，尽可能的立即保存已经改变的数据，减少你在application events中需要进行的状态管理操作。 |
|
Page Events |
所有继承了PhoneApplicationPage对象的页面均暴露了两个方法，OnNavigatedTo(NavigationEventArgs)和OnNavigatedFrom(NavigationEventArgs), 你的应用程序可以通过Override这两个方法来管理Page State。 |
|
Tombstoning |
当应用程序的进程结束时，一些状态数据和个别页面将会被保存。这些数据包括当前页面和之前访问的页面间的返回堆栈。如果用户向后导航（navigate backwards）至已经墓碑化的应用程序。该应用程序将会被重新创建，且当前页的状态和页面间的导航信息将被自动恢复。 |
|
State Dictionaries |
每一个Windows Phone应用程序和页面都提供字典对象（Application State和Page State），用以存储键值对。这些字典对象在程序进入墓碑状态（tombstoned）时被保存。当程序从墓碑状态（tombstoned）被激活（activated）时，这些字典对象用以恢复Application State和Page State。注意所有的这些数据都必须可以序列化！（否则无法存入，且不报错。） |
The Windows Phone Application Lifecycle
下图说明了Windows Phone应用程序的生命周期。图中, 圆圈是应用程序状态。矩形显示了应用程序或页面级别的事件，你应该在这些事件中管理应用程序的状态。
本节讨论了Windows Phone应用程序生命周期，强调了每个步骤应该做的事情。本节提到了操作系统层面和用户操作对application state的影响。具体的事件列表及你的应用程序应该做的事情参看这里 Summary of Execution Model Events and Application Actions.
The Launching Event
Launching事件发生在用户创建一个新的应用程序实例时，比如从应用程序列表或Strart页面的瓷片（Tile）中运行程序，点击推送通知关联的应用，从照片库的扩展菜单中选择运行一个程序。当应用程序通过这些方式运行，应该呈现给用户一个新的实例，而不是之前的实例。未了确保你的应用程序可以快速的启动，你应该在Launching事件中写尽可能少的代码。特别是要避免资源密集型的任务，比如访问网络。为了最佳的用户体验，你应该在程序加载后，在后台线程运行这些任务。
Running
在应用程序创建后,程序将保持运行状态。直到用户向前导航（navigate forward）离开这个程序，或者从程序的第一个页面向后导航（navigate backwards）。Windows Phone应用程序不应该存在退出这样的概念. 在屏幕被锁定时，应用程序也应该离开运行状态（Running State），除非你已经关闭了application idle detection。请参阅 Idle Detection for Windows Phone.
The OnNavigatedFrom Method
当用户从页面离开时， OnNavigatedFrom(NavigationEventArgs) 方法将会被调用。除了在应用程序页面间导航切换时会触发外，应用程序“失效”时（deactivated）也会被调用。只要这个方法被调用，你就应该保存Page State，以保证用户返回该页面时，状态能被恢复。但向后导航（navigation backward）是个例外。NavigationMode属性可以被用来判断是否为向后导航（navigation backward），在这种情况下不需要保存状态，因为下次访问时，该页面又会重新走一遍创建的逻辑。
一些情况下，你可能也需要在OnNavigatingFrom(NavigatingCancelEventArgs)方法里保存状态。特别是你需要保存MediaElement控件的状态时。
The Deactivated Event
Deactivated事件发生在用户向前导航（navigates forward），通过按下Start按钮或运行其他程序来离开你的应用时。你的程序启动一个选择器（Chooser）时也会发生Deactivated事件。关于Choosers请参见Launchers and Choosers Overview for Windows Phone. 屏幕锁定时也会发生Deactivated事件，除非你已经关闭了application idle detection。
处理Deactivated事件，应用程序应该保存所有的状态，以便能够做到在短时间内恢复。Windows Phone应用程序提供了State对象, 以字典（dictionary）的形式来存储应用程序状态。如果应用程序从墓碑状态（tombstoned）被重新激活（reactivated），状态字典（state dictionary）将填充失效时（Deactivated）保存的数据。因为这些数据都是在内存中，所以你不用做任何文件操作就可以恢复应用程序状态。
在调用Deactivated事件后，应用程序有可能被彻底结束。状态字典（state dictionary）在程序结束时是不会被保存的。所以，你同样应该在Deactivated事件中保存那些需要持久化的应用程序数据到独立存储（isolated storage）中。
Dormant
当用户向前导航（navigates forward）离开应用程序，会调用失效（Deactivated）事件，之后操作系统将试图将应用程序转为休眠状态（dormant state）。在这种状态下，应用程序所有的线程将停止工作，但应用程序仍完整的保存在内存中。如果从休眠状态被激活（reactivated），应用程序不需要重建任何状态，因为程序一直完整的保存在内存中。
如果新的应用程序开始运行，并且需要更多的可用内存来提供足够好的用户体验。操作系统将墓碑化休眠的应用程序来释放内存。
Tombstoned
一个墓碑化（tombstoned）的应用程序实际已经被结束了。但失效（Deactivated）事件中保存的导航信息和状态字典依然存在。Windows Phone设备将同时维护最多5个应用程序的墓碑信息。如果用户向后导航（navigates back）到处于墓碑化（tombstoned）的应用程序，应用程序将被重新创建，并且使用保存的数据来恢复状态。另一方面，原来墓碑化的程序将被结束。
The Activated Event
当应用程序从休眠或墓碑状态返回时将调用Activated事件。应用程序可以检查事件参数中的IsApplicationInstancePreserved来判断是从休眠或是墓碑状态返回的。如果IsApplicationInstancePreserved为true，应用程序是处于休眠状态，操作系统将自动恢复程序状态。如果是false，则应用程序是从墓碑状态被恢复，应用程序应该使用状态字典中的数据来恢复程序状态。在Activated事件中，应用程序不应该执行资源密集型的任务，比如读取独立存储的数据（isolated storage），或者访问网络资源。因为这将增加应用程序恢复所花费的时间 ，这些操作应该在程序启动后，在后台线程中执行。
The OnNavigatedTo Method
用户导航（navigates）进入页面时调用OnNavigatedTo(NavigationEventArgs) 方法。包括应用程序首次运行，用户在页面间切换和从休眠或墓碑状态恢复。在该方法中，应用程序应该检查页面是否是一个新的实例。如果不是，页面状态就不需要恢复。如果是新的页面实例，并且状态字典中存在对应该页面的数据，则应该恢复页面UI到之前的状态。
The Closing Event
当用户从应用程序的第一个页面执行向后导航（navigates backwards）时，将调用Closing事件。在这种情况下，应用程序将被结束且不保存状态。在Closing事件的方法中，你的应用程序可以保存那些应该被持久化的数据。对所有的应用程序事件和页面事件的执行时间都有一个10秒的限制。如果时间超过这个限制，应用程序将被结束。因此，建议在整个应用程序生命周期中尽可能的进行保存状态的操作，来避免在Closing事件中处理大量的文件I/O操作。
Summary of Execution Model Events and Application Actions
下表总结了应用程序生命周期中会触发的事件，以及应用程序对应该事件应该采取的动作。
|
Event or method |
Application action |
|
|
Launching event |
执行少量代码。不要做访问独立存储之类资源密集型的操作。 |
|
|
OnNavigatedFrom method |
如果不是向后导航（backward navigation）,保存界面状态（UI state）至State dictionary. |
|
|
Deactivated event |
当墓碑化应用程序时，保存application state至State。当应用程序结束时，保存需要持久化的数据至独立存储（isolated storage）。在应用程序处于休眠状态时，不要销毁内存中的application state。 |
|
|
Activated event |
检查IsApplicationInstancePreserved。如果是true, 不用做任何事。如果是false, 使用State中的数据恢复application state。 |
|
|
OnNavigatedTo method |
检查是否是新的页面实例。如果不是, 状态会自动恢复。否则使用State中的数据来恢复UI。 |
|
|
Closing event |
保存需要持久化的数据至isolated storage。 |
|
|
警告: |
||
|
本节描述的事件提供了当应用程序从前台开始运行和离开时，保存和恢复应用程序状态的机制。无论如何，推荐的做法是在数据改变时立即保存。例如，一次web request的结果在到达时，就应该立即被保存到磁盘（disk）或者application state dictionary（或二者均需要）。你不应该等到失效事件（Deactivated）发生再保存数据。记住在应用程序生命周期中，事件存在10秒的强制限制。 |
||
