【发布时间】：2014-11-07 22:47:33
【问题描述】：
我在应用程序中使用推送通知。一切顺利。
有时消息从服务器发送，但在应用程序端却没有收到。
在这种情况下，我必须知道缺少要传递的消息（应用未收到）。
有什么方法可以从服务器端知道应用程序收到了哪些消息，哪些没有？
【问题讨论】：
标签： ios objective-c iphone push-notification
【发布时间】：2014-11-07 22:47:33
【问题描述】：
不，推送通知是一劳永逸的。
Apple 不会告诉你以下内容：
- 不会告诉消息是否发送成功
- 不会告诉用户是否选择退出推送通知
- 还有很多其他的事情，但无论如何......
然而
另一方面，当用户选择推送通知时，您的应用可以处理此问题，但在一定程度上：
基本上，您可以在-didReceiveRemoteNotification: 和-didFinishLaunchingWithOptions: 中添加逻辑来联系您的服务器并告诉您的服务器已收到消息。
如果在特定时间段内未收到，则可以重新发送。
但如您所见，这可能会导致无辜用户大量收到相同的推送通知。
从某种意义上说，骚扰他点击你愚蠢的推送通知，这反过来可能导致他完全关闭你的应用程序的推送通知，但大多数情况下他会删除该应用程序，甚至给它一个低评价？
为你服务，我会说。
无论如何，如果你继续这样做，你需要实现一个识别模式，你将一个唯一的message identifier 插入到推送通知的有效负载中，当你的应用收到这个推送通知时，它应该发送这个@987654324 @返回服务器。
然后，您的服务器应记录特定设备令牌返回了 message identifier，这意味着它收到了该特定推送通知。
您的服务器可以按小时/每天/任何时间进行检查，并将特定消息重新发送给那些尚未向相关message identifier 报告的设备令牌。
同样，这意味着您的服务器有时可能需要运行 OT。
整个方法还有其他问题：
- 用户收到推送通知但将其关闭而不是使用它打开您的应用程序
- 您的服务器将假定用户没有看到推送通知，并将再次发送此推送通知
- Ghost 设备令牌
- 用户最初接受了推送通知，但后来撤销了此权限
- 用户卸载了应用
- 基本上，曾经用于接收推送通知但现在不再接收的设备令牌，很可能是由于您的消息泛滥声誉所致
- 用户收到推送通知，但稍后点击它
- 可能会多次收到相同的推送通知（非常烦人）
- 用户收到推送通知，但在没有互联网连接时点击它
- 用户收到推送通知，但您的服务器已关闭，可能已烧毁 \m/
您可以通过在应用程序中添加更多逻辑来规避最后 3 种情况，这些逻辑将要发送到服务器的消息 id 排队并仅在服务器成功响应时将其删除。
所以你看，太多的工作，服务器端 + 客户端。
此外，在处理大量用户时，它会极大地降低服务器端的性能，并且会稍微降低应用程序的性能。
【讨论】：
Apple 推送通知服务包括一个反馈服务，用于 为您提供有关失败推送通知的信息。当一个推 无法传递通知，因为预期的应用程序没有 存在于设备上，反馈服务将该设备的令牌添加到 它的清单。在传递之前过期的推送通知是 不被认为是失败的交付并且不影响反馈 服务。通过使用此信息停止发送推送通知 将无法传递，您减少了不必要的消息 开销并提高整体系统性能。
每天查询反馈服务以获取设备令牌列表。采用 验证设备令牌是否未被使用的时间戳 自生成反馈条目后重新注册。对于每个设备 尚未重新注册，停止发送通知。 APNs 监控供应商在检查反馈方面的努力 服务并避免将推送通知发送到不存在的 设备上的应用程序。
【讨论】：
1.如果您询问未在设备上安装了应用程序的设备上发送的通知，并且只是因为通知在发送之前过期或其他原因，则通知不是发送者。
那么答案是
没有。
它不提供支持，您可以在其中检查通知是否已过期并且未在有效设备上传递：
any option to know if apple app get the push notification?
请参阅上述链接中 Moshe 的回答。我在这里包括他的答案，以便将来即使链接失效，它对每个人都有用。
简短的回答是，您不能，因为 APNS 是一种方式。然而，由于一个 应用程序可以在收到通知后执行任意代码，您可以 用这个说，发送一个http请求到你自己的服务器，当 收到通知。
2.如果您询问由于用户已卸载应用程序而未发送通知，那么您可以参考 meda's 在这篇文章中的回答。
希望这对您有所帮助，如果您对我的解释有任何疑问，请告诉我。
【讨论】：
您可以使用 "Service Extension" 并在您的 Push json 中稍作修改，获得推送通知的发送报告，不是来自服务器，而是来自您的应用程序。查看this link了解详细说明。
【讨论】：