手机邮件实时推送：推动(Push)模式和拉动(Pull)模式
push：保持长连接（采用异步socket建立tcp连接），能实时无延迟的收到服务推送过来的消息。服务器的域名不会改变，客户端能够找到服务器，而手机客户端是用的是移动运营商的网络，若30分钟（不同省份的运营商设置的可能不同，大部分运营商设置的是30分钟）用户不使用网络，运营商可能把这个IP分配给其它的用户，所以服务器一般不能实时的找到手机客户端。所要要实现push，那么就要再服务器和手机客户端建立长连接。由于手机客户端需要连接服务器的连接很多，通常服务器要支持集群，毕竟一台服务器要实现少冲突的分配长连接端口号，那么就最好不超过20000个连接。Push的好处是实时，维护通道的流量超少，只需要每30分钟维护一次通道（为保持安全稳定最好每14分钟维护一次通道，就是发送一次请求，应用前后台切换时有继续让线程僵死，所以应用前后切换时要维护一次通道）就可以。个推的透传和苹果APNS本质就时push长连接，所以他们很省点，也较快。只所以它们没有做到想象的那么实时是因为苹果运营的手机是海量的，APNS连接也是海量的，消息的调度是很费时间的。个推的连接比苹果少，但是再少也是海量级别的。所以个推付费能提高响应速度，但不能从根本上解决问题。想解决响应慢的问题只有你自己实现push长连接才更安全可能，毕竟是消息队列调度问题还是连接问题你都实时的知道，可以用http请求的方案替代暂时连接异常。大部分邮箱和邮箱客户端都不真正的支持push。微软的exchange服务器的imap idle从实现机制上它是push。
个推的付费用户也不是单独给你搭建一个服务器，而是调整给你有消息队列插队的的特权。如：你是付费用户，个推服务器有1亿条消息在排队，又一次性来1000万条消息，其中有5000条消息是付费用户的，那么这5000条消息肯定排列在1亿条消息紧挨着的后面，至于这5000条消息的那么就靠谁先来谁就在前面了。若一条消息处理时间是x毫秒，那么你的等待时间最快就是1亿＊x毫秒。所以你可以看到你的个推消息响应时间不但于你的应用使用量，也取决于这个时间段消息拥堵状况，其它人使用个推发送消息的瞬时情况，个推的透传可能发送很快（长连接大部分情况正常，无需建立通道的时间）但是它们大部分时间被耽误在消息排队上了。苹果的APNS服务器也是一样，只是没有插队的后门而已。自己在服务器上实现苹果的APNS的通信功能，不但在要求这方面的技术，最关键的是它不支持类似的安卓手机远程。而是个推集成了iOS和android这两方面的远程推送，所以你若想用不依赖于手机是否开启都推送消息，最简单的方法是使用个推。个推的APNS远程远没有个推的透传来的快，毕竟少了，在个推推送到苹果APNS服务，在哪里排队的时间，苹果的连接可是海量的。个推的付费用户对你的及时性有所提高，但是也没有你想象的那么及时，必定要在个推那里进行大量消息排队。自己实现push长连接，只排队等待自己应用的消息和其它应用的消息无关，所以响应最快最准确，不用担心消息丢失率的问题。
Pull:就是定时获取。优点是实现简单，技术难点和异常很少。缺点不够实时，若获取的时间间隔太短，设备的耗电量超快。还有一种实现方案是结合push和pull两者的优缺点，具有实时收到消息，实现简单，耗电量界于两者间。具体的是建立长连接，却是10秒维护一次通道（服务器或客户端不够强大，没有实现监控两者间异常的机制，才频繁的发送心跳消息来代替这种异常监控机制）。这种方案的优点是基本做到了push的省去了发送请求才建立tcp通道的时间，达到了实时发送。它可以是异步socket也可以是同步socket。同步socket的优点是实现简单，异常较少；缺点是阻塞连接线程，异步socket的优点是实时发现异常，不阻塞连接线程；缺点是实现相对复杂，异常较多。综上所述push的实现方案最优，pull的实现方案最简单，两者结合的方案是两者的折中，具体实现那种实现方案，根据自己技术团队的技术水平和项目紧急水平。金笛邮件系统支持推送方式，用最小的心跳包减少手机的电力消耗，同时又保证的消息的及时性。