第一篇文章我们先来聊聊“Android我还可以相信你多少”，在Android系统版本的碎片化之下，在国内百家争鸣的厂家定制rom修改之下，作为一个开发者在选用系统组件的时候应该如何抉择？
每当想起这个话题的时候，总是略带一些沮丧。系统的组件都不靠谱，倒逼着开发者重复造轮子，浪费时间是其一，良莠不齐的实现和激烈的资源竞争都是导致Android平台App质量不高的原因之一。不过这倒催生了一系列优秀的开源项目，只要你想得到基本上都可以在开源平台上面搜得到。
首当其冲的应该算推送。推送作为拉回流失，提高活跃的重要手段基本上每个App都是标配。但无奈GCM依赖google服务框架，国内手机系统基本都被阉割，直接导致官方系统级推送服务扑街。于是演变出了很多变种，每个厂家自研一套，比如小米，华为都是对外公开。有的厂家是有自建推送到未普及到普通应用开发者，比如
oppo，vivo。小众一点厂家可能都还没有实现。除了厂家实现的系统级推送，也有很多第三方软件公司实现的方案，比如个推，极光。甚至还有像友盟这种的打包方案：会根据手机品牌来进行适配优先选择系统级推送，并以其他推送作为辅助来提高消息到达率。这种做法在实现推送服务的时候很常见，很多App都会接入不止一个推送SDK，所做的一切就是为了尽可能的提高消息到达率。
除了推送，定时轮询也算是另外一种解决方案，适合实时性要去不高接入推送成本又偏高的应用
事实上因为没有统一的推送平台，只靠接入一家推送服务都无法在现在的国内环境下面保证到达率。随着厂家对功耗限制的越来越严格，程序在后台存活的概率越来越小，要是利用不了系统级推送服务被杀之后基本没有机会。于是乎又衍生出了另外一种唤醒服务，也即接入某种推送平台的SDK之后，一个程序启动了就会拉起另外一个程序运行，这样即使没有系统级服务也可以继续收发消息。但道高一尺魔高一丈，厂家发现这种行为后纷纷亮出大招，比如禁止使用startService唤起一个死掉的程序，同时还在通知栏来个提醒：已禁止A程序后台启动B程序。开发者被逼上了绝路。关于唤醒还有另外一种变种，就是消息通道复用，也即A程序起来之后也可以代收同样使用这个推送平台的其他程序，这样就不存在唤醒但同时可以收发更多程序消息。这种实现系统很难禁止，唯一的缺点就是流量功耗都会算到A程序上面，或许推送开发者又要进行一轮修改了。
一个App保持了很多条长链接，App之间反复被唤醒，轮询频率过快都是导致手机变卡，耗电严重的重要原因。
推送服务选择的原则最重要的就是要选有系统级推送且市场占有率大的厂家。根据我们的经验同时接入小米和华为，在华为手机上面走华为推送，在其他手机上面走小米推送。oppo，vivo市场占有率很高，但无奈推送服务还不成熟，据小道消息还要在通知栏上面做竞价排名？小米推送比较成熟，服务器也比较稳定，接入也很简单，华为推送因为某些旧版本系统存在bug导致到达率会有一些损失。个推据说留有后门可以动态执行。在推送实现上面也可以采用几个推送平台服务端同时下发，客户端进行过滤去重的实现。可以根据自己需要来进行选择。
还要警惕的是，接入推送之后有可能存在消息延迟，这完全依赖于推送服务提供商的后台服务。消息从我们服务器发到推送平台之后进入处理队列，最后真正推到客户端的时间是不确定的，所以客户端要尽量有延迟容忍能力。话说回来，除了个别推送（比如个推），其他都是免费提供服务，你还能要求咋样？
更多推送平台的对比网上也有很多参考文章，大家可以搜索：android推送对比 进行查看，这里有篇对比文章可供参考：http://www.jianshu.com/p/d650...
更多文章请关注微信公众号：anzhuozhimei
