Mikel
[转载]Android推送小结-Android开发源码下载-eoe Android开发者社区_Android开发论坛 – Powered by Discuz!.
先写个草稿，借用大量的大家资料，正在整理中，先放出来一个极光的，整取把另外几种也整理出来。
相关阅读
作者：Shims Android消息推送技术原理分析和实践 http://www.eoeandroid.com/forum.php?mod=viewthread&tid=307832
作者：keisuo Android消息推送/Push机制介绍和资源索引贴(持续更新中) http://www.eoeandroid.com/forum.php?mod=viewthread&tid=210592
作者：way1989Android之基于百度云推送IM http://www.eoeandroid.com/forum.php?mod=viewthread&tid=296417
作者：yanghe123 Android C2DM学习——云端推送(转载) http://www.eoeandroid.com/forum.php?mod=viewthread&tid=173212在线课程 http://edu.eoe.cn/course/view/cid/9.html
弄完了才发现，各位老大都整理的差不多了，真心是班门弄斧了，想想还是先发出来，然后去做细节吧
概念
手机推送服务是指服务器定向将信息实时送达手机的服务。与常见的轮询方式（伪推送）相比区别主要在于两点:一是否长联网，二是到达实时性。
推送服务是长联网的，一般到达手机的延迟在0.1-0.5秒左右，而轮询方式（伪推送）不是长联网的，达到延迟时间则根据轮询时间的不同为1-10分钟，也有延迟1小时或一天的情况。
一般来说对于时间敏感度不高的需求，建议使用轮询服务，能有有效的解决服务端压力以及客户端压力。
服务原理
手机推送服务的原理很简单，就是通过建立一条手机与服务器的连接链路，当有消息需要发送到手机时，通过此链路发送即可。
推送服务的使用流程虽然略有差别但是大致都和一下原理相似：
1首先是应用程序推送消息注册，此过程中启动了推送服务，以及向服务器注册了应用标识(APP Key&&APP Id&&APP&&API Master Secret)，这些标识表明了应用的身份。
2客户端向服务器取得用户标识(ClientId)，该标识能够表明用户的唯一身份。
3应用程序将ClientId发送给服务器PUSH程序。
4服务器PUSH程序向客户端监听服务发送消息。
5客户端监听服务将消息发送给应用程序。
以Google的C2DM服务为例，结构视图如下：
推送实现方式
对于Android
方案1：
使用C2DM服务（Google Cloud Messaging）
简介：Google推出的云消息服务，即第二代的G2DM。
优点：Google提供的服务、原生、简单，无需实现和部署服务端。
缺点：Android版本限制（必须大于2.2版本），该服务在国内不够稳定、需要用户绑定Google账号，受限于Google。
方案2:
使用XMPP协议（Openfire + Spark + Smack）
简介：基于XML协议的通讯协议，前身是Jabber，已由IETF国际标准化组织完成了标准化工作。
优点：协议成熟、强大、可扩展性强、主要应用于许多聊天系统中，且已有开源的Java版的开发实例androidpn。
缺点：协议较复杂、冗余（基于XML）、费流量、费电，部署硬件成本高。
方案3:使用第三方推送服务
简介：通过嵌入SDK使用第三方提供的推送服务，主流的有极光推送，百度云推送，个推等。
优点：稳定，成熟，推送管理界面及统计程序完善。
缺点：有程序嵌入顾虑
推送方案的评价标准
推送方案的公认评价采取4s标准：
Safe(安全) Stable(稳定)Save(省电省流量省成本)4.Slim(体积小)
1.Safe (安全)
推送方案应支持透传及各种加密方案，保障信息传递安全。
推送方案的ID系统应该独立于已有的网站或服务的ID系统，这样保障用户在不同手机上登录后的信息投递准确性，避免因为取消绑定事件失败因网络传输而造成的信息误投送。
2. Stable（稳定）
稳定包括两个部分一个是服务器端的稳定性，一个是手机端的稳定性。
服务端稳定性，因为使用长连接方案，对服务器的开销和要求很大，推送方案对服务器开发要求很高，海量线程连接下的服务器稳定性是非常具有挑战性的。
一般的评判标准包括：
– 同时在线时峰值（一般按照百万并发连接时服务器稳定性评测）
– 高并发时消息平均延迟时间（一般按照1分钟处理1百万条信息评测）
– 服务稳定性（一般要求全年99.9%以上可用，有备份，有负载均衡等）
鉴于服务器稳定的开发难度很大，维护难度大，建议使用稳定的第三方推送方案。
手机端的稳定性，主要是因为中国的复杂网络状况及手机型号适配情况造成手机长时间稳定联网较困难，所以稳定性非常重要。
一般的评判标准包括：
– 每日联网23.5小时以上用户比例（表征联网稳定性）
– 消息发送后9小时内收到率（表征到达率）
一般来说，推送方案要做网络的分运营商，分省，分机型适配，开发工作量较大。
3.Save（节省）
省电应注意CPU休眠，一般用服务缩短待机时间百分比评判。
省流量应注意协议的修改和冗余数据包的处理，一般用空载待机月流量评判。
省成本应考虑单服务器承载同时连接数，可承载同时连接数越多成本越低，业内顶尖水平为个推的单服务器300万连接。
4.Slim（体积小）
客户端推送服务SDK应该体积尽量小，不影响主程序的大小和复杂度，一般以小于或等于300K为宜。
Android推送方案
目前对于Androi推送，第三方的客户端SDK以非常低的代价保持连接，电量、流量消耗都很少。技术架构先进，经受过千万级用户的考验；支持 Portal上推送，也支持 API调用，简单易用的 Portal，可以用来发送通知，统计分析推送效果。不考虑推送的内容部分。推送内容的多少是由开发者决定的大多数的第三方推送数据理论平均值：流量消耗 15K-30k/天，电量消耗 20mAh-100mAh/天。
JPush的Demo,包括客户端以及服务端。具体文档请查阅
