刚刚看到一个关于集成米聊微信等推送系统的投票贴，感触很深，确实用Android以来其推送的占用资源和不稳定性让我有了些微不满，不过前两天我恰好看到了一篇技术类文章全面阐释了Android的推送机制与ios的区别以及带来的实际体验的差距，所以想把自己获得的一些东西分享给大家。


推送系统最早其实是黑莓的专利，后来ios非常聪明的学去了，而且学的很好。在推送之前很多智能系统只能通过轮询的方式不断定期向服务器询问是否有新信息，往往费电和费流量。
ios建立了一个统一的服务器，APNS（Apple Push Notification Service），简单的说，我们在手机上接收到的所有推送信息都来源于这个服务器，每一台ios设备都有一个独立的识别码相当于身份证。那么当你用这个身份证登录了某个软件（比如米聊）后，就连接到了米聊的服务器上，在推送体系中这个目标服务器被称作Provider。接着你看完消息，退出米聊后，进程结束，但是此时你这个身份证的登录状态并没有在Provider里注销，而是保留了。因此如果有人给你的米聊发送了信息，就会触发Provider的行为，但是由于你关闭了米聊，所以它无法直接向你的手机发送消息，于是它转而向APNS发送信息，顺便带着你的身份证。然后万能的APNS就顺着身份证找到你，然后把消息塞到你的手机里。只要你ios设备的推送不关闭，流量不关闭，那么你的设备就会一直和APNS保持连接，从而达到24小时接受推送信息的目的。有人应该已经明白了这样做的好处，因为你只和一个服务器产生连接，省电省流量。另外由于APNS服务器的广域和强大的稳定性，以及该服务在ios属于固定的API接口，使得整个推送系统稳定而健壮。不过顺便一提ios的邮件推送是另一套完整的PushMail系统，和这个无关。


那么为什么安卓的推送没有ios给力？其实在Android2.2之后，谷歌也建立了类似ios一样的推送系统——Android Cloud to Device Messaging（C2DM），但是为什么这个系统没有APNS给力呢？主要是C2DM的服务器对于国内来说是外面的东西，由于谷歌在国内受到了一些格外的照顾，这个服务器也就显得不那么给力，这是国内厂商多不选择C2DM的重要原因。另外Android开源和API的开放提供了其它推送的选择。在C2DM不给力的情况下，一些软件选回了老的轮询方式的（凡是软件里需要你自己选择多长时间检查一次有没有更新的软件都是轮询方式）来提供消息，这种方式有相当的不稳定因素，在机器内存紧张的情况下驻留的http服务容易被回收，还更费电费流量。更多软件厂商则选择了利用Android的自由的XML的API接口自己搭建XMPP服务器来直接向用户推送消息，缺点同样是驻留的服务容易被回收，尤其对于小内存机器和在内存管理上时常有技术性溢出（回收机制缺陷）的MIUI来说如果不锁定服务的内存那么就可能出现收不到推送的情况。总体看来由于安卓推送机制的缺陷和进程的不统一（你装米聊微信微博就等于后台有了三个推送进程），整体上的健壮性得不到保证，也更加费电和费流量，与ios统一而健壮的推送服务有了很大的差距。


综上所述安卓系统的推送问题是并不是MIUI小组可以企及的，就算MIUI强势到能够建立一个墙内的推送服务器，也需要说服众多的软件厂商去使用他们的服务器，这就意味着需要有“米聊MIUI版”“微博MIUI版”，更加加剧了安卓生态圈的分裂。


至于在Android4.0时代安卓能否改变这个现状我只能持谨慎乐观态度，因为其开源性和向下兼容的API整合使得这种现状更有可能延续下去而不是改善。