我们在讨论 Android 手机上的推送时，大多数情况是在说集成第三方推送，因为即使是像微信这样的大厂，也需要厂商加到启动白名单里才能保持在线。
这样一来，国产手机的推送就成了个问题，也带了机会。
推送的实现方式
总结一下几种推送实现方式，其中有些我们只要了解即可，因为属于历史解决方案，现在已经被废弃掉了。
轮询
客户端定期询问服务器有没有新的消息，这种方式最大的缺点就是性能和实时性的矛盾，轮询时间过长和过短都不好。
短信
这种方式还没出生就不被允许了，首先运营商不会配合，其次拦截手机短信本身就是一个高危权限，大多数用户不会买单。
长连
目前最通用的方案，客户端与服务端建立 TCP 长连，定时发送心跳包保活，有新消息时服务端通过该长连通道进行推送。
这里再简单说明一下长连和心跳包。长连接就是建立连接之后，双方互相发送数据,，发完了也不主动断开连接。
但是在某些情况下长连会断开，问题就在断开这件事上，而且这件事必须是由客户端知道，因为客户端是可以重连服务器的，服务器却没法再联系上客户端。这样才确定了心跳包必须由客户端发给服务器。所以心跳包的作用就是告诉服务端客户端还活着，如果服务端挂了，客户端能知道，所以保活说的是保持两边都活着。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询
上面说的某些情况中， NAT 超时算是一个典型的例子。因为 IPv4 的 IP 量有限，运营商分配给手机终端的 IP 是运营商内网的 IP，手机要连接 Internet ，就需要通过运营商的网关做一个网络地址转换（Network Address Translation，NAT）。简单的说运营商的网关需要维护一个外网 IP、端口到内网 IP、端口的对应关系，以确保内网的手机可以跟 Internet 的服务器通讯。大部分移动无线网络运营商都在链路一段时间没有数据通讯时，会淘汰 NAT 表中的对应项，造成链路中断。所以长连接心跳间隔必须要小于 NAT 超时时间（aging-time），如果超过老化时间不做心跳， TCP 长连接链路就会中断，服务器就无法发消息给客户端，只能等到客户端下次心跳失败后，重建连接才能取到消息。
有了长连，即使在休眠模式下，有推送消息过来，也能唤醒 Android 系统，这是由系统机制决定的，我们这里只要知道结论就好。
推送的指标
在接入推送服务时有几个核心指标需要考量。
在线率
在线率 = 在线用户数 / 总用户数。
推送服务后台保持在线的方法：
Push 进程常驻后台，需要用户手动让应用常驻；
共享连接通道的方式，比如极光或者个推，通过共享连接，当应用有推送到达时，唤起该应用。
显然，后者在体验上更加接近 GCM 。
到达率
到达率 = 实际到达数 / 目标用户数
在线数 -> 目标用户数 -> 成功下发数，如果后端的计算或调用出现问题这两个数据就会不准确；
在线数 -> 实际到达数 -> 展示数，数据收到后，是否展示要看用户有没有打开该应用的允许通知的开关，可以通过如下方法判断：
notificationManagerCompat.areNotificationsEnabled();
耗电量
耗电量受到很多方面的影响，如果收到推送比较多，打开应用比较频繁，耗电量自然也会上去不少，但这个用户是可以接受的。
以下几个耗电量的因素用户是比较反感的：
应用间互相唤醒产生的耗电，因为这个耗电是别的应用的，用户本来没有意图要去打开；
错误重试造成的耗电，重试策略的优化包括重试时间的累加和重置。
推送选型
上面提到，我们这里聊的推送，是第三方推送，那有开发者要问了，为什么不自己做推送？
自己做不是不行，但需要考虑几个问题：
开发成本问题， ROI 是否可以接受；
如果不加入白名单，那么一旦应用被彻底杀掉，是没人给你吟唱复活魔法（互相唤起）的。
第三方推送主要有厂商推送和非厂商推送：
华为、小米、魅族推送；
个推、极光、友盟；
阿里、腾讯、百度。
其中，选型的几个因素：
厂商推送通知是否系统通道（所有厂商支持）；
厂商推送透传是否系统通道（仅魅族）；
非厂商推送的市场占有率（影响共享连接互相唤起的概率）。