仅当设备正在充电和/或应用程序处于前台时才会发送静默推送通知 [英] 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.

我正在使用 UILocalNotification，所以我知道正在接收什么.

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.

此行为可在运行 IOS 8 或 8.1 的 iPhone 5s、6 和 iPad 2 上重复.

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 会收到推送消息，但不会唤醒您的应用程序.我们在苹果论坛上发布了关于它的信息:https://devforums.apple.com/message/1069814#1069814.我们还开出了一张支持票，支持团队告诉我们将其作为错误报告提交，我们几周前就这样做了，目前仍在等待回复.

• Messages will get received more reliably in background when on wifi than 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.

从 Apple didReceiveRemoteNotification:fetchCompletionHandler: 文档:

完成通知处理后，您必须致电在 handler 参数中阻止，否则您的应用程序将被终止.你的应用程序有长达 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屋！