移动端推送

推送的目的

主要是出于产品的角度考虑,主要功能如下:

  • 功能提醒:各个APP的系统提醒,比如淘宝的交易物流提醒、支付宝的转账到款提醒、微博的特别关注提醒、点评的订单/订座服务通知等,当然也包括微信QQ的IM消息~

  • 温馨服务/引导:各个APP引导使用核心功能的通知,如消费后邀请写点评、问答邀请……

  • 个性化内容:与“人地时”场景相关的各种偏营销型的推送,主要是基于用户行为偏好的推荐;

  • 兜底/冷启动:平台大型活动通知、社会热点等等。

对于我们 App 目前主要的目的就是功能提醒了

现状

iOS 推送现状

iOS 是使用苹果公司统一的推送机制,APNS(Apple Push Notification service),iOS 上推送的送达率几乎 100%

Android 推送现状

1、GCM(Google Cloud Messaging)Google 在推出 Firebase 云服务之后,更名为了 FCM,谷歌提供的服务国内不能正常使用。
2、国内手机厂商提供的推送,只有华为/小米/魅族 三家公司提供
3、其他的手机就只能使用线程保活手法自己处理消息的收发。主要有 push 和 pull 两大类别,我会在下面详细解释。

  • 国内 Android 推送的送达率参差不齐,使用华为/小米/魅族自带的推送送达率他们声称是100% 但是我们测试发现可以达到百分之八九十左右,还算可行;
  • 使用线程保活在5%以内。这里的送达率是指在从后台杀掉 App 后 App 任然能收到推送。这个送达率是之前我们做过的一个测试得出的结果,有一定的可靠性可以作为参考。

为什么 Android 推送的送达率那么低?

推送原理

无论 Android 还是 iOS 推送最根本的原理都是一样的,很简单就是手机端和服务器保持一个长连接,有消息时服务端就给手机端发一个消息。原理很简单,但是实现方式的不同导致我们的体验有很大的差别

iOS 推送原理

这就是 APNs 的逻辑所在:iOS 自己做个长驻后台保持连接。所有应用,有必要(申请)并且被允许(用户可以改设置)的话,可以通过 APNs 中转到达用户。如下图:

image.png

Android 推送原理

Android 是每个 App 都可以设置自己常驻线程,保持后台长连接。大家可能会说这是好事情,所有都可以保持链接,这样都能收到推送,为什么现在的体验还很差。

因为所有的 App 都可以保持常驻线程,谷歌的初衷是让开发者用到的时候才开启常驻线程,但实际情况是大家无论用不用到都会让App 保持常驻线程,这样手机耗电就急剧增加,这是谷歌和其他手机厂商不能容忍的。手机厂商干脆就显示所有的常驻线程,这就导致了 Android 推送的送达率很低。

Android 推送的解决方案

第一种方案是系统实现方案:轮询(Pull)方式、SMS(Push)方式、持久连接(Push)方式、C2DM云端推送、MQTT协议推送、RSMB推送功能等方式。每种系统实现方案都存在问题:不稳定,性能低,不及时等;
第二种方案是第三方互联网厂商提供的方案,比如极光、友盟和个推等推送平台;
第三种方案是手机厂商的推送方案,比如小米和华为。第二种和第三种方案也存在不稳定,性能低,不及时,耗电等问题;
第四种方案是自建推送平台,包括自建服务器和通讯协议,但是成本和人力物力需求比较大;

下面详细介绍一下第一种方案中的几种实现方式:

  • 轮询(Pull)方式:应用程序隔固定时间主动与服务器进行连接并查询是否有新的消息。
  • SMS(Push)方式:服务器有新消息时,发送1条类似短信的信令给客户端,客户端通过拦截信令,解析消息内容 / 向服务器获取信息
  • 持久连接(Push)方式:客户端和服务端保持长连接,有消息服务端给客户端发消息
  • C2DM云端推送:Cloud to Device Messaging,云端推送。谷歌提供的解决方案,国内用不了。

以上每种系统实现方案都存在问题:不稳定,性能低,不及时等,所以 Android 的推送一般都是同时使用多个方案。目前国内的解决方案普遍使用轮询和保持持久链接的方式。

我们的机制

了解了原理,接下来就要看下我们实现推送的解决方案是什么。iOS 不用多说,肯定是使用官方提供的推送方案。主要是 Android 的解决方案。

目前比较成熟的解决方案

第一种方案是第三方互联网厂商提供的方案,比如极光、友盟和个推等推送平台;
第二种方案是手机厂商的推送方案,比如小米/华为/魅族。第二种和第三种方案也存在不稳定,性能低,不及时,耗电等问题;
第三种方案是自建推送平台,包括自建服务器和通讯协议,但是成本和人力物力需求比较大;

第一种方案优点是使用了相同推送厂商的 App 可以互相借力,缺点是不稳定。
第二种方案比第一种方案相对要稳定些,但是即使是系统级别的推送服务,也不是百分百保证消息送达。这里比较奇葩的是华为推送,华为的推送一些问题,他们自己的技术都搞不定了,下面是他们技术支持给出的描述(原话):

华为手机上:
Emui3.0上,Push广播有很大概率被限制,如: Mate7 3.0版本,荣耀6plus,P7 3.0版本,4X, 4A等。
Emui3.1上,Push广播基本不被限制,但个别型号机型存在问题,如:荣耀5x等。
Emui4.0及以上,Push广播有较高概率被限制,不被限制的机型如:荣耀畅玩4C,荣耀畅玩4X,Mate S,P8 MAX等。
如广播被限制,需要将应用设为开机启动项。所以对于及时性或到达率要求非常高的应用,我们建议应用要考虑替代方案。
后续Push版本,华为将采用新的设计方案,解决被限制的问题,但发布计划待定。

另外,至于限制的问题,其实华为sdk还是能接收到推送消息的,当将消息通过广播发送给应用是,如果手机管家查到该应用处于stop状态,那么会拦截该广播的。

我们的选择

iOS 使用极光推送集成的官方方案
小米手机使用小米系统推送
华为使用华为系统推送
其他的型号手机使用极光推送

ps:不要感觉微信,淘宝这些 App 的用户量大就去选择腾讯和阿里的推送服务,官网在不是很明显的地方说明了他们使用的是同一套技术,但是走的不是同一条推送路线。所以不用想着去蹭微信、淘宝的流量了。被坑过~~