在socket通信中，心跳是为了判断当前连接是否有效，可被使用。如果可以及时的判断出当前连接已经失效了，就可以快速的建立重连机制。

在Android的世界里，google推出的云推送服务，默认心跳是28分钟，但这个放诸全球绝大部分地区行得通的规则，到了*，就出现了问题。以中移动的2.5G网络为例，经过粗略测试，大约5分钟左右的基带空闲，连接就会被释放，如果出现信令风暴的时候，经过测试30S左右的基带空闲，连接就会被释放，这也是为什么微信Android版本选择以‘5分钟’为周期发送连接心跳。其实不然，5分钟只是测试出来的一个平均值，可能在5分钟就会频繁的掉线，致使推送服务不能使用，在失效的情况下，通过心跳建立重连机制，如果是对于消息的即时性要求不高的情况下，5分钟的心跳也是可以满足需求的。如果是超过10分钟的心跳，虽然可以达到省电的目的，但是作为一个开发者来讲，10分钟的心跳会大大增加推送服务的不稳定性，致使10分钟左右才可以建立重连的机制，大大的影响了用户的体验性。

对于心跳时间的把握，不同的推送服务，心跳周期基本是不同的。相信有不少人，为了解决2G/2.5G的信令风暴做出了很多的努力，但是收效却甚微。在这里我就谈谈智游推送的心跳机制。

首先，选择心跳的周期，大部分推送服务都是选择5分钟以上的心跳，如果是信令风暴时期，推送服务基本瘫痪，我们的心跳周期并不是5,10分钟，而是一个动态的单心跳，可以很好的预防信令风暴，即使是信令风暴时期，推送服务也可以使用。

其次，智游推送还使用了双向心跳。双向心跳不仅可以增加通道的活性，同时也可以保证通道的连接状态是真实的，不会出现假心跳的情况，让推送服务更加的稳定，使消息可以快速的推送到客户端。

同时，我们增加了一些策略去保证推送服务的稳定性，比如说开屏，我们会发送一个命令去检测连接是否失效，如果是连接失效，推送会立即执行重连机制，保证推送服务的连接是可用的。

推送服务做到现在，已经有不短的时间了，推送服务的快速，稳定以及流量，电量的消耗都有很好的保障性