windows-phone-8 - 让 Windows Phone 8 资源密集型任务运行的任何提示？

Question

在部署到手机几天后，我一直试图让一个资源密集型任务后台代理在 Release模式下运行，但从未见过它运行。有没有人让它在调试器之外工作？你需要等多久才能运行？

我能够使用 LaunchForTest 启动并成功运行资源密集型任务，但从未让它在 Release模式下正常运行，即使该任务显示它已被安排。我已经按照示例进行操作，手机应该已满足发布要求。我已经将 list 设置为自动上传，因此不需要为任务设置到期日期。

手机已插入并充电，电池电量为 100%。
手机有wifi。
手机在锁定屏幕上，并在此过夜 2 晚。

我在诺基亚 Lumia 920 和 HTC699OL 上都试过了

我可以运行周期性任务，但不能运行资源密集型任务。如果定期运行，我假设我已经在 WMAppManifest 中正确配置了所有内容，并且资源密集型任务应该在某个时候运行？

资源密集型任务显示以下内容:

IsEnabled = true

IsShceduled = 真

最后预定时间:1/1/0001 12:00:00

到期时间:12/31/9999 11:59:59

LastExitReason:无

该应用程序显示在“设置”>“后台任务”>“高级”中。

运行 Store Kit 测试显示电话应用程序没有 API 调用问题，我从主电话应用程序项目中引用了代理项目。

这是我的代理 WMAppManifest 设置:

<ExtendedTask Name="BackgroundTask">
    <BackgroundServiceAgent Name="SML.Sync.WP8.Agent" Specifier="ScheduledTaskAgent" Source="SML.Sync.WP8.Agent" Type="SML.Sync.WP8.Agent.BackgroundUploadAgent" />
</ExtendedTask>

根据此处的 MSDN 文档，这似乎是正确的: MSDN Task Element documentation

这是自动上传扩展，它跟在 Tokens 节点之后:

<Extensions>
  <Extension ExtensionName="Photos_Auto_Upload" ConsumerID="{5B04B775-356B-4AA0-AAF8-6491FFEA5632}" TaskID="_default" />
</Extensions>

我也在没有自动上传设置的情况下尝试过它并且从不运行的结果相同。

我也尝试从这里获取示例 http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202941(v=vs.105).aspx运行，但在删除 debug_agent 并部署为 Release模式后，我看到了同样的问题，即使它说它是预定的，也永远不会运行 - 定期运行只是不占用资源。

我知道文档说它可能永远不会运行，但似乎 2 天过去了，满足任务要求应该可行。我需要等一个星期才能看到这个傻瓜运行吗？

如果您收到了 的任何指导或提示，我们将不胜感激。资源密集型任务 实际在 Release模式下运行。

Answer 1

我在 2013 年 2 月 4 日向 Microsoft 发起了一个支持事件，并在 2 月 5 日收到了他们的回复，内容如下:

I collaborated with the internal Windows Phone developers and confirmed the following:

1. ResourceIntensiveTask (i.e. Resource Intensive Agent) does not get triggered in the Windows Phone 8 operating system in Release Mode.
2. FYI, Auto-upload uses ResourceIntensiveTasks, so it does not work in WP8 either.
3. A fix is scheduled for inclusion in a future Windows OS update, most likely later this spring. The fix needs to propagate through the OEMs who build their hardware-specific versions of the Windows Phone 8 OS.
4. There is no known immediate/official workaround.