3

当接收方 iPhone 关闭时,我看到来自 Apple Push Notification Servers 的一些非常奇怪的行为。这是我的场景:

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

这很奇怪!通过阅读 Apple 文档,我期望只发送最新的推送通知。我希望我的空白通知会被发送,我当然没想到会发送最旧的未发送推送通知!

苹果文档说:

Apple Push Notification Service 包括一个默认的服务质量 (QoS) 组件,该组件执行存储和转发功能。如果 APNS 尝试发送通知但设备处于离线状态,则 QoS 会存储通知。它只为设备上的每个应用程序保留一个通知:从该应用程序的提供者处收到的最后一个通知。当离线设备稍后重新连接时,QoS 会将存储的通知转发给设备。QoS 将通知保留一段有限的时间,然后再将其删除。

有人见过这种行为吗?我只是遇到某种时间窗口错误吗?应该发生什么?

更新: -
如果我在发送任何推送通知之前关闭手机并等待 5 到 15 分钟,则不会发生此问题。在这种情况下,当我打开手机时,我看不到任何通知弹出窗口,尽管我不确定这是否是苹果放弃通知的结果,或者他们的“队列”工作正常(即持有最新的空白通知)的第一个弹出窗口)。
-我将通过将 APNsLogging.mobileconfig 放到 iPhone 上来进一步调查,以查看它收到了哪些通知。
- 关闭 wifi 似乎并没有改变结果。
-我已经针对这种情况向 Apple 提出了错误报告。

4

4 回答 4

3

您可能需要在蜂窝网络和 WiFi 网络中检查此行为。当手机在 WiFi 上时会出现很多奇怪的行为,尤其是在涉及多个 NAT 路由器的情况下,即在一个有主路由器和每层 WiFi 路由器的大公司中,或者在你有多个路由器的家中扩大范围。但在手机上,它非常可靠。

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

不管怎样,听起来它可能值得一个 bugreporter 报告。

于 2009-10-28T18:03:37.537 回答
1

作为记录,我在 10 月 29 日向 Apple 提出了这个错误 ID #7349660 ( https://bugreport.apple.com ),然后在 10 月 30 日向他们提供了他们想要的额外诊断。

从那以后Apple没有回应,所以我假设这可能只是他们的优先级列表中的低位,这很公平,因为它是一个可能发生问题的非常小的时间窗口(当我第一次打开这个时我没有意识到问题)。

于 2009-12-14T22:42:48.820 回答
0

在苹果的文档中,据说它可以缓存推送通知长达 30 天。所以一旦你打开你的 iPhone,你可能会得到推送(前提是你有互连)

于 2009-10-28T18:23:31.523 回答
0

C 在 B 之后多久被发送?似乎这可能是一个错误,其中存在某种超时服务器端,如果 C 被发送得太早,他们会不小心保留 B ...

如果您有一个很好的测试示例(这似乎是一个很好的测试),我会就此提交一份雷达报告。

于 2009-10-28T23:34:55.530 回答