windows phone因为墓碑化导致“正在恢复”的分析

我们在平时的WP使用过程中，会遇到一个问题

应用在切出，切回后，

1. 有时候，会显示“正在恢复”，并等待时间较长，才能回到用户切出时候的画面，但是这种情况并非常见，偶尔发生
2. 有时候，直接回到切出时的画面，反应还蛮迅速的

这是为什么那？

我做了研究，分析如下：

首先，我们看一下WP的生命周期

(详情见：App activation and deactivation for Windows Phone 8)

当应用因为

1. 用户点击WIN键
2. 发送短信，跳往WIFI设置，或者其他Task

切出应用后，会触发事件Deactivated，失活，也就是不在前台显示了

然后，

这里是关键

存在两个状态

1. Dormant
2. TomeStoned

Dormant

When the user navigates forward, away from an app, after the Deactivated event is raised,
the operating system will attempt to put the app into a dormant state.
In this state, all of the application’s threads are stopped and no processing takes place,
but the application remains intact in memory. If the app is reactivated from the dormant,
it doesn’t need to do anything to re-establish state, because it has been preserved.

If new apps are launched after an app has been made dormant,
and these applications requires more memory than is available to provide a good user experience,
the operating system will begin to tombstone dormant applications to free up memory.

休眠

当用户向前导航或导航出应用时，引发 Deactivated 事件后，操作系统将尝试使应用置于休眠状态。在此状态下，应用程序的所有线程均将停止，并且不进行任何处理操作，但应用程序仍完好地保留在内存中。如果应用是从休眠状态重新激活的，则无需执行任何操作来重建状态，因为状态已被保留。

如果在应用进入休眠状态后启动新的应用，这些应用需要更多的内存才能提供出色的用户体验，操作系统将开始逻辑删除休眠的应用以释放内存。

Tombstoned

A tombstoned app has been terminated, but the operating system preserves information about its navigation state
and also preserves the state dictionaries the app populated during Deactivated.
The device will maintain tombstoning information for up to five apps at a time.
If an app is tombstoned and the user navigates back to the application,
it will be relaunched and the application can use the preserved data to restore state.

已逻辑删除（即墓碑化）

已终止逻辑删除的应用，但操作系统不仅保留了有关其导航状态的信息，而且还保留了 Deactivated 期间填充应用的状态字典。设备每次最多可维护五个应用的逻辑删除信息。如果在逻辑删除应用之后，用户向后导航至应用程序，则应用程序将会重新启动并使用保留的数据还原状态。

回到问题

应用在切出，切回后，

1. 有时候，会显示“正在恢复”，并等待时间较长，才能回到用户切出时候的画面，但是这种情况并非常见，偶尔发生
2. 有时候，直接回到切出时的画面，反应还蛮迅速的

我认为，

这是因为两种不同的状态返回了应用而致：

应用是从休眠状态重新激活的，则无需执行任何操作来重建状态，因为状态已被保留。

于是这样发生了2

应用进入休眠状态后启动新的应用，这些应用需要更多的内存才能提供出色的用户体验，操作系统将开始逻辑删除休眠的应用以释放内存。（这也是为什么低RAM-512MB的机器更容易出现此问题，他更容易进入此流程）

用户进入逻辑删除（墓碑化）后，再返回应用。

于是这样发生了1

但是上面的关于“墓碑化”的描述文字真的是没有解释为什么会产生会导致性能损失，从而显示“正在恢复”并等待

只是指导了一下开发者，应该在墓碑化前后的Deactivated和Actived中保存和恢复一些状态，实在是不负责啊！

因此，我们现在深入墓碑化，会发现墓碑化后返回应用与休眠后返回应用存在不同

休眠后返回应用

墓碑化后返回（请留心Back之后的区别）

相信细心的你也已经看出来了：

从墓碑化状态Back回应用

居然如“开始屏幕”启动程序一样

重新走了一遍

App Constructor

Page Constructor

启动了一个新的app instance

虽然在“正在恢复”等待之后，最终的效果与Dormant-Back一样，都是显示用户切出应用时候的画面！

怪不得Activated 事件，提醒我们要注意以下黄底部分的文字

Activated 事件

当用户返回到休眠或逻辑删除的应用时，将调用 Activated
事件。应用应检查事件参数的 IsApplicationInstancePreserved
属性，以确定应用是从休眠状态返回，还是从逻辑删除状态返回。如果IsApplicationInstancePreserved 为 true，则应用之前处于休眠状态，状态已由操作系统自动保留。若为 false，则应用之前已被逻辑删除，应用应使用状态字典来还原应用程序状态。在执行Activated 事件处理程序期间，应用程序不应执行资源密集型任务（例如，从独立存储或网络资源加载内容），因为这会增加应用程序恢复所用的时间。而是应在加载应用程序之后，在后台线程中执行这些操作。由于在重新激活您的应用时，您在Deactivated
期间保存的状态字典将显示在内存中，您可以用这些字典来还原状态，而避免产生资源密集型文件操作的开销。

我自己的亲身调试经历也告诉我，当打开

调试——项目属性

勾选“在调试且停用时执行逻辑删除”

应用在切出切回后同样显示“正在恢复”

且等待少许时间

才能回到用户切出时候的画面

因此，验证了我的想法

另外，这个问题十分有趣

同样是采用墓碑机制，Windows Phone 8和iOS的多任务性能为什么会有较大的差别？

有兴趣的同学可以看一下