在我们正在构建的iPhone应用中，我们使用推送通知有效内容中的"content-available" : 1参数，一旦推送通知到达，就会在应用代理中调用application:didReceiveRemoteNotification:fetchCompletionHandler:。推送通知不是沉默的;我们也在使用＆＃34; alert＆＃34;和＆＃34;声音＆＃34;用于通知用户的参数。我已将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:的调用是非常不可靠的，有时它被调用，有时它不是，即使推送通知总是到达（当然我知道这是因为它不是＆＃39; ta隐藏通知，我看到消息并听到声音。）
还有其他人也有这种经历吗？ iOS可以更加保守吗？在生产环境中调用application:didReceiveRemoteNotification:fetchCompletionHandler:以最大限度地减少对电池寿命的影响？
答案 0 :(得分：1)
Apple关注用户并检查应用程序是否不会耗尽设备的电量，尤其是在后台使用时。如果您的应用程序请求太多资源，系统可能会将您的应用程序的请求推迟到较低优先级队列。这是从文档中提取
一旦完成处理通知，您必须在处理程序参数中调用该块，否则您的应用程序将被终止。您的应用程序有最多30秒的挂钟时间来处理通知并调用指定的完成处理程序块。实际上，您应该在处理完通知后立即调用处理程序块。系统会跟踪应用程序后台下载的已用时间，功耗和数据成本。 处理远程通知时使用大量电量的应用可能无法提前唤醒以处理未来的通知。
还有第二个时刻需要注意
但是，如果用户强行退出，系统不会自动启动您的应用。在这种情况下，用户必须重新启动您的应用程序或重新启动设备，然后系统才会再次尝试自动启动您的应用。