android 接入腾讯信鸽
最近产品有用到信鸽，正好做一下分享，主要讲解一下android接入信鸽的缺陷和使用方法
- android推送实现的分类
- 信鸽推送流程与缺陷
- 信鸽接入及使用方式
android推送实现的分类
首先要明白android系统对于推送的限制，android的特殊机制 ：android系统对于休眠于后台的进程和service都可能会被杀死 基于这个机制 那么所有的基于长连接的推送都可能会被杀掉，特别是android5.0之后进程在后台时直接挂起，这个时候一般我们会把类似的业务放在service中，但service只是按照优先级来进行回收 service一样是可能会 被杀死的。google这样设计是因为android毕竟是个在一个要求低功耗的手机上运行，如果所有的app都在后台频繁的前期数据 那么这个很快电量将耗完。那么我们的推送又要求实时要求常驻 这个问题怎么解决？
- google FCM推送服务 当然首选它了 这个是google专门为解决推送而做的一套方案，类似于ios的推送：它的原理是他是系统进程所有的app只需要和它进行消息推送 它统一进行notify就可以了。可惜国内不能用google服务。
- 自己做一个tcp长连接 可以做在自己的service中 适当做一下存活，比如设置一下他的优先级；按照我们的之前的分析，这种模式有很大概率被杀掉，但好在当app在前台时是可以保证不被杀，这样一些对实时性要求不高的app可以采用这个，比如类似用mqtt实现
- 手机厂商推送接入 有的厂商在ROM中预制了一套自己的推送通道，但需要一个一个的去接入，现在手机厂商很多，这个不可取
4.手机厂商白名单，国内一般所有厂商对微信、qq这2个大杀器直接在rom设置系统白名单，这样系统不会杀死这2个应用，但这都需要商业合作，一般app厂家怕是不够格
5.友盟、信鸽、极光第三方推送服务接入，它有2方面一个是通过自己的方案实现2，第二个因为用它的服务的app较多，它在app A存活时也可以推送app B的消息 实现一个app相互拉起的机制，实质是流氓操作，但有一点就是它做的存活机制相对来讲更可靠，而且实现比较简单
综上所述我个人觉得我们应该采用第5套方案
信鸽推送流程与缺陷*
可以看到android失败的地方，主要还是第二个失败的地方，service未启动被杀死，理论上大概率失败的情况是在这个地方，这个是无法逾越的地方。
信鸽接入及使用方式
接入有2种方式 我们直接选择最简单的自动导入方案，不建议使用手动配置方案 比较繁琐
具体查看http://docs.developer.qq.com/xg/android_access/jcenter.html
我这里主要讲解一下信鸽内部代码适配业务
它的推送有2个机制
1. notify
信鸽本身是想做个后台发了消息后直接推送notify 整个流程不需要开发者在写什么代码，但这样的情况下很明显是严重的紧密耦合，遇到我们有特殊需求时我们没有办法进行二次开发
假设我们的业务知识简单推送然后显示notify 可以采取这个方案，它会做好所有的东西 包括现实推送。
重要的几个函数
onNotifactionShowedResult
onNotifactionClickedResult
2.消息透传
这个方案便于我们进行自定义，我们拿到消息后是notify还是直接处理，我们可以自己控制 也可以自己自定义notify
重要的函数
onTextMessage
我个人是采用的消息透传机制，这样我可以随心所欲控制代码 ，也符合软件开发的松耦合规范
以上2个机制的回调函数都是在实现XGPushBaseReceiver类后直接重写就可以了。当然java后台需要改为对应的消息透传。
这个文档主要是讲解android推送和信鸽内部的流程及机制分类，具体信鸽的接入官方文档更清晰就不细说，希望能给其他人有帮助，目前在实际使用中其实还存在单终端切换账号之类的问题，我看了一下官方的解释，看来迭代速度比较快，目前还是beta版本，下个版本会会解决这些问题，总的来说还是可以使用的。