c/s 端做消息推送通知的话，如何选择？ websocket 还是选择长轮询？

[tctc4869]

要做实时数据显示功能，当然这里主要指手机客户端，在客户端后台挂起，实时监听，如果有内容则判断是否要显示通知栏。那么是选择长轮询，还是用 websocket ？然后服务端增加 websocket 服务端处理。

在这个帖子里： https://www.v2ex.com/t/477876?r=julyclyde 。有 V 友指出“长连的资源消耗不比轮询低”，“受网络限制比较大，需要处理好重连”

那么到底要怎样考虑做选择？

[IGJacklove]

@tctc4869 没有这个意思，我的意思是想少点麻烦就多花点钱，想自己弄就麻烦一点，自己做取舍。

[opengps]

app 没有被杀死的情况下，用原生 socket 更实时

[tctc4869]

@opengps 那么你觉得 websocket，或 http 长轮询，哪个方式更好。

[opengps]

@tctc4869 http 轮训比较简单。建议首选，做大了在考虑 websocket
websocket 实时性好，但是大部分人没经历过长连接项目，可能得有些坑需要踩。作为一个客户端，可控性更低，有问题难以分析

[unco020511]

@tctc4869 不管是从消息送达率,还是耗电,还是投入 /产出比 上来说,使用第三方推送都会比你自己做要好,你要考虑好;你使用 http 轮询不用考虑耗电问题吗,再说现在的 rom 很多会限制你后台的活动,再其次你使用 socket 长连接,你的心跳包间隔是多少,怎么根据不同运营商来优化心跳频率,还有国内 row 有诸多改动和限制,也会涉及适配的问题;以上你都得考虑

[sioncheng]

手机后台存活不了多少时间，不要想啦。 退而求其次，有数据需要刷新了，发送 APP 推送（ ios apns 或者国内 android 厂商推送服务），提醒用户打开 APP 然后拉取最新数据。

[0x8192dd]

移动端直接利用推送通道不就完事了？接个推送 SDK 就行了，保活就别想了
都 2020 年了，移动端没有后台挂起这种说法，用户退出应用之后，就是靠推送通道推送消息，用户点了消息，唤起应用，重连，你用 iOS，微信启动之后有个“收取中”，就是执行重连和数据同步。

轮询和 socket 的区别主要是在应用位于前台的时候
如果你是要做 IM，或者股票 K 线图那样实时的东西，那必须用 socket 让客户端接收服务器主动下发的数据，如果只是个什么中奖通知，工单反馈之类实时性要求不高的推送，那么在移动端轮询或者写一些触发点（比如切页面）来查询就可以了。

简而言之：需要频繁主动下发 - socket ；需要用户在某一页面的时候更新数据状态 - 轮询