android 推送选型和混合设计

android里面每个点好好做都是可以玩出很多花样的，推送也是同样如此啊，最近这不国家开始制定统一推送标准了不，但是啥时候可以开始用还是一个未知数，那么就来说说现在的常用的推送设计，大概的说下各个推送

google 的 GCM 在国内被墙了，要不也不用大家费事了，所以现在市场上催生出来太多的推送服务商，按照级别可以按如下分类：

• 大牌级
  • 微信，QQ
• 系统级推送
  • 小米推送，华为推送，魅族推送
• 第三方厂商推送
  • JPush，友盟，个推，百度云推送，腾讯信鸽，阿里云推送
• 混合推送
  • 云巴推送，LeanCloud推送

大牌级

为啥说是大牌呢，微信，QQ那可是亿级应用啊，说话的分量十足啊，大家都知道推送接受的核心就是承载长连接服务的进程会不会被系统杀死，微信，QQ他们可是和国内大部分厂商谈妥了把微信，QQ放入系统强杀的白名单，不会被杀死，这商务合作的能力不得不佩服啊，不过啊，也不是每个厂商都谈好了，我得VIVO手机可是能杀微信进程的。

系统级推送

什么是系统级推送呢，就是和google 的 GCM 一样，推送进程是系统级别的，不会被杀死，所在相应的厂商系统上可以做到随时接受推送消息，但是国内的事大家知道的，小米和华为不对户，小米的推送在华为系统上是无法运行的，魅族的推送是刚刚才出来的，集成的app应该不多。系统级推送一般都是在那个系统上用哪个公司的推送，比如小米的机器上用小米推送，系统级的优势是很明显的，不容错过。

第三方厂商推送

这个不用说了吧，不是上面3个厂商的推送服务都是第三方推送。但是呢，根据具体实现分成2个档次：

• 传统型的：一个app启一个长连接进程，非常耗费系统资源和电量
• 优化型的：合并长连接，使用同一个长连接跑所有的集成同一套推送的所有app。简单来说就是10个同样使用一种推送的app，只要有一个app处于活动状态，那么剩下9个app的推送都能及时收到，因为优化过后只使用一个长连接，所以是很节省系统性能和电量的。

优化型的推送有：友盟，个推，百度云推送

友盟推送的原话：优质的服务质量，实现了同一设备多 APP共享一个长连接、智能心跳等优化方案。消息发送速度快，长连接稳定，设备能耗低。

混合推送

这个呢就是结合了上面2种推送，若手机系统厂商推送推送服务，那么就是用这个厂商的推送，剩下的没有系统级推送的使用第三方推送。解释起来很简单，也很容易理解，本质上就是一种资源优化方式摆了，但是呢集成几种系统级推送的设置比我们写也没省什么事，就是代替我么完成了手机系统类型的判断。因为魅族推送出来的时间不长，目前的混合推送都是不支持的。另外我们还是要看这个混合推送自身的推送技术实现的，貌似我没发现这2个混合推送的自身实现是优化型的，还是传统型的实现。

设计总结

说到这，其实各位看官自己心里应该有个抉择了，混合推送的方式是目前最有的方式了，我还是倾向于自己实现，一部分原因是目前的混合推送不支持魅族推送，另一部分原因是混合推送自身的实现不是太好。所以觉得还是自己做混合推送好：3个系统推送+优秀/顺手的第三方厂商推送。

最后说下，目前的第三方推送中说哪个好用的都有，各个地方转一圈过来，大伙还是喜欢 个推，飞鸽，友盟的多一些

• 推送设计:

  • 安卓推送这背后件小事
  • 消息推送的思考

• 推送类型协议：

  • 手把手带你全面了解Android消息推送 解决方案

---

参考资料

• 大厂的推送设计

  • 架构师于小波：魅族实时消息推送架构
    里面包含推送后端设计

• 项目需求讨论-Android推送及Activity启动方式

• Android 进程保活招式大全