客户端消息推送实现方案_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
客户端消息推送实现方案
&&客户端消息推送实现方案
阅读已结束，下载文档到电脑
想免费下载更多文档？
定制HR最喜欢的简历
你可能喜欢上下架应用
只需一步，快速开始
最全APP推送（push）秘籍：做推送，这一篇就够了！
APP消息推送指的是APP开发者通过第三方工具将自己想要推的消息推送给用户，让用户被动的接收。
消息推送（push）是APP运营的渠道之一，运用得当可以帮助运营人员更高效地实现运营目标，相反盲目得push也将带来反作
一APP消息推送是什么？APP消息推送指的是APP开发者通过第三方工具将自己想要推的消息推送给用户，让用户被动的接收。消息推送（push）是APP运营的渠道之一，运用得当可以帮助运营人员更高效地实现运营目标，相反盲目得push也将带来反作用。如何控制好消息推送（push）的“度”是每个APP运营人员需要学习的一门课程。二APP推送有什么特点？1、量大，用户数即是可push覆盖的数量。假如一个APP有5000万的活跃用户，且都取得了用户授权，那么全量push一次即可触及到5000万的用户。2、精准，消息推送的受众是下载安装且使用过APP的用户，即是该产品的目标用户，相比之下其他渠道则需要层层过滤才能到达目标用户。3、免费，消息推送的主动权掌握在APP开发者自己手里，只要按照协议规则去push，是不需要花任何费用的。三推送的好处与不足？好处——1，提高产品活跃度。大多数运营人员身上都背着DAU这样的KPI，活跃用户数是APP生存的根本，有用户才能给产品带来价值。现在用户手机上的APP何其之多，除去强需求的应用之外，消息推送是获得用户特别关注，并打开APP激活使用的良好途径。2，带动功能模块使用率。很多产品经理都喜欢通过做加法来体现自己的价值，根据二八法则，80%的用户只会用到APP内约20%的功能点，而剩下80%的功能模块使用率需要运营人员通过一定手段去加强用户认知，引导使用。以百度地图为例，现在的百度地图已经是一个集地图查询、路线导航、O2O服务（美食、打车、酒店、团购、景点等）于一身的服务集群，但是绝大多数用户用百度地图还是只在使用地图查询。酒香也怕巷子深，用户对新功能点的主动发现欲望是很低的，而消息推送正是一个引导用户关注及使用体验的途径。3.增加用户粘度。“粘度”是衡量用户忠诚度的重要指标，消息推送在一定程度上可以成为APP内容服务的一部分，以新闻类APP为例，对重大新闻进行第一时间push推送能够极大促进用户关注，提高用户使用率、用户忠诚度。4.唤醒沉睡的用户，提高留存率。在做用户运营过程中，唤醒沉睡用户，挽留流失用户，对于提高用户留存率都是有重要意义，合适的消息推送能有效唤醒这部分沉睡的用户。不足——1，对用户形成打扰，招致卸载。错误的时间推送用户不喜欢的消息，会招致用户关闭推送甚至下载。2，用户对推送消息变得麻木。盲目地海量推送用户不感兴趣的内容，用户也会变得麻木，自然地对你的APP产生一种心理上的屏蔽。等你再推送真正有价值的内容时，用户也会视而不见。四市场上做推送的代表个推，极光，百度云，腾讯信鸽，云巴，友盟推送，小米推送等。五如何做好APP消息推送？1，细分消息推送的对象，不随意push全量首先要建立用户数据库，对用户特征、地域、偏好进行细化，这部分可以通过账号体系引导用户主动选择，也可以通过对用户行为的大数据分析建立用户模型。2.尊重用户，把主动权还给用户尊重用户第一步就是把选择的主动权还给用户，消息推送的前提是用户充分信任APP才给了授权，就像邮件订阅一样，用户有取消订阅的权利，否则就会屏蔽你的邮件来源。在上面的消息推送时用户心理反应模型中，用户遇到反感的消息时，会首先想到关闭消息，甚至关闭消息推送的授权，这个时候要尊重用户的选择权，否则当用户找不到关闭的入口，就只能将APP卸载掉，直接导致用户流失。3.从用户接受信息的场景反推消息推送的时间现在的APP推送机制都由服务端进行控制，在推送时间上需要正确得把握。首先千万别在大半夜push消息。除非是预报地震，影响用户休息等对用户形成打扰都是不友好的行为。二是从用户使用场景出发，选择合适的推送时间。以天气类APP为例，通常用户会在早上出门前想知道一整天的天气情况、温度变化，因此天气类APP最好的推送时机就是早上。再举一个浏览器的例子，每到年前各大浏览器厂商都开始做抢票，必然涉及到给用户推送抢票日历，那么抢票日历的推送时间放在早上合适吗？仔细考虑一下这个使用场景，12306的放票时间从早上8点开始，等到抢票当天才提示用户需要抢票，会不会给用户一种突然措手不及的感觉？用户需要提前准备抢票设备（手机APP、网速较快的电脑、可信赖的浏览器等），所以选择在前一天晚上推送是不是更为合适？4.推送用户感兴趣的内容永远只推送用户感兴趣，且选择与用户心理定位相符合的内容。微信的订阅模式值得被参考，为什么每天收到那么多微信消息提示但用户不会反感？因为这些都是用户主动订阅的内容，订阅就代表着感兴趣，感兴趣就会点开看，就是这样的逻辑。为什么说要选择与用户心理定位相符合的内容，如果一个音乐APP整天推送新闻，用户会觉得这是挂羊头卖狗肉，这种与产品无关的消息推送短期内会带来流量上的利益，但长期来讲破坏产品在用户心理的定位，得不偿失。5.根据使用频次决定消息推送的频率工具型APP用户可能每天只打开一次，而社交型APP用户每天会打开20次以上，这就是产品类型决定的使用频次差别。用户心理有一个平衡值，恰到好处的消息推送频率会让用户不知不觉对APP形成依赖。社交型APP可以推送得频繁些，因为用户希望第一时间收到好友发来的消息；工具型APP按照使用场景和使用频次进行推送，通常每天不可以超过一条；内容型APP则不需要按时间决定，当用户订阅的电视剧有新剧集更新，那么就第一时间给用户推送消息。一切以用户感受为中心的运营事半功倍。6.推送的信息要与落地页一致从APP开发者的角度，一切消息推送皆以用户打开APP为目的，那么用户打开时进入的是不是用户想要看到的界面？有很多APP推送的是活动信息，但点开进入的是APP首页，用户还要花精力去寻找活动页面入口在哪儿，这就是不友好的用户体验，一定程度上挫伤了用户点开消息的热情。六关于推送的误区误区一：总之推送要发给所有用户把同一个内容发给所用用户的推送方式其实并不好，当用户多次收到这样没有目标性的推送之后就会逐渐厌烦。《糖果粉碎传奇》中用户可以设置“在下次启动游戏前不接受推送”，这样的设计就让用户在被推送的时候同样拥有选择权。误区二：总之先用推送喊一下用户社交类游戏中经常可以看到“快来帮帮我！”、“牧场出问题了！”这样的推送，这种单纯为了唤回用户而发送的推送也无效并且容易让用户产生厌倦的。比较聪明的做法是推送对用户有利的信息和情报，比如限定活动。误区三：不分时间的推送这方面比较好理解，首先一定要避开用户睡眠的时间。这方面做的比较好的有《NHK红白》这款APP，它会在表演者登场前几分钟对用户进行消息推送。此外，个别情况下会产生推送延迟的问题，这方面运营商们最好事先做好相关测试。误区四：推送和跳转页毫无关联系统推送内容和点击后打开的页面毫无关联也是非常不明智的。最常见的就是点击推送信息后用户看到的是APP的入口界面，而推送内容可能还在系统公告里。误区五：推送的表现一成不变喜新厌旧是消费者常见的心态之一，这对于手机用户来说同样如此。很多运营商甚至不知道推送的系统提示音其实是可以改变的，而Android系统还支持定制提示音。七关于推送的真相真相一：用户厌烦的并不是推送功能本身针对如何看待推送功能这一问题，对1万名用户进行了问卷调查，结果表明80%的用户表示不会拒绝推送功能。各个年龄段方面没有太大的差别，但女性用户更容易受个人兴趣和心情影响。真相二：推送同样会带来用户卸载风险23%的用户有因为系统推送而卸载APP的经历。这也就是说，推送功能同样会成为用户卸载的一个契机。调查结果显示越年轻的用户对推送的抵抗倾向越小，而40岁左右的女性对推送最为包容。原因是这一年龄层的女性多为主妇，比起其他类型的人群她们更需要各种不同渠道的信息和情报。真相三：35%～50%的用户允许系统发送推送APP初次启动的时候，有35%～50%的用户允许系统发送推送，而其中“媒体”的承认度最高、平均50%，“游戏”则比较低、平均35%，娱乐为45%、运动为48%真相四：推送功能ON的用户会经常使用该APP推送功能ON的用户经常使用该APP的倾向更为明显，而在游戏类APP中，推送功能ON的用户月平均启动次数为27次，而推送功能OFF的用户月平均启动次数万恶20次。真相五：推送使得用户留存率提升无论推送功能开启与否APP启动率都相差无几的“媒体”类APP中，仍然提高了用户留存率。6个月后“新闻”类APP中，推送功能ON的用户 留存率为50%，推送功能OFF的用户留存率为31%。而“游戏”类APP上，这两个数字分别为14%和9%。真相六：留存率与推送的数量没有关系很多运营商都很会很关心，究竟推送数量要发送多少才能最有效地保证用户留存率。而实际数据表明，用户留存率与推送发送的数量并没有太大关系，重要的不是发送几次，而是发送什么内容。八大神们关于推送的说法秘密(创新工场旗下)CEO张昊认建议开发者针对产品特性来做消息推送。在他看来，合理化的全局推送有两点，一是推送与用户相关的信息，譬如“你的发帖被某某评论了”;另外是推送用户感兴趣的内容。推送与用户相关的内容不仅能提升用户的使用体验，还能提升用户的使用时长。张昊还分享了推送的几点心得：1，推送频率上，两天一次比较好；2，推送时间上，中午和下午5点-7点比较合适。秘密的使用周期比大众产品晚很多，会在中午12点和晚21点做推送。这样的推送能给秘密整个活跃度和留存率带来30%的提升。今日头条研发总监梁汝波则分享了他们在个性化推送的一些实践：1，推送频率个性化，对于接受度高的用户给予更频繁的推送，同时，对于不同类别用户设置不同的推送时间;2，内容个性化，基于地域和用户兴趣来推送。梁汝波坦言，推送其实是一件众口难调的事，而好的推送就是要在满足用户需求和防止打扰用户之间取得平衡。除了依靠第三方工具，产品自身运营设计也至关重要。大姨吗COO张相卓提到，在产品设计初期要考虑到产品的短板，大姨吗作为一款女性生理周期的应用，很容易让用户一个月只使用一次，所以APP内添加了健康、养生等相关内容，贯穿女性生理周期始终，每个阶段都可以获取更多资讯方面的信息和建议，给用户更多使用这个应用的理由，有效提高用户的使用频率。另外，产品集成社交功能，社区定期组织产品试用活动等，对提升用户的活跃度也很有益处。来源：白琦老师的微信公共账号（baiqinote）
关注我们的微信公众号》》》每天都有干货与你分享！&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp鸟哥笔记&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp手游道
上一篇：下一篇：
互动吧821活动节，免费瓜分超1亿消费
数据可视化分析神器
一站式装修家居平台
真的不只是卖零食
给的再多，不如懂我
免费读好书，最清新的读书应用
漫时光的最佳伴侣
王者返利，边买边攒私房钱！
& 上海青墨网络科技有限公司 All Rights Reserved.
沪公网安备 99号
联系地址：上海市闸北区共和新路层集成第三方推送最佳实践 - CSDN博客
集成第三方推送最佳实践
集成第三方推送最佳实践
字数6571&阅读7983&&喜欢57
本文会不定期更新，推荐watch下项目。如果喜欢请star，如果觉得有纰漏请提交issue，如果你有更好的点子可以提交pull request。
本文的示例代码主要是基于作者的经验来编写的，若你有其他的技巧和方法可以参与进来一起完善这篇文章。
注意：本报告写于日，本文内容可能随着时间和技术的发展而产生错误和偏差。
本文固定连接：
一、需求背景
Android在国内没有办法利用系统级的推送服务，再加上第三方rom对于原生的各种定制（这里的定制并无褒贬之意）所以国内的开发者就需要选择一些成熟的推送平台做推送服务了。目前的推送平台种类繁多，本文将给出推送平台的具体对比和调研结果，方便后来人进行选择。因本人对于国外的推送服务没有了解，所以选择的是国内的推送平台。
调研国内推送平台的优劣给出技术方案和选型能快速集成推送服务
调研信息一览
极光推送小米推送友盟推送个推阿里推送
参与测试的机型：
MI2 (android 5.1.1)N5 (android 6.0.1)MI4 (miui 7.2.4)OPPO (colorOS 2.1)MX4 (flymeOS 4.2.2.1c)Samsung (android4.1.2)
因为测试的结果在相同的rom上表现一致，所以下文的测试结果做了简化，屏蔽了机型的细节。
我们的项目长期使用的是信鸽的服务。为什么写这篇文章，是因为信鸽完全不能满足高到达率的标准，所以对于腾讯信鸽，就不进行调研了。
我先排除的是个推，排出它并非是因为他不好，而是因为个推本身就是收费平台，其优点就是服务全，数据颗粒度细，对开发者的响应也比较及时，但因为其收费的属性让我无法将其作为选择之一。有很多朋友也说到了，个推在用户量少的情况下是免费的。只是本文挑选的是全量免费的服务，所以就暂时不列举个推了。
阿里推送采用的是阿里云的一整套服务，但因为大公司的原因，所以会强制植入one sdk，这个东西真的是全家桶级别的东西，而且联系技术的方式是通过阿里旺旺让人心累。大而全的东西一向不是我的选择，而且未来阿里推送可能会有付费的趋势，因此我对它不做考虑。
友盟是做数据的老牌厂商，但其给我的感觉总是不舒服，之前做过友盟反馈，接入和使用总觉得不够优雅。但就推送来说，它的后台界面和提供的小工具、文档都是最美观实用的。
需要注意的是友盟的sdk引入了httpClient（官方已废弃）、okio等第三方库，我是认为完全没有必要的。我认为一个独立的sdk应该尽可能的保持轻量，过多的自带库会引起很多问题。如果你要引入友盟反馈的话，那么一定要注意它带来的几千个方法数！
友盟采用了共享连接的技术方案，即多个采用友盟推送的App可以相互共用长连接，保证你的app被杀死后只要用户打开了采用友盟推送的app，你的app就可以利用兄弟app来接收推送。这个技术也被很多推送平台所采用，是一个很不错的方案，至于是否流氓？不可说。
共享长连接（将长连接挂在高德上）
测试结果：
app处于前台
返回键退出
√(有延迟)
手机重启后
√(有延迟)
√(有延迟)
打开兄弟App
（√：能收到推送，×：收不到推送，-：无意义的测试）
测试结果表明友盟对于原生的支持较好，可以做到在原生rom上不死，在flyme上面能有一定的几率复活，只是复活后有较大几率丢失之前的消息。
需要说明的是：
本次测试在flyme上在mx4和mx5上都是通过滑动来杀掉应用的，在mx5中，如果用顶部的“扫把”进行所有应用的杀死，那么友盟推送也无法到达了。
内存使用情况
sdk配置文件如下：
通过代码分析，友盟的一些服务是在独立的进程（push）中运行的，这也是用来提升service存活率的通用方法，因此在debug下断点的时候需要选对进程！
广播接收器
我们可以明确的知道，友盟推送在监听到（可能在不同的rom有监听不到的情况）开机、网络改变、应用卸载这样的广播后就会自动复活，以便再应用被杀死后仍旧可以实时接收远端的推送信息。
在测试中我发现在MIUI上即使打开了兄弟app（高德地图），我也收不到推送。后台工具告诉我长连接的service确实挂到了兄弟app上，至于为什么没办法接收到推送就不得而知了。
最后需要说下友盟的缺点，在service被杀死后有一定概率丢失消息，刚注册的设备是无法收马上到消息的，需要过一段时间才能收到测试消息，再过一段时间才能收到正式消息，总觉得不稳定。如果一条消息很久都没有收到，那么很可能会永久丢失。
再次提醒！友盟的sdk引入了4个库！带来了好几千个方法数！引入了已经被废弃的httpClient！
小米的推送有一个很大的优势就是在MIUI上会直接使用系统的长连接，只要系统不死，那么你的app就有90%以上的概率接收到推送。当你的MIUI用户达到了一定的量级，你就必须要使用小米的推送。
要吐槽的是小米的推送后台（网页端）经常出现打不开的情况，复现频率极高。
app处于前台
返回键退出
手机重启后
√(有延迟)
打开兄弟App
（√：能收到推送，×：收不到推送，-：无意义的测试）
从结果来看小米推送是符合其文档描述的，能够在原生和MIUI上有良好的表现，所以小米推送可以被列入选择列表。
原生rom上的内存信息
MIUI上的内存信息
我发现小米在MIUI上会自动采用系统的服务，也就是说不用自身建立一个service，所以理论上要更加轻量省电。
小米推送配置文件
从代码来分析，小米会监听网络切换的广播来重启service，对于MIUI层面可能会有一个特殊的方法，不启动额外service，却可以handleMessage。
对于能否通过兄弟应用来接收推送信息，我的测试结果是无法收到，不知道是不是bug。我只能说通过这样的方式来提升消息的接收率是不靠谱的。
极光早期专注于推送服务，可以说沉淀很深，现在改名为“极光”后业务面更广了。极光对开发者提问的响应可以说是做的最好的。里说到了各个功能的目的，不会像OneSDK（阿里全家桶）那样偷偷加入一些权限。文档也是走AS的风格，较为现代。不足之处就是后台比较古老，三年前就是这样丑丑的样子，发送操作有一个延迟的过程，没有友盟做的好。
极光也支持兄弟应用相互拉起的功能，从代码上看是1.8.0之后的版本开始支持的。
第三方系统收不到推送的消息的原因（摘自）
由于第三方 ROM 的管理软件需要用户手动操作
小米【MIUI】
自启动管理：需要把应用加到【自启动管理】列表，否则杀进程或重新开机后进程无法开启
通知栏设置：应用默认都是显示通知栏通知，如果关闭，则收到通知也不会提示
网络助手：可以手动禁止已安装的第三方程序访问2G/3G和WIFI的网络和设置以后新安装程序是否允许访问2G/3G和WIFI的网络
MIUI 7 神隐模式： 允许应用进行自定义配置模式，应用在后台保持联网可用，否则应用进入后台时，应用无法正常接收消息。【设置】下电量和性能中【神隐模式】
华为【Emotion】
自启动管理：需要把应用加到【自启动管理】列表，否则杀进程或重新开机后进程不会开启，只能手动开启应用
后台应用保护：需要手动把应用加到此列表，否则设备进入睡眠后会自动杀掉应用进程，只有手动开启应用才能恢复运行
通知管理：应用状态有三种：提示、允许、禁止。禁止应用则通知栏不会有任何提醒
魅族【Flyme】
自启动管理：需要把应用加到【自启动管理】列表，否则杀进程或重新开机后进程无法开启
通知栏推送：关闭应用通知则收到消息不会有任何展示
省电管理： 安全中心里设置省电模式，在【待机耗电管理】中允许应用待机时，保持允许，否则手机休眠或者应用闲置一段时间，无法正常接收消息。
VIVO【Funtouch OS】
内存一键清理：需要将应用加入【白名单】列表，否则系统自带的“一键加速”，会杀掉进程
自启动管理：需要将应用加入“i管家”中的【自启动管理】列表，否则重启手机后进程不会自启。但强制手动杀进程，即使加了这个列表中，后续进程也无法自启动。
OPPO【ColorOS】
冻结应用管理：需要将应用加入纯净后台，否则锁屏状态下无法及时收到消息
自启动管理：将应用加入【自启动管理】列表的同时，还需要到设置-应用程序-正在运行里锁定应用进程，否则杀进程或者开机后进程不会开启，只能手动开启应用
总之，它就是一个很实在的东西，对于android的权限和中国国情无能为力，它只能尽可能做到高的推送送达率。
app处于前台
返回键退出
√（有延迟）
√（有延迟）
手机重启后
√（有延迟）
打开兄弟App
（√：能收到推送，×：收不到推送，-：无意义的测试）
关于延迟：
延迟的原因是极光的服务被杀死后，是无法接收实时消息的，直到复活后才会继续工作，所以产生了消息延迟。这点在android原生和三星的rom上有明显的规律。在三星的手机上杀掉app-&关屏-&点亮屏幕后服务就会自动重启，我认为这个就是服务重启的方式之一。
极光的配置文件中详细说明了什么是用来测试的，什么是必选的，什么是可选的，而且是否将服务放入独立进程都是一个建议选项而非强制。整体的demo和文档给人的感觉是不流氓，却无奈。
我打开了极光官方提供的兄弟app，但并不能接收到我测试app的推送消息。
在原生和MIUI上小米推送有很强的优势在三星的ROM上小米和友盟难分伯仲在魅族的Flyme中友盟有一定概率复活在OPPO的ColorOs中三家均无突出表现
整体结论是国外的rom推送成功率高，国内rom推送成功率低，国内定制真的是伤不起啊。
技术方案和选型
因为app有大量的miui用户，所以小米推送是必须被引入的，因为在flyme上友盟的表现较好，所以最终采用了小米和友盟共同接入app的方案。目前的策略是在miui上启用小米推送，不启用友盟推送；非miui上启用友盟，废弃小米推送。
判断用户rom是否是miui的方法：
public static boolean isMiUi() {
return !TextUtils.isEmpty(getSystemProperty(&ro.miui.ui.version.name&));
public static String getSystemProperty(String propName) {
BufferedReader input = null;
java.lang.Process p = Runtime.getRuntime().exec(&getprop & + propName);
input = new BufferedReader(new InputStreamReader(p.getInputStream()), 1024);
line = input.readLine();
input.close();
} catch (IOException ex) {
return null;
} finally {
if (input != null) {
input.close();
} catch (IOException e) {
e.printStackTrace();
因为推送服务是采用另一个进程，所以application会被启动多次，因此必须要判断是哪个进程启动的application，这样就可以让主进程才需要的配置工作对push进程屏蔽。开发者需要做的就是判断是否是主进程，如果是那么就执行原本application中的代码。
public static boolean isInMainProcess(Context context) {
ActivityManager am = ((ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE));
List&ActivityManager.RunningAppProcessInfo& processes = am.getRunningAppProcesses();
String mainProcessName = context.getPackageName();
int myPid = Process.myPid();
for (ActivityManager.RunningAppProcessInfo info : processes) {
if (info.pid == myPid && mainProcessName.equals(info.processName)) {
return true;
return false;
千万要注意！！！！！！！！
因为推送服务的复活会启动application，即唤醒应用。所以千万不要在application启动的时候进行网络请求的操作。因为一旦开始推送，大量用户的应用会被唤醒，然后再几分钟内会产生对于少数api的大量请求。后台服务很可能会被搞挂，所以千万要小心这点。这也就是为什么我强烈不推荐application中做很多事情的原因之一。可以考虑把这些请求转移到mainActivity中进行。
集成推送服务
目前我采用的是集成多个第三方推送，然后根据机型来注册不同的推送服务。后端不控制推送的平台。因为友盟的推送必须要一个module（我也不知道为啥），所以我索性把第三方推送平台都整个成了一个module。
友盟推送和友盟反馈会有冲突，现在友盟反馈已经不再维护了，所以强烈不建议使用友盟反馈。而且友盟推送和阿里的产品有冲突，所以如果产生了冲突，要下载去UTDID的SDK。
友盟和阿里冲突解决
友盟反馈和友盟推送冲突的解决方案（我才知道友盟反馈原来偷偷集成了推送服务）：
compile('com.umeng:fb:5.4.0') {
transitive = true
exclude group: 'com.umeng', module: 'message'
module一览
libs中集成了友盟所需要的so包（引入一个友盟的推送，要引入一堆东西，还各种冲突，这些so全是友盟的），此外还有小米的一个jar包。
一般我们不会把so放在lib中，都会采用新建一个main/jniLib文件夹来放，友盟采用了另一种方法来方，因此在build.gradle中出现了这样一段代码：
友盟文档中说，要引入我的推送，你就必须引入httpClient，因此我们必须在build.gradle中引入已经被谷歌废弃的httpClient！！！！！：
compileSdkVersion 23
buildToolsVersion &23.0.3&
useLibrary 'org.apache.http.legacy'
defaultConfig {
minSdkVersion 8
targetSdkVersion 23
友盟还使用了square家的东西，所以必须要引入以下两个依赖：
Paste_Image.png
到此为止，我终于引入了友盟的sdk。小米的sdk我就不说了，上面的图中也有，一个jar包搞定。
Manifest中的权限
因为各大推送平台都有自己的权限，但是如果混合到一起，以后想删除某个平台的代码都很难删，最终也不知道整个权限是谁加入的，有什么作用。因此我把各个平台的权限做了独立，这样做虽然在编译的时候会有重复定义权限的警告，但是并不影响最终的包，这点我通过反编译已经证实了，请放心。
android:name=&android.permission.WRITE_SETTINGS& /&
android:name=&android.permission.INTERNET& /&
android:name=&android.permission.ACCESS_NETWORK_STATE& /&
android:name=&android.permission.ACCESS_WIFI_STATE& /&
android:name=&android.permission.WRITE_EXTERNAL_STORAGE& /&
android:name=&android.permission.WAKE_LOCK& /&
android:name=&android.permission.READ_PHONE_STATE& /&
android:name=&android.permission.CHANGE_NETWORK_STATE& /&
android:name=&android.permission.CHANGE_WIFI_STATE& /&
android:name=&android.permission.GET_TASKS& /&
android:name=&android.permission.RECEIVE_BOOT_COMPLETED& /&
android:name=&android.permission.BROADCAST_PACKAGE_ADDED& /&
android:name=&android.permission.BROADCAST_PACKAGE_CHANGED& /&
android:name=&android.permission.BROADCAST_PACKAGE_INSTALL& /&
android:name=&android.permission.BROADCAST_PACKAGE_REPLACED& /&
android:name=&android.permission.RESTART_PACKAGES& /&
android:name=&android.permission.GET_ACCOUNTS& /&
android:name=&android.permission.VIBRATE& /&
android:name=&android.permission.SEND_SMS& /&
android:name=&android.permission.RECEIVE_SMS& /&
android:name=&android.permission.READ_SMS& /&
android:name=&android.permission.INTERNET& /&
android:name=&android.permission.ACCESS_NETWORK_STATE& /&
android:name=&android.permission.ACCESS_WIFI_STATE& /&
android:name=&android.permission.READ_PHONE_STATE& /&
android:name=&android.permission.GET_TASKS& /&
android:name=&android.permission.VIBRATE& /&
android:name=&${applicationId}.permission.MIPUSH_RECEIVE&
android:protectionLevel=&signature&
android:name=&${applicationId}.permission.MIPUSH_RECEIVE& /&
关于Mainfest中的key
在配置文件中因为用到了key和具体项目的包名，而我希望整个push的module保持独立性，所以我最终将key用代码进行写入，而不是采用在manifest中定义data标签的方式。
编写推送管理类
因为集成了多个平台，所以东西多，东西一多就需要管理类。管理类做的事情很简单，注册服务，接收推送消息，展示通知。
public class PushManager {
private static final String TAG = &PushManager&;
public static String tokenT
public static S
@Retention(RetentionPolicy.SOURCE)
@StringDef({PushType.MI, PushType.UMENG})
public @interface PushType {
String MI = &MI&, UMENG = &UMENG&;
public static void register(Context context) {
if (Utils.isMiUi()) {
registerMiPush(context);
registerUMengPush(context);
MiMessageReceiver}发送广播
private static void registerMiPush(Context context) {
if (BuildConfig.DEBUG) {
MiPushClient.checkManifest(context);
final String APP_ID = &xxxxxxxxxxxxxx&;
final String APP_KEY = &xxxxxxxxxxxxxx&;
if (DTUtil.isInMainProcess(context)) {
MiPushClient.registerPush(context, APP_ID, APP_KEY);
LoggerInterface newLogger = new LoggerInterface() {
public void setTag(String tag) {
public void log(String content, Throwable t) {
P.e(content, t);
public void log(String content) {
P.d(content);
Logger.setLogger(context, newLogger);
if (!BuildConfig.DEBUG) {
Logger.disablePushFileLog(context);
private static void registerUMengPush(final Context context) {
PushAgent agent = PushAgent.getInstance(context);
final String appKey = AnalyticsConfig.getAppkey(context);
final String appSecret = &xxxxxxxxxxxxxx&;
agent.setAppkeyAndSecret(appKey, appSecret);
agent.setMessageChannel(AnalyticsConfig.getChannel(context));
agent.setDebugMode(BuildConfig.DEBUG);
agent.setPushCheck(BuildConfig.DEBUG);
IUmengRegisterCallback callback = new IUmengRegisterCallback() {
public void onRegistered(final String deviceToken) {
new Handler().post(new Runnable() {
public void run() {
sendDeviceToken(context, PushType.UMENG, deviceToken);
handleRegisterResult(context, PushType.UMENG, true, null);
agent.enable(callback);
String deviceToken = UmengRegistrar.getRegistrationId(context);
if (deviceToken != null) {
callback.onRegistered(deviceToken);
agent.setResourcePackageName(&com.duitang.main&);
agent.setMessageHandler(new UmengMessageHandler() {
public void dealWithCustomMessage(final Context context, final UMessage msg) {
if (FeedbackPush.getInstance(context).dealFBMessage(new FBMessage(msg.custom))) {
new Handler().post(new Runnable() {
public void run() {
PushNotificationUtil.handlePassThroughNotify(context, PushType.UMENG, msg.custom);
agent.setNotificationClickHandler(new UmengNotificationClickHandler() {
public void dealWithCustomAction(Context context, UMessage message) {
super.dealWithCustomAction(context, message);
PushNotificationUtil.MsgBean bean =
PushNotificationUtil.parsePushMsg(message.custom);
if (bean.target != null) {
Intent intent = PushNotificationUtil.getPushIntent(context, bean.target);
context.startActivity(intent);
PushManager}变成单例，存一个token的map即可。
public static void sendDeviceToken(final Context context) {
sendDeviceToken(context, PushManager.tokenType, PushManager.token);
public static void sendDeviceToken(final Context context, @PushType String type, String token) {
if (token == null) {
PushManager.tokenType =
PushManager.token =
public static void handleRegisterResult(Context context, @PushType String type,
boolean isSuccess, @Nullable String resultMsg) {
if (isSuccess) {
小米推送信息接收器：
public class MiMessageReceiver extends PushMessageReceiver {
public void onNotificationMessageClicked(Context context, MiPushMessage msg) {
PushNotificationUtil.MsgBean bean = PushNotificationUtil
.parsePushMsg(URLDecoder.decode(msg.getContent(), &UTF-8&));
if (bean.target != null) {
Intent intent = PushNotificationUtil.getPushIntent(context, bean.target);
context.startActivity(intent);
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
public void onReceiveRegisterResult(Context context, MiPushCommandMessage message) {
String command = message.getCommand();
List&String& arguments = message.getCommandArguments();
String cmdFirstArg = ((arguments != null && arguments.size() & 0) ? arguments.get(0) : null);
if (MiPushClient.COMMAND_REGISTER.equals(command)) {
PushManager.sendDeviceToken(context,PushManager.PushType.MI, cmdFirstArg);
long code = message.getResultCode();
PushManager.handleRegisterResult(context, PushManager.PushType.MI, code == ErrorCode.SUCCESS, cmdFirstArg);
public void onReceivePassThroughMessage(Context context, MiPushMessage message) {
PushNotificationUtil.handlePassThroughNotify(context, PushManager.PushType.MI,
URLDecoder.decode(message.getContent(), &UTF-8&));
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
PushNotificationUtil的代码就不贴了，不同的项目会有不同的实现形式。至此，推送的集成工作已经完毕！
在miui上，如果应用被杀死，即使用了小米推送，透传消息也是无法收到的。可以考虑采用非透传的模式进行推送，简单方便，而且自带点击统计。至于是否采用非透传，就看项目的设计和需求了。
写到这里，在回过头来看，这篇真的是所谓的“最佳实践”么？或许是，也或许不是，其中更多的是一种妥协和无奈。技术本无罪，但它终究敌不过金钱与利益，毕竟操作技术的是人，那么技术也免不了人间的烟火气。
我们仅仅是希望更多的用户能接收到我们的推送，但在实现的路上却做了很多的妥协和权衡，甚至寄希望于不死的服务。这很可悲，但也很现实。
转念一想，在妥协和容忍中不断的寻找着实现梦想的最好的方式，这不就是人生么？是啊，这就是人生。
developer_
android整合小米、个推、jpush推送 - yuanfen934的博客 - 博客频道 - CSDN.NET
&— 《CSS3实战》总结 box-flex属性
常见问题 - 极光文档
友盟推送SDK文档
&— 友盟消息推送——中国最精准的移动推送服务，支持Android、iOS推送。友盟推送帮助开发者建立于用户直接沟通的渠道。将APP的内容更新或者活动通知主动推送给终端用户，让用户第一时间获取到相关信息，有效提升用户活跃度和忠诚度。
本文已收录于以下专栏：
相关文章推荐
注意：本报告写于日，本文内容可能随着时间和技术的发展而产生错误和偏差。
本文固定连接：/tianzhijiexian/Android-Best...
一、需求背景
Android在国内没有办法利用系统级的推送服务，再加上第三方rom对于原生的各种定制（这里的定制并无褒贬之意）所以国内的开发者就需要选择一些成熟的推送平台做推送服务了。目前的推送平台...
更方便的将各个 rom 厂商自己的推送服务进行集成,并统一管理
本文固定连接：/tianzhijiexian/Android-Best-Practices
一、需求背景
Android在国内没有办法利用系统级的推送服务，再加...
本文会不定期更新，推荐watch下项目。如果喜欢请star，如果觉得有纰漏请提交issue，如果你有更好的点子可以提交pull request。
本文的示例代码主要是基于作者的经验来编写的，若你有其...
本文会不定期更新，推荐watch下项目。如果喜欢请star，如果觉得有纰漏请提交issue，如果你有更好的点子可以提交pull request。
本文的示例代码主要是基于作者的经验来编写的，若你有其...
本地和推送通知使您的应用程序能够通过显示消息并接受用户的操作，播放独特的声音或更新应用程序图标上的徽章，使用户及时了解相关内容。服务扩展功能使您的应用程序能够在显示之前解密并扩充推送通知内容。了解什么...
Android Studio集成个推第推送,边写边学系列
Android端集成极光推送的个人看法
利用第三方推送使APP被杀掉后仍能接受消息（小米篇）
他的最新文章
讲师：宋宝华
讲师：何宇健
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)