推送简介
目前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被经常选为宿主
