正文
3. 长连
目前最通用的方案，客户端与服务端建立 TCP 长连，定时发送心跳包保活，有新消息时服务端通过该长连通道进行推送。
这里再简单说明一下长连和心跳包。
长连接
就是建立连接之后，双方互相发送数据,，发完了也不主动断开连接。
但是在某些情况下长连会断开，问题就在断开这件事上，而且这件事必须是由客户端知道，因为客户端是可以重连服务器的，服务器却没法再联系上客户端。这样才确定了
心跳包
必须由客户端发给服务器。所以心跳包的作用就是告诉服务端客户端还活着，如果服务端挂了，客户端能知道，所以
保活
说的是保持两边都活着。
上面说的某些情况中，
NAT 超时
算是一个典型的例子。
因为 IPv4 的 IP 量有限，运营商分配给手机终端的 IP 是运营商内网的 IP，手机要连接 Internet ，就需要通过运营商的网关做一个网络地址转换（Network Address Translation，NAT）。简单的说运营商的网关需要维护一个外网 IP、端口到内网 IP、端口的对应关系，以确保内网的手机可以跟 Internet 的服务器通讯。大部分移动无线网络运营商都在链路一段时间没有数据通讯时，会淘汰 NAT 表中的对应项，造成链路中断。所以长连接心跳间隔必须要
小于
NAT 超时时间（aging-time），如果超过老化时间不做心跳， TCP 长连接链路就会中断，服务器就无法发消息给客户端，只能等到客户端下次心跳失败后，重建连接才能取到消息。
有了长连，即使在休眠模式下，有推送消息过来，也能唤醒 Android 系统，这是由系统机制决定的，我们这里只要知道结论就好。
想要了解更多的可以去看文末的
参考资料
。
推送的指标
在接入推送服务时有几个核心指标需要考量：
1. 在线率
在线率 = 在线用户数 / 总用户数
推送服务后台保持在线的方法
显然，后者在体验上更加接近 GCM 。
2. 到达率
到达率 = 实际到达数 / 目标用户数
在线数 -> 目标用户数 -> 成功下发数，如果后端的计算或调用出现问题这两个数据就会不准确
在线数 -> 实际到达数 -> 展示数，数据收到后，是否展示要看用户有没有打开该应用的允许通知的开关，可以通过如下方法判断
notificationManagerCompat.areNotificationsEnabled();
3. 耗电量
耗电量受到很多方面的影响，如果收到推送比较多，打开应用比较频繁，耗电量自然也会上去不少，但这个用户是可以接受的。以下几个耗电量的因素用户是比较反感的：
推送选型
上面提到，我们这里聊的推送，是
第三方推送
，那有开发者要问了，为什么不自己做推送？自己做不是不行，但需要考虑几个问题：
第三方推送主要有厂商推送和非厂商推送
