某学姐

Android Female Developer, Technology Fan, Reader.

Android学习笔记——消息推送

2018-07-28 | Comments

1、小米推送
(1)通知栏消息/透传消息
(2)工作原理
2、极光推送
3、FCM - Firebase Cloud Message
4、推送接入策略
5、参考文档

1、小米推送

(1)通知栏消息 / 透传消息

通知栏消息:在设备接收到消息之后,首先由小米推送服务SDK弹出标准安卓通知栏通知,在用户点击通知栏之后,激活应用。

透传消息:当小米推送服务客户端SDK接收到消息之后,直接把消息通过回调方法发送给应用,不做任何处理;

对于MIUI系统:

通知栏消息: 此时推送服务的长连接由MIUI系统维护,MIUI系统接收到推送,并弹出系统通知栏,点击系统通知栏发送一个广播告诉APP,然后APP监听到广播后处理一系列业务逻辑。 APP进程可以是死的,点击通知栏后拉起APP进程。
到达率高。

透传消息:
此时推送服务的长连接由MIUI系统维护,MIUI系统接收到推送,如果APP进程还活着则可以收到推送;如果APP进程死了则没法收到推送,需要等到下次用户手动点击激活应用后,才能收到消息。

此时通知栏消息的送达率会远高于透传方式。

关于透传需要APP进程活着,通知栏不需要APP进程活着的思考:
我认为是MIUI出于省点的设计,对透传和通知栏处理方式的权限不同。对于透传过来的消息,不会主动去唤醒APP进程;而通知栏过来的消息,由于主动权交给用户了,只有当用户点击通知栏才会唤醒APP进程。

对于非MIUI系统:

此时长连接服务寄生在APP运行空间。不管是透传和通知栏都需要应用活着,并且两者到达率一样。

小结:
具体走通知栏消息还是透传消息,在服务端发推送消息的时候是可以设置的,默认情况是通知栏消息。
对于MIUI系统,推荐使用MiPush的通知栏通知方式。对于非MIUI系统,MiPush不是很稳定,可以考虑使用JPush。 同理,对于华为手机,使用华为Push的通知栏通知方式,对于非华为手机,可以考虑使用JPush。 所谓的保活就是针对透传消息。pushservice进程直接影响消息的到达率。

推送通道:
在MIUI系统中,push服务的消息走的是系统通道,不需要应用单独建立连接。
在非MIUI上,通道会建立在每个app的进程中,每个接入mipush服务的app都会建立一条单独的通道。

其他 手机厂商+厂商推送 套路应该都差不多。

小米11.11:海量数据压力下的推送服务

(2)工作原理

1、开发者到小米开放平台申请推送服务使用权限,得到自己APP对应的AppId, AppKey, AppSecret。 其中 AppId 和 AppKey 是客户端的身份标识,在客户端SDK初始化时使用; AppSecret是服务器端的身份标识,在使用服务端SDK向客户端发送消息时使用。

2、客户端注册推送服务时,服务端会生成一个regID,唯一标识设备上的一个APP,并返回给客户端。
regID生成方式:设备标识 & appID & 当前时间戳之间一个算法
一般来说regID是不变的,regID生成后Client SDK会通过sp缓存,之后再次注册推送时如果SDK发现regID非空则不会重新请求服务。不过当应用卸载或清除应用数据时regID会清空。

3、服务端可以根据:RegID、别名、userAccount、标签来进行推送。

4、PushMessageReceiver#onReceivePassThroughMessage 收到透传消息的回调;
PushMessageReceiver#onNotificationMessageClicked 点击通知栏消息的回调;

推送其实就是维护一个Socket长连接。通信协议可以基于MQTT、XMPP或自定义协议,MiPush是基于XMPP协议实现的。

小米推送Android版快速接入指南
小米推送常见问题汇总

2、极光推送**

小米、华为设备可以使用自家的推送SDK,那么其他厂商的设备则可以使用JPush。

极光推送是比较好用的第三方推送,稳定性到达率各方面都比较好。有免费通道和付费通道两种选择。

关于应用相互唤醒:
之前说BAT全家桶APP之间可以相互唤醒。
只要运行一个百度系app或者某一app监听系统广播自启,该app会以广播或者服务的方式拉起手机中其他系列app.
主要通过在AndroidManifest指定相同的action:com.baidu.android.pushservice.action.xx, baidu.intent.action.account.SHARE_SERVICE实现启动。

接入个推/友盟SDK的APP之间相互唤醒原理大同小异,总之就是相互拉起进程。

但是现在应该是不能相互唤醒了,国内厂商应该有做这方面的优化。

关于的思考: 进程死掉的状态下,以前静态注册是可以接收到广播的。现在很多厂商都做了优化,收不到广播。
target 26之后,限制了系统隐式广播的静态注册,因此大大降低了静态广播拉起进程的概率。

https://developer.android.com/guide/components/broadcasts

开机自启动的思考:

3、FCM - Firebase Cloud Message

Firebase功能包括很多,其中Push功能官方文档:

https://firebase.google.com/docs/cloud-messaging/

Push推送后台:

https://console.firebase.google.com/

使用Firebase之前,需要先安装Google Play Service相关的应用。

为啥国内不能使用FCM,这个具体细节稍后再梳理。

iOS的推送等之后再了解,原理应该差不多。

4、推送接入策略**

我现在APP里同时集成了MiPush、华为Push、JPush,用于满足小米、华为和其他机型的推送需求。

一个设备一次只能通过一个推送渠道接收消息,不能同时通过几个渠道接收消息,不然消息会重复,乱套了。

推送渠道注册和推送渠道分发的策略是一致的: 如果是小米设备,注册MiPush;如果是华为设备,注册华为Push;如果是其他设备,注册JPush。
用户的注册信息最终会在第三方推送管理后台保存,所以管理后台使用同样的策略选择一个推送渠道推送消息。
运营人员直接点一键推送就可,不需要关心选的是哪个推送渠道。

5、参考文档**

本文原文发自 某学姐, 转载请保留出处, 谢谢.

Comments