如果用户因未打开应用程序而忽略太多推送通知,iOS是否会停止提供静默推送通知？

Question

我们对iOS推送通知相对较新,而且与Apple一样,我对解决方案的优雅感到印象深刻,但对于该功能行为的一些不透明的"幕后"管理也略有激怒.

我的问题是: 成功收到约.10个单独的静音推送通知,每小时一个,在我们的测试用户最终打开之前,我们的测试应用程序不再提供.基于此,如果确定应用未被使用,iOS可能会停止提供静默推送通知.这是预期的行为吗？有没有人知道关于Apple使用的启发式的粗略细节？

有兴趣者的测试详情

仅供参考,我们的测试设置如下:

1. 我们构建了一个简单的通知测试应用程序(使用application:didReceiveRemoteNotification:fetchCompletionHandler委托方法为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 推送通知并不关心您的应用程序是否正在使用。
2. APNS 不是 100% 可靠，影响最大的因素是网络质量（您的服务器到 APN 服务器，APN 服务器到您的设备）。
3. 我在 3 分钟内向 iphone4s 推送了 10,000 条通知，设备收到了超过 95% 的通知。因此，以每小时 1 条的速度发送 10 条单独的静默推送通知毫无压力。

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

第一：应该意识到通知的第一个接收者是系统，而不是您的应用程序。

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

我认为没有一个好方法来“记录所有发生的事件”，除非您的应用程序始终位于前台。

BTW：当您测试推送时，如果设备没有很快收到通知，您可以更改设备的网络（或关闭然后打开网络），有时，通知很快就会到来。