Android 推送技术解析

Android 推送技术解析

 

　　当今信息爆炸的时代，人们对于充斥在身边的各类信息几乎有些麻木了。大量无关的信息不断骚扰人们的神经，所以个性化、社交化的应用也是大行其道。好比一些新闻客户端，会根据用户的使用习惯或订阅要求向用户发送指定的新闻内容；再好比经常使用的一些即时通信软件如微信、GTalk、个信等，都是能够实时地将私密信息送到用户的终端。这背后用到的技术就是消息的推送。
　　本文讨论的消息推送特指从服务器端向移动终端设备进行特定格式信息流传递的过程。 与传统服务器端到服务器端通信最大的区别就在于移动终端的不肯定性。举个生活中的例子，服务器端比如是北京的"水立方"游泳馆，闻名遐迩，有明确并且固定的地址（IP或域名），你们要游览（访问）"水立方"能够很方便的找到她。可是反过来，"水立方"要想找到某个具体的"游客"就很难了，由于每一个"游客"没有肯定的地址（每次登陆网络均可能变动IP）。
　　怎样才能随时找到散落各处的"游客"呢？移动运营服务商提供了一个有效的途径-SMS。经过移动终端的惟一标识（手机号码），随时随地找到某个终端用户。但是有两座大山挡在了开发者面前。其一，号码资源做为运营商的垄断资本不会轻易开放出来，事实上在android手机上要想绕开运营商得到手机号码毫不容易；其二，短信内容的拦截、解析与匹配自己技术门槛较高，对于开发者来讲实在不是一种合适的选择。
　　有没有其余便捷的选择呢？答案是确定的，既然服务器端找到客户端不容易，而客户端找到服务器端很容易，那么就可让消息推送的过程反转过来。首先由客户端来定时访问服务器端，创建某种联系（一般为http请求）。以后，服务器端就能够轻松地将信息经过这种联系通道发给客户端了。这就是一般说的轮询模式。这种模式具体到移动终端设备上，却存在致命缺陷：高频的轮询致使流量和电量消耗极高，低频的轮询又会致使消息的及时性不好。
　　有没有更好一些的实现方式呢？的确是有的，并且苹果已经很好地实现了这种方式-持久化链接。苹果信息推送服务（Apple Push Notification Service）提供了苹果移动终端与服务器端的长链接。一样地，在android系统上也能够实现相似苹果APNS的推送机制。目前主流的实现协议包括：C2DM、XMPP和XQTT等。同时，一些技术公司也看准了android信息推送的广阔市场，将这些协议进行封装、改造，造成了各具特点的android推送解决方案。
　　国内的推送技术解决方案有个推，听说新浪微博android上的推送也是他们作的，并发量达到5000tps（每秒钟能够处理5000个事务），日分发消息听说超过1亿条，消息到达率在96%以上，延时小于250ms，换句话说消息会在1/4秒内到达。同时对于消息都有详细的报表数据，能够用于作数据分析挖掘和用户体验的改善，整体来讲是开发成本最低的。
　　  个推平台有两种接入模式：
　　    群发模式
　　  提供群发管理后台，知足消息群发需求
　　  无需设备部署，当天开通帐号，客户端集成SDK发布便可使用
　　    业务整合模式
　　若是但愿推送与业务深度结合，还可使用其提供的业务整合模式。
　　提供服务端API接口，能够与客户已有业务系统深度整合
　　客户通常通过1-2周开发改造便可实现新功能的上线
　　第三方推送接入相对最简单，开发也比较容易。不管是从消息的到达率、集成开发成本、并发量仍是统计报表的完善程度，个推都表现的很是出色。