前端时间研究APP消息推送的机制,由于机型、版本的碎片化,消息推送的机制不太好理解,所以飘易总结下,放在博文里以备后续查阅。
安卓Android系统的消息推送:
安卓 | ||||||
推送方式 | 应用状态 | 类型 | 消息中心 | 触发receive | 触发click | |
远程推送 | 应用在前台 | 1、普通消息 | 进入 | 不触发 | 不触发 | |
2、透传消息且符合格式 | 进入 | 不触发 | 触发 | |||
3、透传消息且不符合格式 | 不进入 | 触发 | 不触发 | |||
应用不在前台 | 进程 存活 | 1、普通消息 | 进入 | 不触发 | 不触发 | |
2、透传消息且符合格式 | 进入 | 不触发 | 触发 | |||
3、透传消息且不符合格式 | 不进入 | 不触发 | 不触发 | |||
本地推送 | 应用在前台 | 进入 | 不触发 | 不触发 |
苹果iOS系统的消息推送:
iOS | ||||
推送方式 | 应用状态 | 消息中心 | 触发receive | 触发click |
远程推送 APNs | 应用在前台 | 不进入 | 触发 | 不触发 |
应用不在前台 | 进入 | 不触发 | 触发 | |
本地推送 | 应用在前台 | 进入 | 触发 | 不触发 |
Android:
触发click事件: 发送透传数据并且格式为标准格式。
触发receive事件:发送透传数据且格式为非标准格式且应用在活动。(消息栏不会有提示!)
iOS:
在线:只能响应receive,但消息中心无消息;
不在线:消息中心有消息,且响应click事件.
push是一个可用但不可依赖的功能。
1. 手机用户有自主关闭推送的权利,如果被关闭自然无法收到push。
2. Android的push更不可依赖,Android rom厂商为了省电会禁止push进程开机自启、三方清理软件会杀掉push进程。
不止是个推,所有非大厂的app,没有进入rom厂商和三方清理软件白名单的app,不管用哪个推送方案都可能会被杀。
本质上推送是一个有利于开发商但却很容易造成用户骚扰和费电的功能。
所以大多数主流app里的push的实际用处都是拉激活的非实时活动推送。
如果app主体在运行期且需要实时推送,应该使用js与服务器长链接或轮询比如socket.io方案。
用户可以使用JS代码监听推送的消息,现在可以监听“receive”事件和“click”事件。如应用在前台时收到推送消息,在IOS平台会触发“receive”事件回调,在Android平台如发送的是透传消息并且消息不符合格式时会触发“receive”事件。
当用户点击消息中心里的消息时会启动应用,并且在监听push事件的页面触发“click”事件。
【参考】: