iOS APNS“尽力而为”后备

Posted 2023-02-24

【中文标题】iOS APNS“尽力而为”后备

【英文标题】：iOS APNS "best-effort" fallback

【发布时间】：2014-10-10 15:22:00

【问题描述】：

我似乎无法理解这一点。文档中所述的 APNS 已尽力交付，即无法保证交付。但是，如果我要在我的客户端/服务器应用程序中使用推送通知模型，我必须以某种方式使用它们。

一般模型如下：服务器上有新数据 -> 服务器然后发送推送通知通知客户端有新数据可用 -> 客户端下载新数据。

那么问题是，如果我不能 100% 依赖要传递的通知，我可以使用什么样的回退机制来确保客户端接收到服务器上可用的新数据？使用 APNS 确保客户端拥有最新数据的方法是什么？

【参考方案1】：

使用 APNS 确保客户端拥有最新数据的方法是什么？

只是 APNS 无法做到这一点。当应用程序被带到前台时，您的客户端需要查询您的服务器以查看是否有新数据，无论您可能丢失或收到任何推送通知。

【讨论】：

是的，我也在想同样的事情。我无法理解的是 - 如果客户端每次将应用程序带到前台时都会查询服务器，那么 APNS 的意义何在？回想起来，这让我认为，如果我不能依赖 APNS，如果我无论如何都必须查询服务器，那么使用它们有什么意义呢？谢谢。

关键是当应用程序在后台时能够在设备上显示警报或触发其他操作。或者允许应用程序避免在前台轮询新数据。与每 N 秒/分钟轮询一次相比，在应用程序启动时检查新数据的频率要低得多。

因此，如果应用程序在前台并且用户正在与之交互，并且服务器上有新数据并且未传递通知 - 那么客户端如何知道获取新数据?我看到的唯一选择是轮询或做一些愚蠢的事情，比如在每个 viewWillAppear:

上更新数据

我的意思是你不能保证通过any机制交付，因为网络并不完美。您所能做的就是稍后再试；当那个“稍后”是（viewWillAppear：，进入前台等）取决于你。如果 APNS 未能传递您的通知，您将在下次轮询尝试时发现有新数据。因此，您必须在某个时候进行投票；您可以减少使用 APNS 的频率，因为它通常可以快速可靠地交付内容。

答案是：视情况而定。我肯定会在进入前台时检查新数据，但是您是否还应该检查 viewDidAppear 或类似内容实际上取决于您的数据更改频率、视图之间共享多少数据等。您甚至可以考虑以下内容：检查在 viewDidAppear 上，但前提是至少经过 2 分钟。

【参考方案2】：

这完全取决于您计划如何使用 APNS。

假设您正在制作一个销售 eBay 等商品的应用程序。你有： - 多个用户出价 - 物品关闭时间倒计时

您不会使用 APNS 来更新个人设备上的计时器或通知他们物品的当前价格。这些太重要了，不能依靠尽力而为的交付，也不是 APNS 的预期用途。

在这种情况下，最好让应用每 X 秒轮询一次服务器以获取更新信息。然后，您可以将 APNS 用于非关键功能，例如通知用户他们是否出价过高或他们是否赢得了物品。