ios 推送通知在被删除之前在队列中等待多长时间？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/8608849/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How long does a push notification sit in queue before being removed?
提问by NicholasTGD
I've been digging around trying to uncover some data for apple's push notifications for a client and something I have been unable to find an answer to is how long a push notification will sit in queue for an offline device before it will be removed.
我一直在挖掘苹果客户端推送通知的一些数据，但我一直无法找到答案是推送通知在离线设备的队列中等待多长时间才能被删除。
There maybe long periods of time, 2-3 months for example, in which the device maybe inactive and powered off. I'm simply interested in knowing how long I can expect a notification to linger, waiting to be delivered to an offline device, before it gets automatically removed (which is what I understand to be what happens).
可能有很长一段时间，例如 2-3 个月，其中设备可能处于非活动状态和断电状态。我只是想知道在通知被自动删除之前，我可以等待通知停留多长时间，等待发送到离线设备（这就是我理解的情况）。
采纳答案by paislee
Official developer documentation isn't clear about this. From developer.apple.com:
官方开发人员文档对此并不清楚。来自developer.apple.com：
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.
Apple 推送通知服务包括一个默认的服务质量 (QoS) 组件，该组件执行存储转发功能。如果 APNs 尝试传递通知但设备处于离线状态，则 QoS 会存储该通知。它只保留设备上的每个应用程序一个通知：从该应用程序的提供者收到的最后一个通知。当离线设备稍后重新连接时，QoS 将存储的通知转发到设备。 QoS 会在删除通知之前将通知保留一段有限的时间。
But according to PCWorld, it's 28 days:
但根据PCWorld，它是 28 天：
If the app is running, it gets the notification immediately. If the app isn't running, the notification is held in the phone to be consumed at the app's next launch. If the iPhone is offline when the sender attempts delivery, APNS attempts to send the notification for 28 days.
如果应用程序正在运行，它会立即收到通知。如果应用程序未运行，通知将保存在手机中，以在应用程序下次启动时使用。如果发件人尝试递送时 iPhone 处于离线状态，APNS 会尝试在 28 天内发送通知。
While 28 days may have been true in 2009, I wouldn't be surprised if its different today. The ambiguity in the documentation is a great excuse for Apple to change this timeout period willy-nilly.
虽然 2009 年可能是 28 天，但如果今天有所不同，我也不会感到惊讶。文档中的歧义是 Apple 随意更改此超时期限的绝佳借口。
回答by avichalp
Upon digging the docs I found out that we can use 'expiration date' parameter to control the queuing of APNS notifications.
在挖掘文档后，我发现我们可以使用“到期日期”参数来控制 APNS 通知的排队。
Hereis the detailed explanation on the usage of expiration date
这里是关于使用期限的详细说明
apns-expirationA UNIX epoch date expressed in seconds (UTC). This header identifies the date when the notification is no longer valid and can be discarded.
If this value is nonzero, APNs stores the notification and tries to deliver it at least once, repeating the attempt as needed if it is unable to deliver the notification the first time. If the value is
0, APNs treats the notification as if it expires immediately and does not store the notification or attempt to redeliver it.
apns-expiration以秒 (UTC) 表示的 UNIX 纪元日期。此标头标识通知不再有效并可丢弃的日期。
如果此值不为零，APNs 会存储通知并尝试至少传递一次，如果第一次无法传递通知，则根据需要重复尝试。如果值为
0，则 APNs 将通知视为立即过期，并且不会存储通知或尝试重新发送通知。
