ios - Websockets 与 iOS 推送通知

Question

以 Instagram 这样的 iOS 应用为例。 Instagram 从根本上说是一个实时应用程序，只要用户与您交互，它就会更新其 UI。例如，如果有人喜欢您的帖子并且您正在使用该应用程序，则 UI 会更新以触发多巴胺释放并通知您您的一个帖子发生了某些事情。同样，当有人在 Instagram 上向您发送直接消息时，在使用该应用程序时，您会看到消息从顶部实时弹出。
在实现这样的实时功能方面，很明显，简单的 HTTPS 轮询方法效率太低了。因此，这留下了两种策略:
1.) APNS 推送通知:
当用户喜欢帖子、发送直接消息、评论(等)、向后端服务器发送 HTTP POST 时，后端服务器将更新数据库并向收件人的设备发送静默 Apple 推送通知。使用该应用程序的接收者将接收推送的有效负载，并将向后端服务器发送 HTTP GET 以获取所需的数据(即发送的直接消息的内容)。用户界面准“实时”更新。
2.) 网络套接字:
每当任何用户打开 iOS 应用程序时，通过 websocket 将用户连接到服务器。这意味着，当前使用该应用程序的所有用户都通过他们自己的 websocket 连接到服务器。当用户喜欢帖子、发送直接消息、评论(等)时，应用程序通过套接字向服务器发送一条消息，指示操作。服务器在更新数据库之前，找到与接收者关联的套接字，并通过套接字将消息转发给接收者。收到消息后，实时更新UI
这些方法中哪一种是可扩展的并且更适合生产环境？

Answer 1

TL;DR 你会喜欢 websockets + Combine 框架，事件驱动可以平滑地更新你的 UI。 APNS 在可交付性和资源/数据库成本方面可能有些不可靠，对我来说更像是一个信息中心。
喜欢 websockets 的原因:

降低数据库成本(例如查找要发送到的设备)

您知道用户何时不使用该应用程序，从而降低出站数据成本

实际上，延迟和更快(在 websocket 段落中更深入)

回答这个问题:websockets 显然可以根据您的用户数量进行扩展。 APNS 不能在 CI 中进行服务器端测试，不能跨平台，并且在资源消耗方面也不完全可行。

我对 websockets 有偏见。但是要说明为什么我更喜欢它，请考虑一下您的 Instagram 示例给出的效率。
对我来说，websockets == Event Driven，APNS 是一个简单的信息中心。
接入点:
您注册 APNS 并将设备保存在后端。太好了，每次执行操作时，例如有人喜欢您的帖子，查询您的后端，找到链接到 OP 的设备，然后将其发送出站(如果您认为云计算成本很高，则需要花钱)。每次有人喜欢你的帖子时，你都必须这样做(显然你可以聚合，但是当你有 websockets 时为什么要费心呢？)。 所以数据库成本是需要考虑的一件事 .此外，用户可能会静音他们的通知。我没有 Instagram，但他们本可以做的一些效率明智的事情(如果不是通过套接字)是根据喜欢/心的传入通知而不是 websocket 连接更新他们的 UI。如果标记为垃圾邮件，这在延迟方面很慢，成本高昂且不可靠。然而，与 websockets 不同，APNS 的优点是不需要授权，但是......
网络套接字:
当我们接近 websockets 时，您只授权一次(至少对于移动应用程序)。您通过删除 header 之类的内容来消除出站数据成本(就 $$ 和延迟而言)。您想发送小块数据，而套接字只是发送文本/二进制文件(我喜欢使用 JSON 从中创建命令。一个显着的例子是 GitHub)。当您的用户使用完该应用程序后，您将关闭连接，并且不再需要通过 APNS 发送数据。您的服务器本身可以通过诸如 Redis PubSub 之类的东西与单个 websocket 通信，以便在有人使用 POST 请求来关注帖子时更新您的 UI，而无需发送一些推送通知。这对于喜欢者(不需要等待发送推送通知)或其他方式(如果您将其卸载到后台任务(OP 不需要等待))来说是一种胜利。 Websockets == 事件驱动:

不断交付的小数据块(如很多)比使用 APNS 好得多，在其中实际交付可能很慢，特别是如果您向 Apple/您的用户发送大量通知，将您标记为垃圾邮件。虽然，免责声明，这只是我个人的信念和推测，具体取决于您的用例。

您正在消除那些不必要的数据库成本。

一个缺点是保持连接有效。

就个人而言，我最近将 websockets 与组合框架一起用于聊天应用程序，但它可以在许多不同的情况下使用。更新 Facebook 提要/评论部分，通过 websocket 而不是 APNS 实时通知，甚至发布内容。