(4.2.12.2)浅谈第三方推送[API的不同]:百度推送、小米推送、华为推送
2016-06-02 14:59
1281 查看
在上一章节,我们了解了推送的基本集成,在本章节分析他们在使用上的不同
录入时版本号:
百度——2016-05-27 Android V5.0.0
小米——2.2.21版 于2015.11.30更新
华为——Push SDK V2.7.05于2016年1月28日
同一台设备对应唯一一个channel_id;
同一台设备上的不同应用对应不同的user_id;
同一台设备上的相同应用对应唯一一对[channel_id, user_id];
不同的设备对应不同的channel_id,若channel_id不同,user_id一定不同;
对于Android设备百度账户体系:
同一台设备对应唯一一个channel_id;
同一台设备上若有不同的用户登陆了同一个应用,那么就会有不同的user_id;
若同一个用户在多个设备上登陆了相同的应用,那么得到的将都是同一个user_id;
小米 onCommandResult函数参数列表
华为 onEvent函数参数列表
答:首先解释一下透传和通知栏方式的原理,透传是指当小米推送服务客户端SDK接收到消息之后,直接把消息通过回调方法发送给应用,不做任何处理;而通知栏方式,则在设备接收到消息之后,首先由小米推送服务SDK弹出标准安卓通知栏通知,在用户点击通知栏之后,激活应用。 在非MIUI系统中,由于维护小米推送服务长连接的service是寄生在App的运行空间当中的,因此透传和通知栏方式在送达率上并没有任何区别,都需要应用驻留在后台。即,如果一台设备通知栏消息能够接收到并弹出,那么其透传消息也同样能接收到。 在MIUI系统中,由于长连接是由MIUI系统服务建立并维护的,因此在接收消息的时候并不需要应用驻留后台。如果采用通知栏方式接收消息,由于通知栏也是MIUI系统服务弹出的,就可以做到不需要用户后台驻留或者可以自启动消息就能送达。而如果采用透传消息,由于需要直接执行应用的代码,因此即使消息已经到了系统服务,如果应用没有驻留后台或者能自启动,消息依然不能送达,需等下次用户手动点击激活应用后,才能接收到消息。 综上,在MIUI系统中,通知栏消息的送达率会远高于透传方式;在非MIUI系统中,通知栏和透传方式的送达率是一样的。
regID是根据什么生成的?会不会经常变化?
答:regID是在客户端向小米推送服务注册时,小米推送服务端根据设备标识、appID以及当前时间戳生成,因此能够保证每个设备上每个app对应的regID都是不同的。当app注册成功后,小米推送服务客户端SDK会在本地通过shared_prefs来保存这个regID,之后app调用注册,SDK后会在本地直接读取出这个regID并直接返回,不会重新请求服务器。因此只要应用不卸载重装或者清除应用本地数据,regID就不会变化。否则,如果SDK没有从本地读取到缓存的regID,则会向服务端重新请求,此时regID会重新生成。
如果我使用通知栏类型消息,能否在通知栏消息到达之前,先执行一段app的代码?或者在通知栏到达时,通知app?
答:在MIUI系统上,通知栏类型的消息,是不需要应用启动就能弹出的(这一特性决定了通知栏消息的弹出可以不受应用自启动管理的影响),因此在整个弹出通知栏消息的过程中,app是完全不可感知的,当用户点击通知栏消息之后,才会执行到app的代码。
录入时版本号:
百度——2016-05-27 Android V5.0.0
小米——2.2.21版 于2015.11.30更新
华为——Push SDK V2.7.05于2016年1月28日
百度、小米、华为推送一览
属性
平台 | 百度 | 小米 | 华为 | 备注 |
---|---|---|---|---|
标示 | channeid | regid | token | 向Push服务请求应用的唯一标示 |
userid | 详见备注1 | |||
应用ID | APP ID | AppID | ||
应用key | API KEY | AppKey | ||
应用秘钥 | SECRET KEY | AppSecret | ||
标签 | tag | topic | tag | |
别名 | alias | |||
统一账户 | userAccount | 第三方命名账户 | ||
请求id | requestid | 每次与第三方服务器交互时,请求的id号 | ||
管理者 | PushManager | MiPushClient | PushManager | 推送服务的app方的管理类 |
接收器 | PushMessageReceiver | PushMessageReceiver | PushEventReceiver |
管理类
平台 | 百度 | 小米 | 华为 | 备注 |
---|---|---|---|---|
名称 | PushManager | |||
Push服务初始化及绑定 | startWork;注意:不要在Application的onCreate里去做startWork的操作。 | registerPush | requestToken | |
停止Push服务 | stopWork | unregisterPush | deregisterToken | 停止本应用Push服务进程,并且完成unbind工作 |
恢复Push服务 | resumeWork | 恢复本应用Push服务,并且再次完成bind工作 | ||
暂停接收 | pausePush | enableReceiveNormalMsg与enableReceiveNotifyMsg | ||
恢复接收 | resumePush | enableReceiveNormalMsg与enableReceiveNotifyMsg | 这时服务器会把暂停时期的推送消息重新推送过来 | |
设置免打扰时段 | setNoDisturbMode | setAcceptTime | 设置免打扰模式的具体时段,该时间内处于免打扰模式,通知到达时去除通知的提示音、振动以及提示灯闪烁 | |
查询push是否被停止的接口 | isPushEnabled | requestPushState | ||
设置Tag | setTags | subscribe | setTags | 用于设置标签;成功设置后,可以从管理控制台或您的服务后台,向指定的设置了该tag的一群用户进行推送 |
删除Tag | delTags | unsubscribe | deleteTags | 用于删除标签 |
列举Tag | listTags | getAllTopic | getTags | 用于列出本机绑定的标签 |
设置别名 | setAlias | 开发者可以为指定用户设置别名,然后给这个别名推送消息,效果等同于给RegId推送消息。注: 一个RegId可以被设置多个别名,如果设置的别名已经存在,会覆盖掉之前的别名 | ||
取消别名 | unsetAlias | |||
获取别名 | getAllAlias | |||
设置userAccount | setUserAccount | |||
取消UserAccount | unsetUserAccount | |||
设置通知的Builder | setNotificationBuilder | 设置通知栏样式,并为样式指定编号。在管理控制台或您的服务后台中,您可以指定相应的编号,让客户端显示预先设定好的样式 | ||
设置默认的通知Builder | setDefaultNotificationBuilder | 设置默认的通知栏样式;如果推送通知时不指定id的样式,都将显示该默认样式 | ||
设置富媒体通知的Builder | setMediaNotificationBuilder | 为富媒体通知设置样式 | ||
开启精确LBS推送模式 | enableLbs | 开启精确LBS推送模式,覆盖最近半小时内在指定区域出现过的终端 | ||
关闭精确LBS推送模式 | disableLbs | |||
上报点击的消息 | reportMessageClicked |
备注1:百度推送
对于Android设备无账户体系:同一台设备对应唯一一个channel_id;
同一台设备上的不同应用对应不同的user_id;
同一台设备上的相同应用对应唯一一对[channel_id, user_id];
不同的设备对应不同的channel_id,若channel_id不同,user_id一定不同;
对于Android设备百度账户体系:
同一台设备对应唯一一个channel_id;
同一台设备上若有不同的用户登陆了同一个应用,那么就会有不同的user_id;
若同一个用户在多个设备上登陆了相同的应用,那么得到的将都是同一个user_id;
接收器Receiver
平台 | 百度 | 小米 | 华为 | 备注 |
---|---|---|---|---|
命名 | PushMessageReceiver | PushMessageReceiver | onToken | |
获取绑定请求的结果 | onBind | onReceiveRegisterResult或onCommandResult | ||
获取绑定状态 | onCheckBindState | getPushState | ||
stopWork的回调函数 | onUnbind | onReceiveRegisterResult或onCommandResult | ||
接收透传消息的函数 | onMessage | onReceivePassThroughMessage | onPushMsg | |
接收通知到达的函数 | onNotificationArrived | onNotificationMessageArrived | onEvent | |
接收通知点击的函数 | onNotificationClicked | onNotificationMessageClicked | onEvent | |
setTags的回调函数 | onSetTags | onCommandResult | onEvent | |
delTags的回调函数 | onDelTags | onCommandResult | ||
listTags的回调函数 | onListTags | onCommandResult | ||
设置别名的回调 | onCommandResult | |||
删除别名的回调 | onCommandResult | |||
设置通知时间的回调 | onCommandResult | |||
暂停推送的回调 | onCommandResult | |||
唤醒推送的回调 | onCommandResult |
参数列表 参数说明 message 服务器返回的命令封装在 MiPushCommandMessage的对象中,可以从该对象中获取command、commandArguments、 resultCode、 reason等信息。 command表示命令的类型。 调用MiPushClient.registerPush(),返回MiPushClient.COMMAND_REGISTER 调用MiPushClient.setAlias(),返回MiPushClient.COMMAND_SET_ALIAS 调用MiPushClient.unsetAlias(),返回MiPushClient.COMMAND_UNSET_ALIAS 调用MiPushClient.subscribe(),返回MiPushClient.COMMAND_SUBSCRIBE_TOPIC 调用MiPushClient.unsubscribe(),返回MiPushClient.COMMAND_UNSUBSCIRBE_TOPIC 调用MiPushClient.setAcceptTime(),返回MiPushClient.COMMAND_SET_ACCEPT_TIME 调用MiPushClient.pausePush(),返回MiPushClient.COMMAND_SET_TARGETPT_TIME 调用MiPushClient.resumePush(),返回MiPushClient.COMMAND_SET_ACCEPT_TIME commandArguments 表示命令的参数。例如: 注册app就会返回app本次初始化所对应MiPush推送服务的唯一标识regId,alias就会返回alias的内容,订阅和取消订阅主题就会返回topic,setAcceptTime就会返回时间段。 resultCode 表示调用命令的结果。如果成功,返回ErrorCode.Sussess即0;否则返回错误类型值。 reason表示调用命令失败的原因。如果失败,则返回失败原因,否则返回为null。
华为 onEvent函数参数列表
NOTIFICATION_OPENED, //通知栏中的通知被点击打开 NOTIFICATION_CLICK_BTN, //通知栏中通知上的按钮被点击 PLUGINRSP, //标签上报回应
通知样式
平台 | 百度 | 小米 | 华为 | 备注 |
---|---|---|---|---|
自定义通知Builder | BasicPushNotificationBuilder | 自定义通知状态栏构建类构造函数(定制通知栏基础样式) | ||
自定义通知Builder | CustomPushNotificationBuilder | 自定义通知状态栏构建类构造函数(定制通知栏基础样式及layout) | ||
设置通知flags | setNotificationFlags | 定制 Android Notification 里的flags | ||
设置通知defaults | setNotificationDefaults | 定制 Android Notification 里的defaults | ||
设置通知状态栏icon | setStatusbarIcon | 定制 Android Notification通知状态栏的icon图标 | ||
设置通知样式图片 | setLayoutDrawable | 定制自定义layout中显示的图片 | ||
设置通知样式声音 | setNotificationSound | 自定义推送的声音 |
推送配置
平台 | 百度 | 小米 | 华为 | 备注 |
---|---|---|---|---|
PushSettings | ||||
调试模式 | enableDebugMode | |||
支持
平台 | 百度 | 小米 | 华为 | 备注 |
---|---|---|---|---|
启动点 | 非“Application的oncreate()” | Application的oncreate() | 非“Application的oncreate()” | 启动推送服务的位置 |
小米
透传和通知栏,在送达率上有什么分别?答:首先解释一下透传和通知栏方式的原理,透传是指当小米推送服务客户端SDK接收到消息之后,直接把消息通过回调方法发送给应用,不做任何处理;而通知栏方式,则在设备接收到消息之后,首先由小米推送服务SDK弹出标准安卓通知栏通知,在用户点击通知栏之后,激活应用。 在非MIUI系统中,由于维护小米推送服务长连接的service是寄生在App的运行空间当中的,因此透传和通知栏方式在送达率上并没有任何区别,都需要应用驻留在后台。即,如果一台设备通知栏消息能够接收到并弹出,那么其透传消息也同样能接收到。 在MIUI系统中,由于长连接是由MIUI系统服务建立并维护的,因此在接收消息的时候并不需要应用驻留后台。如果采用通知栏方式接收消息,由于通知栏也是MIUI系统服务弹出的,就可以做到不需要用户后台驻留或者可以自启动消息就能送达。而如果采用透传消息,由于需要直接执行应用的代码,因此即使消息已经到了系统服务,如果应用没有驻留后台或者能自启动,消息依然不能送达,需等下次用户手动点击激活应用后,才能接收到消息。 综上,在MIUI系统中,通知栏消息的送达率会远高于透传方式;在非MIUI系统中,通知栏和透传方式的送达率是一样的。
regID是根据什么生成的?会不会经常变化?
答:regID是在客户端向小米推送服务注册时,小米推送服务端根据设备标识、appID以及当前时间戳生成,因此能够保证每个设备上每个app对应的regID都是不同的。当app注册成功后,小米推送服务客户端SDK会在本地通过shared_prefs来保存这个regID,之后app调用注册,SDK后会在本地直接读取出这个regID并直接返回,不会重新请求服务器。因此只要应用不卸载重装或者清除应用本地数据,regID就不会变化。否则,如果SDK没有从本地读取到缓存的regID,则会向服务端重新请求,此时regID会重新生成。
如果我使用通知栏类型消息,能否在通知栏消息到达之前,先执行一段app的代码?或者在通知栏到达时,通知app?
答:在MIUI系统上,通知栏类型的消息,是不需要应用启动就能弹出的(这一特性决定了通知栏消息的弹出可以不受应用自启动管理的影响),因此在整个弹出通知栏消息的过程中,app是完全不可感知的,当用户点击通知栏消息之后,才会执行到app的代码。
相关文章推荐
- Android仿今日头条APP实现下拉导航选择菜单效果
- 访问统计
- POJ 3752 字母旋转游戏
- Python——目录操作
- 欢迎使用CSDN-markdown编辑器
- Python实现优先级队列结构的方法详解
- es5、6新添加的js方法
- Jmeter之参数化
- mysql删除重复数据
- lua select(a,b)函数
- 使用nagios监控被监控主机上的应用服务mysql数据库 (一)
- 生成随机唯一号码, 比如订单号
- 关于图片的压缩(大小压缩和质量压缩)BitmapFactory.Options详解
- 从虚幻 4 中采集 360 度立体电影
- jsp页面上的东西
- IaaS, PaaS和SaaS公司都做些什么
- java list排序
- 【Android新手笔记五】okhttp3网络通信框架
- 设计模式05_抽象工厂模式
- 轮播图简单实现