WP7从Tombstone恢复并返回页面

Question

从逻辑删除恢复时，是否有一种很好/优雅的方式返回用户所在的页面？我不确定我的应用程序是否正常工作，但我总是回到我的主页。

我的应用程序设置了一个带有枢轴控件的主页，并且多个枢轴项目将导航到新页面。如果有意义的话，我的导航看起来像这样：

PivotItem1 ->页A
数据透视项2 -> B页-> C页
PivotItem3 ->; D页-> PageE - PageF（按 PageF 上的后退按钮将使用非线性导航服务返回主页）

因此，如果用户在任何页面上建立墓碑，我希望将它们返回到该页面并让 BackStack 可用，这样导航就不会被搞砸向上。

我正在使用 MVVM Light 和非线性导航服务，如果这有助于或损害我想要完成的任务。

Answer 1

@Tyler，Cyber​​herbalist：我很遗憾我不能直接在您的讨论中“添加评论”。我的声誉还是太低了。我没有任何博客可以将其发布在那里并为您提供指向它的链接。我就写在这里，因为我认为值得注意并写在某个地方，所以其他人也可以检查/使用/性能从中获利。

..所以，请原谅我在这里写这篇“题外话”:)

虽然我不知道如何很好地解决问题 - 我的解决方案通常是手动收集导航历史记录堆栈，将其放入 iso，并在激活时恢复然后跳到右边/最后一个地方 - 我可以告诉你一些关于墓碑的事情。

问题是，如果您的应用程序被停用，并不意味着它已被逻辑删除。停用只是意味着您的应用程序被移出了屏幕。在 Mango 版本中，您可以点击并按住“后退”设备按钮，查看当前打开的应用程序，然后跳转到任何应用程序。 “激活”是指您的应用程序被唤醒。即使在 WP7 SDK+模拟器的早期版本中，我也从我的应用程序中调用外部媒体播放器，并且我的应用程序几乎从未被物理杀死。停用/激活总是在“暂停”的地方恢复我的应用程序。所有内存中的对象都未受影响。

当设备资源不足时，就会发生逻辑删除，并且必须“终止”一些后台任务以释放内存。我相信当设备的屏保下拉或者设备长时间处于待机状态时也可能会出现这种情况。逻辑删除实际上会杀死您的应用程序，所有内存中的对象都将被销毁/删除等等。唯一能够幸存的就是 AppSettings 和 ISO 存储。 仅当您的应用程序处于停用状态时，墓碑才会发生。

那么，您可以看到哪些生命周期？

1）“冻结/待机/失焦”：

• 启动
• ...（工作）
• 停用（移动到后台）
• ...（保留在内存中，也许进程/线程被冻结，但我怀疑）
• （...）
• 激活（移动 到后台）到前台，没有导航发生）
• ...（工作）
• 关闭

2）“墓碑”：

• 启动
• ...（工作）
• 停用（移动到后台）
• ...（保留在内存中，也许进程/线程被冻结，但我怀疑）
• ...（墓碑化，从内存中删除，一切都被破坏）
• （...）
• ...（构造干净的应用程序对象）
• 激活（移动到前台）
• 导航（我认为，始终到第一个默认页面设置明显，但我现在不确定）
• （正在工作）
• 关闭

这意味着，墓碑可能有点难以检测，但也意味着，您总是有时间尝试在停用事件处理程序中保持相同的状态。

这也意味着（除非有一些我还不知道的通知服务），检测从墓碑恢复是否依赖的唯一方法是依赖最致命/最不愉快的效果其中：关于清除你的记忆。

想象一个最简单的情况：您的 App 对象有一个属性“private bool _tomb_test”。它可以是任何类型的任何属性/字段。您也可以使用“object ViewModel{get;set}”来实现此目的。

首先要记住的是，不在构造函数中设置它，并且不分配内联默认值。让它漂浮即可。每当新创建 App 对象时，编译器/运行时都会将其设置为默认 false。这就是重点！

现在：

• 在 Launched （不是 ctor!!!） 中，在 deactivated 中设置“_tomb_test = true”
• ，将最小持久状态保存到
• 激活中的 ISO，检查：
  • 如果 _tomb_test==false 则意味着您已被墓碑化。你的记忆是干净的，所有的物体都被摧毁了。根据上次写入 ISO 的数据恢复您的状态，然后启动所有作业来重新填充/重新下载/重新加载/重新计算/等应用程序状态的所有其他部分
  • 但是，如果 _tomb_test==true，则意味着逻辑删除并未发生。你的记忆未受影响。也许只是 GC 启动并收集了死者。所有曾经有生命的物体仍然活着。该应用程序可以免费运行，就像什么都没发生过一样。

虽然它看起来很漂亮，但请原谅我的冗长免责声明：

我在当前应用程序中成功使用了它，并且 100% 成功，但我不能说这是有保证的平台行为。我还没有时间在 MSDN 上挖掘事实。以上所有内容均来自我对 7.0 和 7.1 SDK 版本的观察。

上述方法的一个小问题是，它依赖（未经证实？）的假设，即内存清除以“全有或全无”的方式进行。

也就是说，假设所有对象都被清除，或者没有发生清除（当前事实：App 对象被观察到从头开始重新创建，甚至发生初始导航来重新创建 UI。在其他情况下，这两种情况都不会发生）发生）。

对于错误的假设...我无法想象谁以及为什么会决定在.net 世界中实施部分内存清除。完全清除意味着杀死该应用程序。部分清除意味着销毁 GC 代中的随机活动对象，并让所有剩余的对象保持悬空句柄或空句柄。我无法想象。我没有观察到。因此，我认为这是全有或全无的情况。

顺便提一句。如果您观察到部分清除并找到了导致它的主要确定性方式，以便其他人也可能看到它，请大声广播！ :)

Answer 2

我有一个类似的导航应用程序，它可以满足您的需求（也使用非线性导航服务）。在我的例子中，我将用户的当前页面/枢轴项目存储在独立存储中，以及指示应用程序是否从逻辑删除返回的令牌（或布尔值）。当用户导航到页面时，页面加载会在 iso 中设置当前页面值，如果页面有枢轴，它还会将当前枢轴设置为第一个。 hub_changed 事件包含将新的当前数据透视表更改为用户刚刚更改的数据透视表的代码。

当应用程序处于逻辑删除过程中时，会触发 app_deactivate 事件，在这里我将 iso 中的 IsTombstoned 值设置为 true。

当用户从逻辑删除返回时，主 page_load 首先检查应用程序是否从逻辑删除状态重新激活 (IsTombstoned=true)，如果是，它会立即导航到名称存储在 iso 中的页面。当当前的 page_load 触发时，它会检查 IsTombstoned=true 是否为 true，如果是，则将其设置为 false（恢复正常），如果页面上有数据透视表，则将选定的数据透视表项设置为存储的当前数据透视表。如果页面没有枢轴控件，则当前枢轴将留空。如果页面被逻辑删除时存在动态内容，您还需要提供其恢复。

抱歉，我没有向您展示代码，但我远离工作站，无法访问它。