Android推送五花八门的根源：GCM缺失与厂商定制

消息推送根据不同途径分为短信、邮件、站内信、App推送。除App外的三种途径，技术上没什么难度，基本上调用不同服务商的API即可完成——短信依赖运营商接口，邮件依赖邮件服务商接口，站内信是系统自身提供的功能。App推送则分iOS和Android两大平台，二者的技术复杂度呈现出鲜明反差：iOS系统比较规范和封闭，基本上只能使用苹果统一提供的APNS，技术方案高度统一；但Android完全不同——在国外，用GCM和APNS差别不大，但在国内情况复杂得多：一是GCM在国内不能用，二是国内各手机厂商都有自己定制的Android系统，消息推送的实现也各不相同。这两个因素叠加，导致Android的消息推送生态变得五花八门：大部分有实力的大厂会自己实现一套推送机制（如阿里云移动推送、腾讯信鸽推送、百度云推送），也有第三方公司提供商业推送服务（如友盟推送、极光推送）。通常对于中小公司，如果不涉及敏感数据，Android系统上推荐直接使用第三方推送服务，因为对方是专业做推送的，消息到达率有一定保证；只有涉及敏感数据的业务才需要自己实现消息推送，这时会面临真正的技术挑战。自建消息推送主要包含设备管理（唯一标识、注册、注销）、连接管理、消息管理三个功能，其中”连接保活”是整个消息推送设计中细节和黑科技最多的地方——因为应用不可能一直在前台运行，大部分设备为了省电省流量都会限制应用后台运行，一旦被限制，连接通道就可能被中断，导致消息无法及时送达，业界为此发展出应用互相拉起、找手机厂商开白名单等各种手段来维持连接存活。