在我们正在构建的 iPhone 应用程序中，我们使用推送通知负载中的 "content-available": 1 参数来调用 application:didReceiveRemoteNotification:fetchCompletionHandler:一旦推送通知到达，就在应用程序委托(delegate)中。推送通知不是无声的；我们还使用“警报”和“声音”参数来通知用户。我已将 remote-notification 值添加到我的 Info.plist 文件中的 UIBackgroundModes 数组。
我注意到当我们使用开发 APNS 环境时，"content-available": 1 参数总是调用 application:didReceiveRemoteNotification:fetchCompletionHandler: 方法推送通知到达(gateway.sandbox.push.apple.com，这是我从 Xcode 运行应用程序时使用的)。不幸的是，当我通过 iTunes Connect 中的 TestFlight 分发应用程序时，情况并非如此(在这种情况下，正在使用生产 APNS 环境，gateway.push.apple.com)。在生产中调用 application:didReceiveRemoteNotification:fetchCompletionHandler: 是非常不可靠的，有时会被调用，有时不会，即使推送通知总是到达(当然我知道这一点，因为它不是不是隐藏通知，我会看到消息并听到声音)。
有没有人也有这样的经历？ iOS 能否在生产环境中调用 application:didReceiveRemoteNotification:fetchCompletionHandler: 时更加“保守”，以尽量减少对电池生命周期的影响？
最佳答案
Apple 关心用户并确保应用程序不会耗尽设备的电池电量，尤其是在后台运行时。如果您的应用请求太多资源，系统可能会将您的应用请求推迟到优先级较低的队列。这是从文档中提取的
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 remote notifications may not always be woken up early to process future notifications.
还有第二个需要注意的时刻
However, the system does not automatically launch your app if the user has force-quit it. In that situation, the user must relaunch your app or restart the device before the system attempts to launch your app automatically again.
关于ios - 使用 "content-available": 1 payload not always calling application:didReceiveRemoteNotification:fetchCompletionHandler: 推送通知，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29218840/