推送通知能否替代Web Socket？

Question

我需要在iOS和Android上开发一个应用程序，其中包含实时功能：应用程序用户需要定期实时共享代码而无需轮询。

通常我使用Web Socket来完成这项工作，并仅在应用程序处于后台时向用户发送附加通知。因此，推送通知对应用程序逻辑没有影响（是一个额外的优势）。

我的疑问是，我能否完全用Firebase Push Notification（用于接收）+ Rest API（用于发送）来取代Web Socket通信？ 推送通知足够可靠吗？

总的来说，推送通知是否可以替换websocket来实现应用程序逻辑？ 解决方案1（WEB-SOCKET + PUSH-NOTIFICATION） 用户A -> 应用程序（websocket） -> 服务器（websocket + push-notification） -> 应用程序 -> 用户B

用户A <- 应用程序 <-（websocket + push-notification）服务器 <-（websocket）应用程序 <- 用户B 解决方案2（PUSH-NOTIFICATION + REST API） 用户A -> 应用程序（rest-api） -> 服务器（push-notification） -> 应用程序 -> 用户B

用户A <- 应用程序 <-（push-notification）服务器 <-（rest-api）应用程序 <- 用户B

- Alex

---

我对这个概念非常感兴趣。你试过吗？我猜推送通知的“唯一”缺点将是它们不是实时的，但允许一些滞后。 - Lukáš Řádek

Answer 1

实际上是可能的。但这个选择有几个关键缺陷：

• 首先，推送通知需要用户权限，如果用户已经阻止了推送通知，你将被阻止（在你的例子中，这意味着你的 RestApi 最多会停止工作），而且很难改变普通用户的这个选择，用户应该去浏览器设置...等等。
• 浏览器对 WebPush 的支持要比 WebSocket 小得多。
• 你的服务器和客户端之间可能存在延迟，因为这种调用的调用堆栈比正常的 WebSocket 连接多得多。非常粗略的方案：你的服务器 -> 推送服务器（如 Firebase 推送通知） -> 客户端，在每一步都有许多检查。

- romjay77