接收iPhone关闭时，Apple推送通知行为很奇怪

Question

当收件人iPhone关闭时，我看到Apple推送通知服务器出现了一些非常奇怪的行为。这是我的情景：

  

- 向Apple发送推送通知A.在几秒钟内，推送通知弹出窗口会在iPhone上按预期显示    - 向Apple发送空白通知以取消之前的通知（大约10秒后，之前的通知毫无意义，这就是我想摆脱它的原因）。 iPhone上没有显示任何内容    - 完全关闭iPhone（不要睡着，关机）    - 向Apple发送推送通知B.等10秒钟    - 向Apple发送空白通知以取消之前的通知。等10秒钟    - 向Apple发送推送通知C.等10秒钟    - 向Apple发送空白通知以取消之前的通知。等待30秒    - 打开iPhone。
   - 大约60秒后，在iPhone上显示通知B的推送通知弹出窗口    - 通知C似乎永远不会到来。

这很奇怪！通过阅读Apple文档，我期待只发送最新的推送通知。我希望我的空白通知会被发送，我当然不希望发送最早的未发送推送通知！

Apple文档说：

  

Apple推送通知服务包括执行存储转发功能的默认服务质量（QoS）组件。如果APNS尝试发送通知但设备处于脱机状态，则QoS会存储通知。它在设备上每个应用程序仅保留一个通知：从该应用程序的提供程序收到的最后一个通知。当离线设备稍后重新连接时，QoS将存储的通知转发给设备。 QoS会在删除之前保留有限时间段内的通知。

有人看到过这种行为吗？我只是遇到某种时间窗错误吗？会发生什么？

更新：
- 如果我关闭手机并等待5到15分钟后再发送推送通知，则不会出现此问题。在这种情况下，当我打开手机时，我没有看到任何通知弹出窗口，虽然我不确定这是Apple放弃通知的结果，还是他们的“队列”正常工作（即保持最新的空白通知弹出的第一个。） - 我将进一步调查，将APNsLogging.mobileconfig放到iPhone上，看看它收到了什么通知 -Turning wifi off似乎没有改变结果。
- 我已经针对这种情况向Apple提出了错误报告。

Answer 1

您可能希望在蜂窝和WiFi网络上检查此行为。当手机在WiFi上时有很多奇怪的行为，特别是如果涉及多个NAT路由器，即在有大型公司的主路由器和每层WiFi路由器的情况下，或者在有多个路由器的家庭中扩大范围。但是在细胞上，它一直非常稳固。

此外，10秒的取消延迟可能会将其切得太近。他们不保证及时交付，在排队推送请求后，我在生产服务器上遇到了多达3分钟的滞后。您可能想要计划系统拥塞。

无论哪种方式，听起来它可能值得一个bug报告报告。

Answer 2

为了记录，我在10月29日（https://bugreport.apple.com）向Apple提出了错误ID＃7349660，然后在10月30日给了他们想要的额外诊断信息。

从那以后Apple没有回应，所以我假设这可能只是他们的优先级列表中的低，这是公平的，因为它是一个很小的时间窗口，问题可能发生（我没有意识到我首先打开这个问题）。

Answer 3

在Apple的文档中，据说可以将推送通知缓存最多30天。一旦你打开你的iphone，你可能会被推送（假设你有互连）

Answer 4

B在B之后多久发送？看起来它可能是一个存在某种超时服务器端的错误，如果C在......之后很快被发送，它们会意外地保留B ...

如果你有一个很好的测试例子（这看起来是一个很好的测试），我会就此提交雷达报告。