我们对iOS推送通知相对较新，与Apple一样，我对解决方案的优雅印象深刻，但也对似乎对功能行为的一些不透明的"幕后"管理感到愤怒。
我的问题是：在以每小时一个的速度成功接收大约 10 个单独的静默推送通知后，在测试用户最终打开它之前，不会再向我们的测试应用程序发送更多通知。 基于此，如果 iOS 确定应用程序未使用，它似乎可能会停止发送静默推送通知。 这是预期行为吗？ 有谁知道苹果为此使用的启发式方法的任何粗略细节？
有兴趣的人的测试细节
仅供参考，我们的测试设置如下：
- 我们构建了一个简单的通知测试应用（使用
application:didReceiveRemoteNotification:fetchCompletionHandler委托方法为 iOS7 构建） - 在测试期间，该应用程序在我们的测试iPhone 5的后台保持挂起状态（有时在办公室使用wifi，有时在伦敦及其周边地区的3G上）。
- 我们有一个简单的 Ruby 脚本，使用 Grocer gem（顺便说一下，这似乎非常好）通过 Apple 的沙盒 APNS 网关每小时向应用程序发送无声推送通知。
- 当应用程序收到通知时，它会唤醒，写入日志并向我们的后端服务器发出简单的请求，后端服务器也会记录发生的事件。
结果：
- 在前 10 小时内，一切都完全按预期工作。在此之后，应用程序不会再收到通知。
通知格式（手动复制，请原谅任何错误）：
aps = {
badge = 2;
"content-available" = 1;
};
几个月前，我对我的应用程序的推送功能进行了大量测试，这是我的一些经验：
- Apple 推送通知不关心您的应用程序是否正在使用中。
- APNS 不是 100% 可靠的，最有影响力的因素是网络质量（您的服务器到 APN 服务器，APN 服务器到您的设备）。
- 我在 10,000 分钟内向 iphone4s 推送了 3 条通知，设备收到了超过 95% 的通知。所以，10个单独的沉默 每小时一个推送通知没有压力。
现在，对您的问题进行一些讨论：
首先：应该意识到通知的第一个接收者是系统，而不是你的应用程序。
如果你的应用不在前台，则永远不会调用应用的应用程序：didReceiveRemoteNotification：fetchCompletionHandler，直到你的应用再次进入前台。因此，您的"写入日志并向我们的后端服务器发出简单请求"操作不适合"记录发生的事件"。
我认为没有一种好方法可以"记录发生的所有事件"，除非您的应用程序始终处于前台。
顺便说一句：当您测试推送时，如果设备没有快速显示通知，您可以更改设备的网络（或关闭然后打开网络），有时，通知很快就会到来。
我可以想象你所看到的行为有三个原因：
- 您的应用程序在您不看时崩溃，
- 用户已强制关闭您的应用，
- 系统已重新启动。
这些是你的应用将不再启动以接收后台通知的唯一情况。现在，您需要调试其中哪一个适用。