接收 iPhone 关闭时奇怪的 Apple 推送通知行为
当接收方 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 推送通知服务包括执行存储和转发功能的默认服务质量 (QoS) 组件。如果 APNS 尝试发送通知但设备处于离线状态，则 QoS 会存储该通知。它只为设备上的每个应用程序保留一个通知：从该应用程序的提供商收到的最后一个通知。当离线设备稍后重新连接时，QoS 会将存储的通知转发给该设备。 QoS 将通知保留一段有限的时间，然后再将其删除。
有人见过这种行为吗？我只是遇到了某种时间窗口错误吗？应该发生什么？
更新：
- 如果我关闭手机并等待 5 到 15 分钟再发送任何推送通知，则不会出现此问题。在这种情况下，当我打开手机时，我看不到任何通知弹出窗口，尽管我不确定这是否是苹果删除通知的结果，或者他们的“队列”正常工作（即保留最新的空白通知）第一个带有弹出窗口的）。
-我将通过将 APNsLogging.mobileconfig 放置到 iPhone 上来进一步调查，以查看它收到了哪些通知。
- 关闭 wifi 似乎不会改变结果。
-我已针对这种情况向 Apple 提出了错误报告。
I'm seeing some very strange behaviour from the Apple Push Notification Servers when the recipient iPhone is off. Here is my scenario:
-Send push notification A to Apple. Within a few seconds a push notification popup gets displayed as expected on the iPhone.
-Send blank notification to Apple to cancel previous one (the previous notification is pointless after about 10 seconds, that's why I want to get rid of it). Nothing displayed on the iPhone.
-Turn OFF iPhone completely (not asleep, it is powered down).
-Send push notification B to Apple. Wait 10 seconds.
-Send blank notification to Apple to cancel previous one. Wait 10 seconds.
-Send push notification C to Apple. Wait 10 seconds.
-Send blank notification to Apple to cancel previous one. Wait 30 seconds.
-Turn ON iPhone.
-After about 60 seconds a push notification popup is displayed for notification B on the iPhone.
-Notification C never seems to arrive.
This is very strange! From reading the Apple docs I was expecting only the latest push notification to be sent. I was hoping my blank notification would be sent, I certainly wasn't expecting the oldest unsent push notification to be sent!
The Apple docs say:
Apple Push Notification Service includes a default Quality of Service (QoS) component that performs a store-and-forward function. If APNS attempts to deliver a notification but the device is offline, the QoS stores the notification. It retains only one notification per application on a device: the last notification received from a provider for that application. When the offline device later reconnects, the QoS forwards the stored notification to the device. The QoS retains a notification for a limited period before deleting it.
Has anybody seen this behaviour? Am I just hitting some sort of timing window bug? What should happen?
Updates:
-If I turn the phone off and wait 5 to 15 minutes before sending any push notifications then this problem doesn't occur. In this case when I turn the phone on I don't see any notification popup, although I'm not sure if this is a result of Apple dropping the notification, or their 'queue' working correctly (i.e. holding the newest blank notification instead of the first one with the popup).
-I will investigate further by putting an APNsLogging.mobileconfig onto the iPhone to see what notifications it got.
-Turning wifi off doesn't seem to change the results.
-I have raised a bug report with Apple for this scenario.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可能需要在蜂窝网络和 WiFi 网络上检查此行为。当手机使用 WiFi 时，会出现很多奇怪的行为，尤其是在涉及多个 NAT 路由器的情况下，即在一个大公司中，有一个主路由器和每层 WiFi 路由器，或者在一个有多个路由器的家庭中扩大范围。但在手机上，它非常坚固。
此外，10 秒的取消延迟可能也太接近了。他们不保证及时交付，在排队推送请求后，我在生产服务器上出现了长达 3 分钟的延迟。您可能需要针对系统拥塞制定计划。
不管怎样，听起来它可能值得错误报告者报告。
You may want to check for this behavior across both the cellular and WiFi networks. There's a lot of strange behavior when the phone is on WiFi, especially if there are multiple NAT router involved, i.e. in a large corporation where there's a main router and per-floor WiFi routers, or in a home where you have multiple routers used to extend the range. But on cell it's been pretty solid.
Also, the 10-second cancellation delay may be cutting it too close. They don't guarantee timely delivery and I've gotten lags of as much as 3 minutes on the production server after queuing off a push request. You may want to plan for system congestion.
Either way, it sounds like it might be worthy of a bugreporter report.
作为记录，我于 10 月 29 日向 Apple 提出了此错误 ID #7349660 (https://bugreport.apple.com< /a>），然后在 10 月 30 日向他们提供了他们想要的额外诊断。
此后 Apple 没有做出任何回应，所以我假设这可能在他们的优先级列表中排在较低的位置，这很公平，因为它是一个相当小的时间窗口问题可能发生的地方（当我第一次打开这个问题时我没有意识到）。
For the record, I raised this as bug ID #7349660 with Apple on 29th Oct (https://bugreport.apple.com), then gave them the additional diagnostics they wanted on 30th Oct.
No response from Apple since then, so I am assuming this is probably just low on their priority list, which is fair enough as it is quite a small timing window where the problem can occur (which I didn't realize when I first opened this question).
苹果的文档中说，它可以将推送通知缓存最多30天。因此，一旦您打开iPhone，您就可以收到推送（前提是您已联网）
In apple's document it is said that it can cache the push notification up to 30 days.so u may get push once you switch on your iphone (provided you are having interconnection)
C 在 B 之后多久被发送？看起来这可能是一个错误，服务器端存在某种超时，如果 C 发送得太快，他们会意外地保留 B...
如果你有一个很好的测试示例（这似乎是一个很好的测试）我会就此提交雷达报告。
How soon was C sent after B? It seems like it may be a bug where there's some kind of timeout server side, and they accidentally keep B if C was sent too soon after...
If you have a good test example (and this seems like a good test) I would file a Radar report on this.