android应用接入第三方推送实践

本文由来和目的

由来：昨天技术群里有人问到推送，作为一个亲自踩过坑的的人，回答了一些问题，有人就说，你应该写一篇博客啊。其实在做完公司的项目集成之后，是想写的，但是因为懒就一直没写，但昨天经人这么一说，感觉还是写出来的好。
目的：本文不会告诉你具体的推送集成方案，比如选择哪家推送，怎样集成这家推送，因为随着时间的推移，这些内容都会变的，而且具体怎样集成还是应该以各家官方的文档为准，本文只会讲到集成推送整个过程中可能遇到的一些逻辑和坑，是一篇软文。本文基于20170111初稿。

推送原理

网上已经有很多篇文章去介绍推送的原理和基础了，本文就不做介绍了，在做推送业务之前，我也是对推送没有什么概念，多亏了这些文章：
谈谈消息推送服务的”送达率”
扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别

负责推送集成的开发人员

理想状态：负责推送的开发人员最好是android的组长或副组长级别，总之就是组内中高级开发人员。因为集成推送本身的技术含量并不高无益于初级开发人员的技术提升，且推送所覆盖的业务面太广，涉及：SDK集成，业务逻辑融合，前后端调试，情景测试，推送效果分析，推送数据分析，后期SDK跟进等等。开发人员将与后台技术人员，SDK技术推广人员，测试人员，运营人员，产品人员等等进行沟通，每一个人关注的点都不一样，所以可能就需要android开发人员持续深度关注推送，这对于初级开发人员来讲太占用时间。太占用时间的本质是因为随着android版本的升级，对应用的后台行为越来越限制，采用第三方推送的效果越来越差，事倍功半。
中高级开发人员的话语权相对强些，对于运营和产品提出的一些不合理需求可以拒绝。

实际开发：因为集成推送本身的技术含量并不高，且成效显著，应该大部分都会交给初级开发人员。

接入第三方推送的目的

推送的原本目的是将应用相关的资讯、优惠、消息下发到手机方便用户了解。这个过程我认为是单向的，就好像快递员把快递递给了送达人就可以了。但是可能是某个产品经理或者技术头头或者运营发现推送对于用户促活有一定帮助，提高了日活用户和月活用户，让数据上可以更漂亮，而对于创业公司而言，数据漂亮就可能会带来投资。所以采用推送来促活成了业内的普遍做法。这个过程我认为是双向的，就是快递员不仅把货物送达，还要送达人签字，最后快递员拿着满满全是签名的单子对老板说，你得给我涨工资。
所以知道自己想要什么，知道自己接入推送的目的是什么很重要，如果仅仅是想要告诉用户应用的相关资讯和优惠等等，请精挑细选出一个推送效果好的三方推送作为集成。如果想要促活，也不一定采用多个推送都集成的方式。

第三方的选择

以下排名不以“好坏”分排名
1.FCM

2.个推

3.友盟

4.极光

5.百度

6.小米

7.华为

8.魅族

9.阿里

10信鸽

11.融云

12BmobPush

13…………

结合国内Top500Android应用分析报告你可以选出你想要的推送。

各家文档、接口对开发者的友好程度

其实这一点对开发者很重要，文档写的清楚明白，我们应用开发者接入的就很顺利，调试方便，集成逻辑简单，省时省力，文档写的东一块西一块，不清不楚，我们很难正确集成，轻则费时费力，重则造成线上bug。以下排名，根据作者的实际集成体验排序，排名靠前，文档写的好，开发者只需要根据文档上的说明来集成即可，排名靠后就需要仔细推敲文档，和相关技术人员核对，以便正确集成。

1.小米推送

消息推送文档
小米推送技术常见问题解答
如何识别小米设备/MIUI系统
小米提供QQ群和在线工单形式提交问题，很方便。

2. 个推

官方文档
采用QQ讨论组形式解决开发者问题，很方便及时。

3.友盟

官方文档
【友盟+】消息推送常见问题索引（开发者必读）
采用论坛的形式解决开发者问题，比较慢，但是因为使用人数也不少，所以论坛很活跃，你可以搜索到你想要的答案。也可以QQ讨论组形式，很方便及时。有QQ大群，但是现在好像不让进了，我是申请几次都没有通过。

4.华为

HMS介绍
HMS服务介绍-PUSH服务
Push SDK-服务端常见问题
Push SDK-客户端常见问题
华为推送服务（HMS）接入文档非官方，网友自整理
常见问题-PUSH服务
华为这个要实力吐槽下：官方文档虽然都在使用HMS做push SDK，但是在推送这块，官方竟然存在着两个SDK的下载：一个是老版的Push SDK，一个是集合后的HMS SDK，要注意；点击通知栏通知的方式也有两个：intent和广播，如果你用intent，就需要把你要跳转的页面告诉后台，后台在推送数据中带过来，如果是广播，不需要后台做什么但是这个广播可能会被系统或者系统自带的手机管家拦截，具体可参见Android端外推送到底有多烦？，真的这样的逻辑好奇怪，自己的推送发出的广播自己的软件都要拦截，我前端要跳转到什么页面还需要后台来指定。因为广播会被拦截，所以推荐使用intent方式，虽然麻烦些。

效果测试

这是在集成各家推送前的一个工作，就是使用各家的DEMO去看推送效果，也是集成各家推送后的一个工作，就是真正的和自己的应用结合起来测试推送效果，同时这也是一个很难去量化的东西。但是很多开发者却以测试结果为准而选择某一家推送。我认为这是不好的。因为要达到一个完美的测试环境是很难的。首先需要了解的是哪些条件影响效果测试。
1.客户端是否正确的集成SDK，正确调用API
2.服务端是否正确的集成SDK，正确调用API
3.测试的时间段是否处于推送高峰期，而导致延迟
4.测试的SDK本身的技术问题
5.客户端或.服务端的业务逻辑
6.机型或者说ROM限制
7.网络环境：弱网导致的延迟
8.SDK官网所展示的合作案例的影响
不敢说影响因素全部都列了出来，但是仅仅是这8个中的一个出现问题，就足可以让你选择了一个错误的SDK或者让你的老板、PM、运营说你的推送不行。所以，网上有些评测推送的文章本人并不认同。在这件事情上口碑要比测试靠谱。

推送接入策略

这里面要考虑的是一个方向的问题。直接关系到怎么写代码。

1.公司有无自己的推送服务，有：端内走自己的，端外走第三方的；无：端内端外都用第三方。

2.是否只集成一个第三方，是：认真慎重选择一个，正确集成，准确结合业务。简单高效省时间。否，呵呵，这是一个坑。

小米用小米，华为用华为，魅族用魅族，那其他的呢？为了达到更多的app能够唤醒我们的应用，有两种方案：

1.单通道方案：选中几个推送，自己在自测阶段分别对这几个推送Demo进行测试：1）看看哪些app能够拉起这些Demo，尽量挑选一些大厂、用户量大的app，如淘宝，网易新闻，高德地图这些。每一个推送圈定4到5可以拉起来的app。2）分析这些app的包名。集成推送多的话，可能会有20、30个包名。3）把这些包名交给服务器，让他们在应用启动时下发（并由他们去维护），客户端根据下发的包名本地去分析，是否有这些包名的app。4）哪个推送调起的app最多，就初始化哪个推送。

2.多通道方案：选中几个推送，全部集成，全部初始化，全部上报服务端token。服务端发推送也是多个推送全部发送，客户端在接收时会接收到多个，那么客户端就需要判断消息的唯一性，先来先处理，后来不考虑。
当然可能还有其他策略，欢迎在评论区作答。

应用场景

推送token可能需要上报的时机：

1.应用进程启动时
2.点击图标进入应用时
3.切换用户时（包括未登录转登录）

测试场景：集成app的各种状态以及和其他app的互动：

1.app在前台
2.按Home键app退后台
3.按Back键app退后台
4.app进程被杀死(用户单独杀死目标app，系统内存不足时杀死目标app，手机管家等安全软件杀死目标app)
5.app进程被杀死后打开相关推送的兄弟app
6.设备重启后的开屏自启动

各个不同厂商ROM的限制测试：

1.原生android ROM 7.0以下的测试（不包括）
2.原生android ROM 7.0以上的测试（包括）
3.国际厂商定制ROM测试
4.国内厂商定制ROM测试（包括是否允许开机自启动，后台自启动，关联启动）

相关业务

1.通知栏合并
2.应用图标红点

推送前景观望：兼容

系统版本坑：我一直很“佩服”android系统版本的向后兼容性，明明硬件是支持的，系统就是不提供更新，连Google官方出的手机也仅仅支持两年，更别提国内的某些厂商了。也不能全怪手机厂商，android系统升级本身逻辑就有问题，系统升级提示的不明显不强制，不像ios，你不升级就一直弹弹窗，也不能全怪手机系统，有些用户即使你很强势、很强制的提示他升级，他就是不升，不厌其烦的把弹窗关掉，比如我。还有android平台本身的开源性，让国内手机厂商各种改源码、定制，同一个操作，各家的行为各不相同。

有了上面的系统版本坑，我们在做推送服务的时候就不能单单依赖于一家推送，像MIUI8，在应用按HOME键退后台时，系统就不让应用有任何后台网络请求。还有android平台本身的升级，在7.0上的加强Doze模式，和去除了一些隐私广播，而8.0继续加强对后台任务的限制。
可见，在android变得越来越对用户友好的同时，我们在推送这块的开发就越来越难。只要Google一天不回来，推送工作就不会轻松，当然即使他回来了，不能解决推送在系统版本上向后兼容的问题和各个厂商定制化的问题，也是白扯。
前些日子，政府牵头各个厂商，想要制造国内版的FCM，我个人很支持，但是如果没有解决我们说的问题：系统版本向后兼容、厂商ROM间兼容、android本身演进兼容，一样白扯。

附录

第三方推送

【持续更新中】Android特殊机型整理&集成注意事项
安卓设备状态离线现象剖析
Android端做消息推送有没有比较好的方案？

自建平台推送

Android实现推送方式解决方案

进程保活

Android进程保活详解：一篇文章解决你的所有疑问
AndroidDaemonService
Android后台保活实践总结：即时通讯应用无法根治的“顽疾”
即时通讯网