Windows Phone 后台任务过早停止答案

【问题标题】：Windows Phone background task stops prematurelyWindows Phone 后台任务过早停止
【发布时间】：2014-08-01 17:22:11
【问题描述】：

我正在开发一个使用后台任务（不是代理！）的 WP8.1 SL 应用程序。

我的任务由 TimerTrigger 触发 - 每 30 分钟一次（我相信这是 Windows Phone 的最小间隔，对吧？）。 它正在做很多工作，并且由于某种原因，有时它会被打断 - 也就是说，它会在中间停止。我知道它在中间的方式是因为我登录每次发生的事情和任务的工作基本相同。

我昨天将应用程序部署到我的设备以测试一种新方法，并且一切正常 - 后台任务每次启动时都会执行所有操作 - 就像一个魅力。今天我的设备需要软重置，所以我做了（没有任何工作，自从我更新到 WP8.1 后它时常发生）。从那一刻起，后台任务每次都会被中断，就在它的中间，就像之前的方法一样。

有什么想法会导致这种情况吗？ 我认为它可能与软重置有关，因为 - 之前的成功率为 100%，之后的成功率为 0%。

到目前为止我所做的尝试：

我正在记录错误，我对所有事情都有一个 try-catch，我已经订阅了 UnobservedException 事件和任务的 Canceled 事件，并且我正在记录暂停计数 - 这些都没有帮助.好像没有错误，没有暂停，也没有取消。
我不时记录当前的内存使用情况，大约是 16-17MB。在我的设备上，限制应该是 30MB，所以我认为这不是问题。
我会尽可能地调用 RequestAccessAsync。我认为一次就足够了，但是由于那个软重置问题，我决定将它放在其他 1-2 个地方以检查它是否导致问题。好吧，它不是，或者至少这没有解决它。

我不确定：

我不知道如何检查我的任务消耗的 CPU 时间。我找不到这样做的好/可靠的方法。此外，我找不到任何信息来解释为什么有时会在中间停止任务，而其他时候 - 它会正常工作。

知道为什么我的后台任务有时会在中间停止吗？我真的很难确定如何修复/改进应用程序以及它是否能正常工作。

谢谢。

【问题讨论】：

呃，很难的问题，就像在 WP 后台任务 have many limits 中一样（你可能已经意识到了 :)。 CPU 配额只有 2 秒 - 也许是这个？你也给RequestAccessAsync打过电话吗？您还通过网络传输任何数据吗？
也许做一些测试：手机通电时有区别吗？您是否有机会运行秒表，并在 LocalSettings 中通知任务运行的时间？你能建立一个简单的任务并在其中等待超过 2 秒，看看它是否被取消？我还假设您正在获得延期。
嘿@Romasz！ :) 感谢您的建议。我知道 3 个限制 - CPU（不知道如何检查）、内存（已检查）、数据传输（未使用）。我经常调用 RequestAccessAsync 。 CPU 约束是针对 CPU 时间，而不是实际运行时间。当它完成所有任务时，任务运行 10-15 秒。手机是否以 20%/100% 的速度充电/使用电池似乎对任务的执行没有任何影响。你的假设是正确的 - 我得到一个延期并在最后（在 finally 块中）调用 Complete 方法。
还有一些 - 你的 Run 是异步的吗？您是否尝试订阅 Competed/Canceled 事件，并在 LocalSettings 中保存一些内容以指示问题？是否有任何消耗 CPU 的操作（我也不知道如何测量 CPU）？如果有，也许有机会放慢一点（Task.Delay(50).Wait()）？您是否有机会与问题分享代码或简单示例？
@Romasz 运行本身不是异步的，但它调用了一个使用延迟的异步方法。没试过 Completed 事件，另外一个好像没有提出来。它消耗 CPU，我可以减慢它的速度，但我不知道这有什么帮助？目前我无法共享代码，因为该任务使用了几个自定义库。我猜它的 CPU 限制是我的问题，但我不知道如何衡量它，我不明白为什么它没问题，然后，在软重置后它停止工作。

标签： windows-runtime windows-phone-8.1 background-task

【解决方案1】：

所以，我想我找到了我的问题所在。

首先，后台任务只是需要大量的 CPU 时间，超过了限制，这就是它在中间被杀死的原因。

它有时工作的原因是，有时我正在测试的设备将应用程序视为处于调试状态（或附加调试器）。在这种情况下，对 CPU 时间的限制就被取消了。

因此，即使我卸载应用程序并在 Release 中重建它并重新部署，并在没有附加调试器的情况下启动它，设备也不会强制执行约束。仅当我在部署后至少使用调试器启动应用程序一次（或者可能是第一次）时，才会发生这种情况。重新启动设备（只需关闭电源然后打开）即可解决此问题。

在我使用相同版本的应用进行测试时，它的后台任务在一台设备上运行了 40 分钟，而在另一台设备上只运行了 3-4 秒。在我重新启动第一台设备后，后台任务开始正常运行（仅运行几秒钟）。

所以，如果您想测试后台任务的 CPU 限制：

您必须在设备上进行测试，而不是在模拟器上。
卸载应用（如果已安装）。
重启设备。
部署应用的发布版本。
运行应用，使其注册后台任务，然后关闭。
等待后台任务被调用。（您可以添加一个可以强制执行的触发器，例如 TimeZoneChanged 或 UserPresent，以便您可以快速对其进行测试。）

附：这可能不是完美的答案，但这些是我的观察结果，它们帮助我解决了我的问题。到目前为止，这是我找到的测试 CPU 时间的最佳方法，但它远非完美。所以，如果有人有更好的想法，请分享。

【讨论】：

这一定很难找到。感谢您的信息。您是否仔细检查过约束是否与 CPU 使用时间有关，或者它是从任务开始计算的？例如，您运行一个任务并执行await Task.Delay(20000);（当然是在某处延迟）-它会被杀死还是运行之后的代码？
@Romasz 跟CPU使用率有关（所以最好用低端设备测试一下，以防万一:)）。 5 分钟后，任务被取消为“空闲”。出于这个原因引发了 Canceled 事件。所以，它可以正常运行大约 5 分钟，如果它不使用过多的 CPU 时间并使用大量的Task.Delay。
感谢您的信息 - 是的，这可能是低端设备的一个不错的陷阱。我想知道是否可以放置某种 Timer，例如在 3 分钟间隔内调用它以延长任务的运行时间 - 我将不得不构建一个简单的示例。再次感谢您提供这些有用的信息。
我也面临同样的问题。即使在 Run 方法中输入，Run 方法代码也不起作用。在它突然退出循环之后。对于同一个 bg 任务，我创建了一个示例项目，它工作正常。我找不到原因。