推送相关介绍
在用户未打开App时，服务端向用户推送服务器最新的消息数据，称为推送。消息推送在移动开发中用到的场景非常多，比如典电商类app的商品促销活动，资讯类的app的新闻推送等等。在实际开发中，我们常常会根据产品设计的需要，进行推送功能的开发。然而在实现过程中，会面临很多问题，比如：怎么实现？是自己实现还是选择第三方的推送？如何选择第三方的推送？如何保证消息推送的数据安全？如何保证推送的到达率？其实这些痛点主要是在Android手机上，本文侧重点也在于Android手机上的推送。
part1：iOS推送和Android系统推送的对比
iOS推送服务通知是由自己专门的推送服务器APNs （Apple Push Notification service）来完成的，其过程是 APNs 接收到我们自己的应用服务器发出的被推送的消息，将这条消息推送到指定的 iOS 设备上，然后再由 iOS设备通知到应用程序，进而提示或展示。 iOS 远程推送的前提是，装有我们应用程序的 iOS 设备需要向 APNs 服务器注册。当我们需要推送消息时，我们的应用服务器将消息按照指定的格式进行打包，然后结合 iOS 设备的 devicetoken 一起发给 APNs 服务器。我们的应用会和 APNs 服务器维持一个基于 TCP 的长连接，APNs 服务器将新消息推送到iOS 设备上，然后在设备屏幕上显示出推送的消息。（注：所有的第三方推送都要通过苹果服务器APNs ）。
而 Android每个需要后台推送的应用要有单独的后台进程，才能和各自的服务器通讯和交换数据。其实 Android 也有类似 APNS 的 GCM（Google Cloud Message）的服务，如果Android应用的推送采用这种模式的话，就和iOS推送一样了。GCM相关的程序应该是集成在所谓的Gapps中。可是由于国内的 Android 手机 GCM 处于基本不可用的状态，并且Android设备的严重碎片化，就导致了做Android推送时不得不考虑的上边的那些问题。
part2：推送的本质与原理
消息推送的本质是：App将服务器更新的信息推送给用户，即App获取服务器信息，再推送给用户App从服务器获取最新消息有两种基本方式（原理）：Push和Pull
- 主动获取方式（Pull）：客户端隔固定时间主动向服务器获取信息，看是否有更新的信息；若有更新信息，则发送到客户端
- 被动接受方式（Push）：当服务器有更新信息时主动发送到客户端
对比：Push方式比Pull方式更优越。因为采用Pull方式时客户端需要不停地去监测服务器的变化，更费客户端的资源（CPU资源、网络流量、系统电量）
part3：Android中实现消息推送的几种解决方案
了解了推送的原理，下面说下在Android中实现消息推送的几种解决方案：
方案1、 使用GCM服务（Google Cloud Messaging）
简介：Google推出的云消息服务，即第二代的G2DM。
优点：Google提供的服务、原生、简单，无需实现和部署服务端。
缺点：该服务在国内不够稳定、需要用户绑定Google帐号，受限于Google。
方案2.轮询
简介：基于Pull方式，应用程序隔固定时间主动与服务器进行连接并查询是否有新的消息。
缺点：成本大，需要自己实现与服务器之间的通信，例如消息排队等；到达率不确定，考虑轮询的频率：太低可能导致消息的延迟；太高，更费客户端的资源（CPU资源、网络流量、系统电量）和服务器资源（网络带宽）
方案3.SMS（短信发送）
简介：通过拦截SMS消息并且解析消息内容来了解服务器的意图，并获取其显示内容进行处理。
优点：可实现完全的实时操作。
缺点：成本相对较高。因为目前来说，很难找到免费的短消息发送网关来实现这种方案，只能通过向运营商缴纳相应的短信费用。
方案4、使用MQTT协议（更多信息见： http://mqtt.org/）
简介：轻量级的、基于代理的“发布/订阅”模式的消息传输协议。
优点：协议简洁、小巧、可扩展性强、省流量、省电，目前已经应用到企业领域（参考： http://mqtt.org/software），且已有C++版的服务端组件rsmb。
缺点：不够成熟、实现较复杂、服务端组件rsmb不开源，部署硬件成本较高。
方案5、使用XMPP协议（Openfire + Spark + Smack）
简介：基于XML协议的通讯协议，前身是Jabber，目前已由IETF国际标准化组织完成了标准化工作。
优点：协议成熟、强大、可扩展性强、目前主要应用于许多聊天系统中，且已有开源的Java版的开发实例androidpn。
缺点：协议较复杂、冗余（基于XML）、费流量、费电，部署硬件成本高。
方案6.使用第三方平台
简介：使用第三方的消息推送平台。现今主流的推送平台分为------
手机厂商类：如小米推送、华为推送...
第三方平台类：友盟推送、极光推送、个推...
BAT大厂的平台推送：阿里云移动推送、腾讯云移动推送、百度云推送。
下面会详细介绍。
part4：第三方消息推送平台详细介绍
1.主流的第三方推送平台分类
手机厂商类：小米推送、华为推送...
第三方平台类：友盟推送、极光推送、个推...
BAT大厂的平台推送：阿里云移动推送、腾讯移动推送、百度云推送
2. 对比其他推送方式的特点
- 可以有效降低成本
上述的推送大多数是免费的，假如自己实现则消耗过多资源（开发成本和后台管理、统计成本）
- 消息到达率高
如果一个手机里有多个App使用了同一家推送服务，那么这些App将共用一条消息通道，即使你家的App推送服务被杀死了，那么只要用户打开了其他集成该推送服务的App，你家的推送就能到达用户。
- 安全性低
使用别人的服务器，数据还是有泄露的风险的。(但是有些推送服务支持私有服，需要￥)
- 服务会被杀死
由于Android系统的机制，后台推送 Service 会被各种主动的或是被动的行为给杀死，而服务一旦被杀死，意味着就接收不到推送消息。(有些推送服务支持集成厂商通道，所以集成厂商通道可以提高（离线）推送到达率，但是也是需要￥)
part5：如何选择第三方平台推送服务？
了解了第三方推送的特点，我们应该如何选择呢？很有必要说清楚三个需要注意的原则。
1.手机厂商推送
请记住一个潜规则：操作系统是不会杀死属于自己品牌的推送服务。
手机厂商的推送服务在自家的手机上属于系统级别的服务，这意味着系统不会杀死自家的推送服务。比如说，Android原生系统是不会杀死C2DM消息推送服务，MIUI系统是不会杀死小米的推送服务。
（小米推送官网截图 - 集成应用）
从小米推送官网可以看到目前市场主流的app大都集成了小米推送。
2. 第三方平台类
请记住一个规则：推送系统会共享一条推送渠道。
这意味着假设你接入了友盟推送，而恰好今日头条也接入了友盟。有一天你的App被杀死了，但这时用户启动了今日头条，那么推送系统也就会通过共享的推送通道顺便把你推送消息送达到手机上（推送到达率得到提高），然后还可能把你的进程也唤醒（被“保活”了）。所以说，关于如何选择第三方平台类的推送，推送平台的规模效应就很重要了。
那如何得知他们的规模和市场份额呢？主要看两点：
-
问内部的朋友。
- 看推送平台的合作客户里有哪些大的app - 参考对应官网的合作案例。
（个推官网截图 - 集成应用）
3. BAT大厂的推送
一句话：BAT大厂的推送其实并没有什么优势。
有人可能会觉得用了腾讯移动推送，就能占上微信的光保证你的App永远不会被杀死，那是幻想了。至于阿里云的移动推送，也看不出市场上有多少主流应用使用了它，但我却在其它平台看出淘宝使用了其它的第三方推送（比如友盟推送，小米推送）。
除了上边三个原则，我们在选择推送平台时还需要考虑的因素有：
用户群体属性（设备）：什么样的用户群体，使用什么样的设备居多。进而可以考虑手机厂商。
到达率：如是否要集成小米华为推送，或者选择第三方平台时是否要集成厂商通道，第三方平台的规模...
实现成本：人力成本,时间成本，资金成本...
所以，我们需要根据自己的情况来进行消息推送平台的选择。
part6：推送消息类别的选择
1. 推送消息的类别
通常第三方推送平台都支持两种推送消息类型：通知栏消息和透传消息。
通知栏消息：该类消息在被送达用户的设备后，直接以系统通知栏的形式展示给用户不会继续被传递到App。
透传消息：该类消息在被送达用户的设备后，还会继续传递到App，通过回调App的某个BroadcastReceiver的形式将消息传递到App内部。然后由App决定如何处理和显示这个消息。
所以透传消息不一定会以系统通知栏的形式进行推送，由程序猿自定义。
2.消息类别的区别与特点
二者的区别在于：透传消息在整个消息传递过程中比通知栏消息多了一步——传递到App
通知栏消息的优点：送达率高
因为透传消息在整个消息传递过程中比通知栏消息多了一步-传递到App，因此透传消息就增加一些被系统限制的概率，给系统杀死的概率就高一些，所以说，通知栏消息比透传消息应该能提供更好的送达率。
透传消息的优点：
- 对消息操作程度高 & 自定义程度高。
- 提供了对消息数据的更灵活的操纵能力。
- App如果仅仅通过通知栏消息，是无法接触到消息数据本身的。
- 可自定义通知提醒的样式（包括提示样式、提示形式如声音等等）
总结
上边不仅对推送和推送的实现方案以及第三方推送进行了全面细致的介绍，也对选择第三方推送时需要考虑的因素和要注意的事项进行了说明。虽然并没有对安全和如何提高消息到达率问题进行单独介绍，却有所提及的穿插在其它内容里了。希望各位看完能有所收获。