安卓应用从服务器推送消息的原理及实现方法解析

你清楚这件事情可知晓状况吗？于Android之上达成消息推送之举，相较于在iPhone那里进行一番折腾而言难度要大得多，具体而言之，google官方规定的C2DM服务在国内基本上是处于无法使用的状态，要是自行着手搭建服务器的话实际上又会面临电量这一阻碍，以及网络方面的问题，还有系统杀进程这三个难题与挑战，这可以说是几乎所有的Android开发者都曾遇到并且踩过的坑洼情形了。

推送服务的两种主流实现方式

由客户端主动前往服务器拉取数据，此即轮询方式，其实现起来着实简单且直接，其中你仅仅只需于App内设置一个定时器，每隔数分钟向服务器发起HTTP请求，借此查询有无新数据，众多新闻类应用在早期皆如此操作，像是2012年的新浪微博客户端每隔5分钟便进行一次同步。

推送方式呈现出全然相反之态，是服务器主动去把数据发送给客户端。苹果的APNs乃是典型的代表示例，每一台iPhone仅仅维持一个与苹果服务器的长连接，所有App的通知均经由这个通道。此种方式具备良好的实时性，然而Android欠缺统一的推送服务，致使每个应用都得自行去维护连接。

C2DM方案为何在国内水土不服

原来Google的C2DM服务是个挺好的举措，其所给予的是一整套完备的消息推送架构，开发者只要调用API就行。服务器会将消息发送至Google的C2DM服务器，随后由该服务器把两者分流至相关目标设备，该完整流程对于开发者而言是毫无晦涩之感的。

但实际情况很残酷，C2DM依靠Google服务框架，然而国内众多手机厂商直接将这一部分给去除了。更为棘手的是，C2DM服务器处于国外，网络延迟较大并且时常连接不上。在2013年我于开发一款即时通讯应用的时候尝试过这个方案，结果消息送达的比率不到30%，最终只能抉择放弃。

自己动手实现推送的三种尝试

最耗费资源的是轮询方案，若搭载 GPS 的 One X 手机每隔十分钟进行一次轮询，那么一天下来就要耗费好几兆的网络流量，甚至电量连半天都支撑不了，并且此时服务器压力也会增大，要是一万个用户同时进行轮询，QPS 会飙升到几百，有这样的情况。

看似完美的短信推送，借助拦截特定号码短信达成实时触发。然而发短信网关成本高昂，一条短信需八分钱，推送一万条便要八百块呢。曾经在2014年有个天气应用尝试过此方案，结果一个月下来烧掉两万多元短信费，而用户增长数量却没多少呀。

有一个极为靠谱的持久连接方案，然而，Android系统存在着一个极其要命的特性，那就是在内存不足的时候，会将后台服务杀掉。比如说，华为P6在剩余内存低于200MB的情况下，便会把全部第三方服务进程清理掉，如此一来，你的推送通道就这么阻断了。

MQTT协议在Android端的实践

专为物联网设计的MQTT协议，其协议包头最小竟仅有2个字节，相较于HTTP要轻量许多。IBM于2011年便推出了针对Android的MQTT客户端库，连接建立之后，心跳包只需发送2字节的PINGREQ消息。

我们于实际项目里所运用的是Eclipse Paho Android Service，它将连接保活的问题给解决了。此服务在连接断开之际会自动进行重连，且能够依照网络状态去切换心跳间隔，于WiFi环境下是每5分钟一次，在移动网络状况下是每15分钟一次，可有效实现省电。

XMPP协议实现推送的完整方案

XMPP协议尽管是基于XML的，其数据包比较大，然而它的扩展性是极好的 ，Openfire服务器是用Java编写的，在腾讯云上的一台1核1G的机器进行部署，就能支撑五千个并发连接 ，客户端使用asmack库，编写代码量不到200行就能够实现注册、登录以及接收消息。

XMPP服务端用于处理长连接，这是服务器端所需的两个组件之一，Web服务端则提供HTTP接口，这是另一个组件。我们那时用Netty重写了连接管理模块，该模块能够实时监控每个客户端的在线状态。当运营后台发起推送时，系统会先检查目标是否在线，若在线则直接下发，若离线则存入数据库等待重连。

持久连接方案的设计缺陷与弥补

伴随着Android 5.0之后所引入的JobScheduler，其能够对传统的Service予以替代，进而开展后台任务。在二零一六年的项目当中，我们借助它来维系推送连接，系统会依据电量、网络条件等诸多因素实施智能调度，相较于普通Service而言，其存活率要高出百分之四十。

还存在着一个痛点，那就是WiFi与移动网络进行切换的时候，连接肯定会断开。其得以解决的办法是，于BroadcastReceiver当中对于网络变化事件予以监听，一旦监测到网络恢复了，便马上启动重连操作。实际测试在小米4这款手机上情况是，从地下室朝着地面走，连接进而恢复所使用的时间从原本的3分钟缩减到了10秒以内。

消息送达予以确认这种情况是十分重要的，我们所制定的协议当中设计规划了ACK机制，客户端在接收到消息以后必定要回复予以确认，要是在30秒以内没有接收到ACK，服务器方面会重新发送三次，如此一来不论是由于手机屏幕熄灭进而导致CPU陷入休眠状态，都能够确保消息不会丢失。

文字推送之外的消息处理策略

推送服务对于传递纯文本形式的通知最为适配，像诸如“你有新订单”这类的，或者是“地震速报”这类的通知。在2015年天津港爆炸事件发生的那个时候，我们是借助推送发出了提醒，用户只有在点击之后才会前往服务器那里去拉取详细的数据，如此这般就规避了大量图片同时进行下发所导致的网络拥堵现象。

推送给你的正文当中应当仅仅把必要的标识涵盖在内，像是消息的ID以及类型。客户端在接收到之后会先弹出通知，当用户触动点击时方可依据ID到服务器抽取详情内容。如此去设计不仅确保了实时性，还规避了长连接传输大数据这一可靠性方面的问题。

你可曾思索过，倘若手机制造商业彼此携手营建一个统一的推送规范，我们这些开发者还会需要自行搭建服务器吗，欢迎于评论区域分享你个人的见解，点赞能促使更多众生知晓这类技术痛点。