问只有当设备正在充电和/或app是前台时才发送静默推送通知

EN

我们经历过同样的行为，并一直试图理解为什么iOS决定交付一些通知而不是其他通知。

到目前为止，我们得出的结论是：

• 在无线网络上，信息在后台接收比在蜂窝数据上更可靠。事实上，在蜂窝网络(3g/4g)上，如果信号强度不够强，iOS会收到推送消息，但不会唤醒应用程序。我们在苹果论坛上发布了这方面的信息：https://devforums.apple.com/message/1069814#1069814。我们还打开了一张支持票，支持小组告诉我们把它作为bug报告提交给我们，我们几周前就这样做了，现在还在等待回复。
• 当您收到推送消息时，需要尽快调用fetchCompletionHandler。从技术上讲，您有30秒的时间来执行后台处理，但是iOS有一个公式，您越频繁地发送推送消息，并且根据处理这些消息的时间，在将应用程序返回到挂起状态之前，iOS可以减少应用程序在将来被唤醒的次数。

参见苹果didReceiveRemoteNotification:fetchCompletionHandler：文档中的以下内容：

一旦处理完通知，就必须调用处理程序参数中的块，否则应用程序将被终止。您的应用程序有30秒的挂钟时间来处理通知并调用指定的完成处理程序块。实际上，一旦处理完通知，就应该立即调用处理程序块。该系统跟踪您的应用程序后台下载所需的时间、功耗和数据成本。在处理推送通知时使用大量能量的应用程序可能并不总是早早被唤醒，以处理未来的通知。

在我们的测试中，我们一直在向应用程序发送频繁的无声推送通知(每10-30秒)。在我们让它重新入睡之前，这个应用程序已经醒了大约3秒。我们已经注意到，随着时间的推移，我们的应用程序被唤醒的频率下降到了iOS每15-30分钟才会唤醒应用程序的程度。因此，似乎有某种衰减/节流公式到位，但我们找不到任何关于它的确切工作方式的文档。我们已经要求苹果提供这个公式和变量作为支持请求，但是他们说“您所要求的信息是不可公开的”，并再次要求我们提交一份bug报告。

希望这能帮上忙？我们仍在努力学习更多的知识，这也是我发现这个问题的原因:)

随着iOS8背景的改变，向应用程序的推送已经发生了变化。后台推送现在只会交付到应用程序在某些情况下。苹果没有明确说明这些情况到底是什么，但从我广泛的实验来看，基本上可以归结为手机是否被充电。还有一些其他变量在起作用(如网络类型、设备类型、启用wifi )，但主要因素是推到时设备是否正在充电。

如果手机是通过直接电源充电的，或者是通过USB连接到电脑上间接充电的话，那么后台推送就会在大部分时间被传送到应用程序上。但是将手机与电源或USB断开，即使手机的面糊有100%的电量，后台推送也几乎永远不会送到应用程序上。

你可以很容易地为你自己测试，只需发送一些推送时，手机是充电的，而不是它。但是，您必须考虑到，开发生成和使用沙箱环境的背景推送与生产生成和生产环境的背景推送不同，背景推送实际上更有可能在开发过程中传递给应用程序，而不是在生产中，所以使用生产构建和Apple的生产环境进行测试以查看实际结果是非常重要的。

注意:推送有两个步骤，第一个步骤是它需要被传送到手机本身，第二个步骤是一旦手机有了它，它就需要被操作系统交付到应用程序。在iOS7中，像图灵一样的事情使得推到电话的机会增加了。然而，使用iOS8，即使推送成功地送到了手机上，如果手机不充电，操作系统也不会将其转发到后台应用程序。这意味着，如果手机不充电的话，手机会收到通知并持有它，有时会持续几个小时，然后再将其转发到应用程序。

我也经历过同样的问题，当应用程序不充电时，没有收到推送通知的原因是，当从Settings > Battery启用低功耗模式时，它会禁用所有应用程序的background-fetch功能。

防止设备接收推送通知。

这个链接可能是有用的。苹果文档