无声推送通知仅当交付设备充电和/或应用软件前景 [英] Silent push notifications only delivered if device is charging and/or app is foreground

问题描述

我已经实现无声推送通知，但我注意到一些奇怪的行为。沉默的推送通知是通过处理：

I have implemented silent push notifications but I have noticed some strange behaviour. The silent push notifications are handled via:

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler

无声推送消息似乎只是如果设备充电可收（即线连接）和/或如果我的应用程序是前景。

The silent push messages only seem to be received if the device is charging (ie cable connected) and/or if my app is foreground.

如果我从充电器断开设备（或Mac），然后无声推送通知，不再接收的除非的应用程序是前景。

If I disconnect the device from the charger (or Mac) then the silent push notifications are no longer received unless the app is foreground.

我得到非无声推送通知通常在两种情况下。

I get non-silent push notifications normally in both cases.

如果我在插入USB电缆一遍，然后我得到接收不管应用程序是否是前景或背景的预期行为和无声推送通知。

If I plug in the USB cable again, then I get the expected behaviour and silent push notifications are received irrespective of whether the app is foreground or background.

所以我知道正在接收的内容。

I am using UILocalNotification so I know what is being received.

这一切工作正常连接的设备的事实表明，我的沉默推通知被正确配置，该应用程序已在plist中等等设置正确的背景模式。

The fact that it all works fine with the device connected suggests that my silent pushes notifications are configured correctly and that the app has the correct background modes set in the plist etc.

此行​​为是在iPhone 5S，6和iPad 2都重复运行的是IOS 8或8.1。

This behaviour is repeatable on iPhone 5s, 6 and iPad 2 all running either IOS 8 or 8.1.

有没有其他人经历过这个？它应该很容易重现。插入一个设备插入充电器的简单行为为什么要改变接收无声推送通知的能力？

Has anyone else experienced this? It should be easy to reproduce. Why should the simple act of plugging a device into a charger change the ability to receive silent push notifications?

推荐答案

我们已经经历过同样的行为，并一直在试图理解为什么iOS的决定提供一些通知，而不是别人。

We have experienced the same behavior and have been trying to understand why iOS decides to deliver some notifications and not others.

我们已经制定了迄今为止为：

What we have worked out so far is:

• 邮件将在后台接受得到更可靠时的wifi然后在蜂窝数据。事实上，当蜂窝网络（3G / 4G）上，如果你的信号强度不够强，iOS的接收推送消息，但不会唤醒你的应用程序。我们张贴在它这里的苹果论坛：<一href=\"https://devforums.apple.com/message/1069814#1069814\">https://devforums.apple.com/message/1069814#1069814.我们还开辟了支持票，而支持团队告诉我们要提出它作为一个bug报告，这是我们一个几个星期前，没有和仍在等待回音。

• Messages will get received more reliably in background when on wifi then on cellular data. In fact, when on a cellular network (3g/4g), if your signal strength isn't strong enough, iOS receives the push message, but will not wake up your app. We posted in the apple forums about it here: https://devforums.apple.com/message/1069814#1069814. We also opened up a support ticket, and the support team told us to lodge it as a bug report, which we did a couple of weeks ago and are still waiting to hear back.

当您收到推送消息，你需要尽快致电fetchCompletionHandler。从技术上讲，你有30秒的执行后台处理，但iOS的在地方有一个公式，从而越频繁发送推送消息，取决于你花在处理这些消息的时间量的应用程序返回到暂停状态之前，iOS设备可以减少用量次您的应用程序获取未来唤醒。

When you receive a push message, you need to call the fetchCompletionHandler as soon as possible. Technically you have 30 seconds to perform background processing, but iOS has in place a formula whereby the more frequently you send push messages and depending on the amount of time you spend processing those message before returning the app to suspended state, iOS can reduce the amount of times your app gets woken up in the future.

在这里看到从<一个href=\"https://developer.apple.com/library/ios/documentation/uikit/reference/uiapplicationdelegate_protocol/index.html#//apple_ref/occ/intfm/UIApplicationDelegate/application:didReceiveRemoteNotification:fetchCompletionHandler:\">Apple didReceiveRemoteNotification：fetchCompletionHandler：文档：

一旦你完成处理通知，必须调用
  在处理程序参数或您的应用程序块将被终止。你的
  应用程序有挂钟时间长达30秒的处理
  通知和调用指定完成处理程序块。在
  实践中，你应该尽快完​​成后调用处理程序块
  处理该通知。系统跟踪经过的时间，功率
  使用情况，并为您的应用程序的后台下载数据的成本。该应用程序
  处理推送通知时使用的显著的功率的
  可能并不总是被唤醒早来处理将来的通知。

As soon as you finish processing the notification, you must call the block in the handler parameter or your app will be terminated. Your app has up to 30 seconds of wall-clock time to process the notification and call the specified completion handler block. In practice, you should call the handler block as soon as you are done processing the notification. The system tracks the elapsed time, power usage, and data costs for your app’s background downloads. Apps that use significant amounts of power when processing push notifications may not always be woken up early to process future notifications.

在我们的测试中，我们一直频繁地发送无声推送通知到我们的应用程序（每10 - 30秒）。而应用程序是醒约3秒钟，我们把它放回去睡觉前。我们肯定在一段时间注意到在我们的应用程序被唤醒的地步，iOS将只醒来应用程序每15频率的降低 - 30分钟。因此，似乎有某种到位衰变/节流式的，但我们无法找到它究竟是如何工作的任何文件。我们要求这个公式，并从苹果作为支持请求中的变量，但他们说，您所请求的信息不公开，并再次要求我们提交错误报告。

In our testing, we have been sending frequent silent push notifications to our app (every 10 - 30 seconds). And the app is awake for about 3 seconds before we put it back to sleep. We have definitely noticed over time a degradation in the frequency in which our app gets woken up to the point where iOS will only wake up the app every 15 - 30 minutes. So there seems to be some sort of decay/throttling formula in place, but we cannot find any documentation on how it exactly works. We have requested this formula and the variables from apple as a support request, but they said "The information you are requesting is not publicly available" and again asked us to file a bug report.

所以，我希望这是有益的？我们仍然在努力学习更多自己这就是为什么我发现这样一个问题：）

So, hopefully this is helpful? We are still trying to learn more ourselves which is why I found this question :)

这篇关于无声推送通知仅当交付设备充电和/或应用软件前景的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！