要在 APP 上实现接收消息推送，用 MQTT 做合适吗？

[reallittoma]

准备给我自己的一个跨平台 App 加一个接受消息推送的功能，初步调研了一下发现 MQTT 十分符合需求。 但我对 MQTT 了解得不是很多，只知道在 IoT 领域应用很广泛。如果用在一般的 App 上，会不会有什么隐患（安全性问题之类的）？

[darkengine]

如果 app 没有运行的情况下需要接收推送，那么这个方案不可行。

[reallittoma]

@darkengine #1 很对，但目前的需求只需要在 APP 运行时能接收推送即可。

[hoogle]

还是看具体场景，不是实时性特别强或者 IM 之类的话，可能通过轮询或者前后台切换的时机请求一下数据就解决了。。

[reallittoma]

@hoogle #3 主要是考虑到自己实现轮询还要维护一套代码，还不如用现有的成熟技术来做。

[ysc3839]

建议 WebSocket 或者新出的 WebTransport https://web.dev/i18n/zh/webtransport/

[kkocdko]

看起来这个需求只需要接受推送，不需要双工（双向通信）。所以 5 楼建议之外，还有一个 SSE （ https://developer.mozilla.org/zh-CN/docs/Web/API/EventSource ），无需手动处理断线重连等逻辑，且完全基于 HTTP ，引入的依赖相对 WebSocket 更少。

不过我感觉轮询可能真的更好，如果时效性要求不高的话。HTTP 轮询下也就一个循环的事情，“还要维护一套代码”从何而来，至于安全性…哦好吧我可能不太了解你的需求。

[whyrookie]

最近刚使用极光推送，目前还不清楚具体的效果怎么样。

[yangzzzzzz]

只接收的话 sse 就够了，双工的话 ws/wss ，mqttjs 的实现就是 ws/wss ，你说的客户端应该也是吧。

[BugCry]

@whyrookie 极光会给你推广告，这个坑特别隐蔽

[xiaoliu926]

我们给 ZF 做的 APP 就是用的 极光+小米+华为，三家推送，目前还可以

[whyrookie]

@BugCry #9 这太恶心了

[ysc3839]

又去看了下 MQTT 的介绍，相对 WebSocket 大概是数据量少、有 QoS 功能，我不确定实际是否需要这些功能。
@kkocdko #6 提到的 EventSource 感觉已经够用了，除非要求推送到达后客户端回复确认。

[ql562482472]

轮训和推送比起来 轮询的可靠性会更高，推送的复杂度很高，想做可靠就更高了