ios - 如果用户不打开应用程序而忽略了太多通知，iOS 是否会停止发送静默推送通知？

Question

我们对 iOS 推送通知相对较新，而且一如既往地使用 Apple，我对解决方案的优雅印象深刻，但也对该功能的一些似乎不透明的“幕后”管理感到有点恼火行为。

我的问题是: 在成功收到大约。 10 个单独的静默推送通知以每小时一个的速度，在我们的测试用户最终打开它之前，不再向我们的测试应用程序发送通知。基于此看来，如果 iOS 确定某个应用程序未在使用中，它可能会停止发送静默推送通知。这是预期的行为吗？有谁知道 Apple 为此使用的启发式算法的任何粗略细节？

感兴趣者的测试详情

仅供引用，我们的测试设置如下:

1. 我们构建了一个简单的通知测试应用(使用 application:didReceiveRemoteNotification:fetchCompletionHandler 委托(delegate)方法为 iOS7 构建)
2. 在测试期间，该应用在我们测试的 iPhone 5 的后台保持暂停状态(有时在办公室使用 wifi，有时在伦敦及其周边地区使用 3G)。
3. 我们有一个简单的 Ruby 脚本，它使用 Grocer gem(顺便说一句，这看起来非常好)通过 Apple 的沙盒 APNS 网关每小时向应用程序发送一个静默推送通知。
4. 当应用收到通知时，它会唤醒、写入日志并向我们的后端服务器发出简单请求，该服务器还会记录已发生的事件。

结果:

1. 在前 10 个小时内，一切都完全符合预期。在此之后，该应用将不再收到通知。

通知格式(手工复制，如有错误请见谅):

aps = {
  badge = 2;
  "content-available" = 1;
};

Answer 1

我几个月前对我的应用程序的推送功能做了很多测试，我的一些经验在这里:

1. Apple Push Notification doesn't care about if your app is in use or not.
2. APNS is not 100% reliable, the most influential factor is network quality(your server to APN server,APN servere to your device).
3. I have pushed 10,000 notifications to a iphone4s in 3 minutes, device received more than 95% notifications.So, 10 separate silent push notifications at a rate of one per hour has no pressure.

现在，就您的问题进行一些讨论:

首先:应该意识到通知的第一个接收者是系统，而不是您的应用。

如果您的应用不在前台，则应用的 application:didReceiveRemoteNotification:fetchCompletionHandler 将永远不会被调用，直到您的应用再次进入前台。因此，您的“写入日志并向我们的后端服务器发出简单请求”操作不适合“记录已发生的事件”。

我认为没有一个好的方法来“记录所有发生的事件”，除非你的应用总是在前台。

顺便说一句:当你在测试推送时，如果设备没有快速收到通知，你可以改变设备的网络(或关闭然后打开网络)，有时，通知很快就会来。