推送简介及友盟推送集成要点

0.318字数 1998阅读 3159

推送简介

目前Android的推送平台有三种类型。

1、专业第三方推送:个推(收费服务比较好)、友盟(免费)、极光
2、手机厂商推送:小米、华为、魅族
3、BAT大厂的推送:百度云推送、腾讯信鸽推送、阿里云移动推送。

上述三种平台各有优势,手机厂商的推送在自己手机上属于系统级服务,理论上推送限制小消息到达率低;专业的第三方推送平台长时间精细耕耘,接入相对简单,且有“看护功能”;BAT大厂的推送,目前集成过百度云,相对到达率不如专业的第三方推送,且大厂的应用较多在手机出厂的白名单,普通app情况不能相比。普通app一般考虑第三方推送+手机厂商推送共用来提供

友盟的优点

最终选择友盟推送的原因,参考官网 https://www.umeng.com/push

1、多平台一键下发,聚合厂商通道。目前已覆盖华为、小米、魅族,支持系统级下发通道,提高消息到达率。同时避免app自己集成多厂商sdk的繁琐
2、消息无痕撤回、个性化推送方案。
3、目前友盟官网贴出的客户较多,不乏淘宝、迅雷、头条等app,这样可最大程度借用“看护功能”。且友盟推送是免费的

友盟的缺点:

1、官方不提供开发者技术群和论坛,只能通过在线客服和电话客服沟通问题,不能与开发人员对接,导致沟通效率低
2、友盟目前与阿里合作,导致部分技术依赖淘宝。但公司内网大概率封禁淘宝,这对device_token的获取,在线状态的判断都会造成影响。
3、生产模式的发送存在限制,测试环境无任何限制。名次定义及限制具体参考https://developer.umeng.com/docs/66632/detail/68343?spm=a311a.9588098.0.0

  • 广播(broadcast)默认每天可推送10次
  • 组播(groupcast)默认每分钟可推送5次
  • 文件播(filecast)默认每小时可推送300次
  • 自定义播(customizedcast, 且file_id不为空)默认每小时可推送300次
  • 单播类消息暂无推送限制

推送类型:单播(unicast)、列播(listcast)、自定义播(customizedcast且不带file_id)统称为单播类消息Web后台不会展示此类消息详细信息,仅展示前一天的汇总数据;
广播(broadcast)、文件播(filecast)、组播(groupcast)、自定义播(customizedcast且file_id不为空)统称为任务类消息,任务类消息支持API查询、撤销操作,Web后台会展示任务类消息详细信息。

其中,列播要求不超过500个device_token,该推送类型预计是我们后端会采用的类型。自定义播通过alias也可以做一些研讨。

目前开放的组播筛选字段有,支持逻辑上的and(与), or(或), not(非)操作, 以及这些操作的组合:

  • “app_version”(应用版本)
  • “channel”(渠道)
  • “device_model”(设备型号)
  • “province”(省)
  • “tag”(用户标签)
  • “country”(国家和地区) //“country”和”province”的类型定义请参照 附录J
  • “language”(语言)
  • “launch_from”(一段时间内活跃)
  • “not_launch_from”(一段时间内不活跃)

推送相关的一些参考文档:

Android端外推送到底有多烦?
陈漠沙:如何正确理解推送服务的“送达率”
友盟推送集成小米华为魅族通道
微软设计师干货分享:3大App消息推送模式及适用场景

集成要点

1、目前友盟的推送分为3种类型:通知(通知栏消息)、应用内消息(广告业,页内弹窗等)、自定义消息(透传消息)。目前我们准备采用的是通知类型推送。
通知类型的推送消息送达率>自定义消息类型。可参考小米push的解释https://dev.mi.com/console/doc/detail?pId=1292#_1_5中章节6透传和通知类消息的区别

2、device_token失效的情况: token通常情况下不会失效,但如果是备卸载过,又重新安装,token可能会变化; 另一种是设备没有SD卡,设备id变化导致的device token变化

3、不能监控应用卸载的情况。用户卸载后,会影响消息送达率。也可参考上述小米push的解释。

4、UmengNotifyClickActivity”使用通道弹窗功能”,小米/魅族/华为的厂商通道需要实现该类的子类,可以共用一个类,该类用来指定点击弹窗后下一步的跳转动作。

5、关于别名的使用。多个设备可设置同一个别名,具体参考文档 https://developer.umeng.com/docs/66632/detail/89996

6、关于离线推送,目前只支持小米 华为 魅族,其他不支持。客服声称小米等系统通道和集成官方sdk表现没有区别。自己测试小米手机杀掉应用后,系统通道下发消息能收到,但是普通消息不能收到

剩余工作:目前仅集成了小米的厂商通道测试,未进行华为的测试。

遇到注册失败:E/com.example.push.umeng.tfzzpushdemo.MyApplication: 注册失败:--------> s:-11,s1:accs bindapp error! —— 出现频率有点高

参考官网device_token离线的FAQhttps://developer.umeng.com/docs/66632/detail/67141,猜测和网络环境有关。公司内网目前是不能访问淘宝的,根据自己的测试,第一次安装时,wifi内网出现上方的注册失败;但是切换到4g网络则立即注册成功。后续再切换到wifi内网,则利用缓存注册成功(断网启动,也会注册成功)。此时官方管理平台提供的device_token在线状态查询返回的在线状态是离线。缓存有失效时间,因测试中发现上午注册正常,下午出现错误。

该问题有一定的影响范围,第一次安装或缓存失效后存在概率注册失败,这个时候只能用后台缓存的device_token发信息。如果token没有变化,设备还是能收到信息的。

目前该问题已反馈给官方,等待官方给的确切答复。

名词解释

宿主指的是挂载长连接的App。在一台设备上,肯定会有超过一款的App集成了U-Push SDK。U-Push采用的是“多路复用技术”,不会每个App都起一个长连接,U-Push SDK只会建立一个后台的长连Service,长连通道会挂到其中的一个App上,那么挂载长连接的App就是“宿主App”。U-Push SDK有一套高级的选举算法,保证宿主的选举是公平的,比如说今天App-A被选为宿主了,那么第二天就会把App-A降级,让其它的App变成宿主,尽可能的保证宿主的选举是公平的,不会出现某一个特定的App被经常选为宿主

推荐阅读更多精彩内容