基于 Android/iOS 的应用,都是采用 CS 结构的方式。一般来说消息的传递都是由 Client 端向 Server 端发放请求,Server 端响应 Client 端的请求。这种方式成为 pull,由 Client 端向 Server 端拉取数据。和 pull 相反,push 是由 Server 端向 Client 端主动推送数据。咱们这里分享的就是推送的实现方法。
大体上,实现推送有这么几种方式,不定期补充。
轮询。轮询其实还是 pull 方式,就是客户端定时的给服务端发送请求,以达到 push 的方式。这种方式的最大问题是消耗,成本太大。就好比你在等待心仪的男/女神给你发短信,你每隔一分钟从口袋里掏出手机查看短信一样,然并卯,累的口袋和手机都不高兴了。
短信截获。这是一个技术可行方案。通过监听手机的短信端口,当服务器通过短信的方式给客户端推送消息的时候,客户端可以截获短信。但是这种方案有几种局限性。首先,国内的各种内置的安全软件,特别是各个系统自带的安全软件,很可能截获你的短信。
长连接,我理解就是 socket 连接。在客户端和服务端之间建立一个长连接。这种方案的缺点是对于移动应用,网络情况复杂,实现不了完全可靠的长连接。长连接同样会增加客户端 CPU 的工作量,同时也对服务端的并发连接数提出了一些挑战。但,目前大多数的应用还都是基于长连接的方式来设计推送的。
这个是由 Google 提供的服务,应该是一个不错的选择,但是不是很符合国情。
一个完整的 GCM 服务包括客户端和服务端。
由于那堵墙和国内各厂商手机对原生环境的改动,这个方案很难在国内落地。
MQTT是一个轻量级的消息发布/订阅协议,它是实现基于手机客户端的消息推送服务器的理想解决方案。
当然这也是需要客户端和服务器都按照这个协议实现了。
Really Small Message Broker (RSMB) ,他是一个简单的MQTT代理
XMPP(可扩展通讯和表示协议)是基于可扩展标记语言(XML)的协议,它用于即时消息(IM)以及在线探测。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。
这个方案是很简单有效的。
这个方案不是一般人,一般公司应该做的。
- EOF -
本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动。
转载请注明:文章转载自 Binkery 技术博客 [https://binkery.com]
本文标题: Android 消息推送
本文地址: https://binkery.com/archives/519.html