MobPush是MOB继一系列公共SDK之后推出的一款专注的免费SDK。可以帮助开发者更快、更方便集成实现推送功能。推送可以大幅度提升用户活跃度，有效唤醒沉睡用户。

目前MobPush可支持IOS 、Android两大平台APP集成，提供Rest API 方便开发者灵活发送推送消息，并且提供完整的可视化数据和强大管理后台。在推送形式上已经完全支持基本的通知栏消息、透传消息、本地消息的推送，并且可设置定时下发推送功能；在考虑精准推送上，MobPush支持不同程度的推送范围发送---Registration ID 、别名、标签、地理位置以及精细化的用户分群方式。

MobPush整体使用MobPush自有通道+厂商通道的方式，厂商通道包括IOS的APNs，Android的厂商通道包括华为、小米、魅族三个通道；MobPush自有通道是自定义的一套基于UDP的更为简单的二进制网络通信协议。如下图先看下整体的推送流程：

以上是MobPush整体的流程， IOS的通知栏消息全部是基于APNs首先下发的，但是如果APNs发送失败，我们会再尝试使用自有消息通道进行消息下发，然后再由客户端处理为本地通知的方式到达通知栏，这样可以保证更高的消息到达能力；Android的通知消息如果对接了厂商通道，则优先会经过厂商系统级别的通道发送，并且如果厂商通道失败，会采用离线的方式保留，待客户端下次上线之后采用MobPush通道下发；所有的透传消息都是需要经过MobPush自有通道下发的。

一个轻量级、可插拔的Android消息推送框架。一键集成推送（极光推送、友盟推送、信鸽推送、华为、小米推送等），提供有效的保活机制，支持推送的拓展，充分解耦推送和业务逻辑，解放你的双手！

在提issue前，请先阅读，并严格按照进行填写，节约大家的时间。

在使用前，请一定要仔细阅读,重要的事情说三遍！！！

在使用前，请一定要仔细阅读,重要的事情说三遍！！！

在使用前，请一定要仔细阅读,重要的事情说三遍！！！

• 集成方便。只需几行代码即可实现推送的集成，目前已经提供极光、友盟等推送渠道，除此之外还可以根据自己的需要进行扩展。

• 兼容性强。目前已完美支持Android 9.0。

• 功能强大。支持推送相关的注册、注销，标签的增加、删除、获取，别名的绑定、解绑、获取，推送的连接状态获取等操作，并能返回响应的结果；支持接收推送通知、通知的点击事件、自定义消息等推送类型。

• 统一的消息订阅。框架提供了统一的消息订阅渠道，无论你使用了何种推送方式，都可以在任何地方进行推送消息的订阅和取消订阅，方便消息的接收和处理。

• 支持增加消息过滤器。类似OkHttp中的拦截器，可以对接收的消息进行全局过滤，过滤出那些我们真正需要的推送消息。

• 提供有效的保活机制。保证接入XPush的应用消息推送的到达率和稳定性，这也是很多推送框架所做不到的。

本框架借鉴了中的部分思想，加之我3年消息推送的经验，形成了如下几个部分：

• 消息推送客户端IPushClient：主要提供消息推送平台的主要API。

• 消息推送事件转发器IPushDispatcher：主要用于将第三方的消息推送事件转发为XPush可识别的事件。

• 消息推送接收器IPushReceiver：统一接收IPushDispatcher转发过来的事件，是事件的接收中心。

• 推送消息的被观察者IMessageObservable：主要负责管理推送消息的订阅和转发。

• 推送消息的过滤策略IMessageFilterStrategy：主要负责推送消息的过滤处理和管理。

以上5个组成部分可以根据你自身的业务需求进行自定义。

在后台发出一则推送消息后：

做过Android消息推送的人都知道，Android不仅设备碎片化严重，推送平台也是五花八门的。早在2017年工信部就号召所有的厂商来制定统一的Android消息推送平台，可到现在也没有下文（究其原因还是这其中的利益太大了，谁也不想妥协）。

可是我们也不能将希望全都寄托在这个完全没有定数的事件上，代码终归要写，功能终归要上，与其受制于人，不如自己革命，搞一个自己能控制的消息推送全平台解决方案来得靠谱。

可能有人又会说，现在友盟和信鸽都支持厂商推送的集成，为何你自己还要搞一套呢？如果你对推送的及时性和到达率都没什么要求的话，其实也是无所谓的（实践证明，友盟并不好用，信鸽还可以）。在这里我需要说明的是，你不可能把自己的命运交到别人的手里，推送有别于其他的业务，相对来说比较复杂，需要处理大批量的事件消息，对服务器的要求比较大，你愿意把你的推送消息交给第三方推送平台去处理？再说了，你能强制你们后台接入指定第三方的推送平台？如果都不能，与其受制于人，何不把这些命运把握在自己的手上，那么写出来的功能自己心安啊。

之前在QQ交流群里一直有人希望我开源一个消息推送框架，其实我在上一家公司的时候就写了一个推送框架，只不过捆绑业务太深，加之避开泄密之嫌，也就没有开源的必要。此次的推送框架完全是重新写了一个，加之全新的设计，会使框架更加通用，灵活。

演示（请star支持）

3.添加第三方推送依赖（根据自己的需求进行添加，当然也可以全部添加）

1.注册消息推送接收器。方法有两种，选其中一种就行了。

注意，如果你的Android设备是8.0及以上的话，静态注册的广播是无法正常生效的，解决的方法有两种：

• 动态注册消息推送接收器

需要注意的是，这里注册的PlatformName和PlatformCode必须要和推送客户端实现类中的一一对应才行。

这里的AppKey和AppSecret需要我们到各自的推送平台上注册应用后获得。注意如果使用了xpush-xiaomi,那么需要在AndroidManifest.xml添加小米的AppKey和AppSecret（注意下面的“\ ”必须加上，否则获取到的是float而不是String，就会导致id和key获取不到正确的数据）。

初始化XPush的方式有两种，根据业务需要选择一种方式就行了：

2、推送的标签（tag）处理

• 通过调用XPush.addTags()，即可添加标签（支持传入多个）。

• 通过调用XPush.deleteTags()，即可删除标签（支持传入多个）。

• 通过调用XPush.getTags()，即可获取当前设备所有的标签。

需要注意的是，友盟推送和信鸽推送目前暂不支持标签的获取，华为推送不支持标签的所有操作，小米推送每次只支持一个标签的操作。

3、推送的别名（alias）处理

• 通过调用XPush.getAlias()，即可获取当前设备所绑定的别名。

需要注意的是，友盟推送和信鸽推送目前暂不支持别名的获取，华为推送不支持别名的所有操作。

这里需要注意的是，消息订阅的回调并不一定是在主线程，因此在回调中如果进行了UI的操作，一定要确保切换至主线程。下面演示代码中使用了我的另一个开源库,只通过@MainThread注解就能自动切换至主线程,可供参考。

5、推送消息的过滤处理

• 通过调用XPushManager.get().addFilter()方法，可增加对订阅推送消息的过滤处理。对于一些我们不想处理的消息，可以通过消息过滤器将它们筛选出来。

6、推送通知的点击处理

对于通知的点击事件，我们可以处理得更优雅，自定义其点击后的动作，打开我们想让用户看到的页面。

我们可以在全局消息推送的接收器IPushReceiver中的onNotificationClick回调中，增加打开指定页面的操作。

需要注意的是，这需要你在消息推送平台推送的通知使用的是自定义动作或者打开指定页面类型，并且传入的Intent uri 内容满足如下格式:

• title：通知的标题

• extraMsg：通知附带的拓展字段，可存放json或其他内容

• keyValue：通知附带的键值对

当然你也可以自定义传入的Intent uri 格式，具体可参考项目中的和

除此之外，如果你使用MQTT协议来做消息推送的话，我也同样提供了案例给你：

极光推送平台所有特性都支持。

• 友盟推送在进行XPush初始化的时候，除了在主进程中注册，还需要在channel中注册。

• 友盟推送不支持Tag和alias的获取

• 友盟推送不支持监听推送的连接状态。

• 信鸽推送不支持Tag和alias的获取

• 信鸽推送不支持监听推送的连接状态。

• 华为推送在注册之前需要安装最新的推送服务，否则将无法注册成功（库会自动弹出升级或者安装提示）

• 华为推送不支持所有Tag和alias的操作。

• 华为推送不支持接收通知到达事件。

• 小米推送一次只能操作一个Tag。

• 小米推送注销无结果反馈。

• 小米推送不支持监听推送的连接状态。

由于Android推送平台的众多，目前本项目不可能也没必要提供所有推送平台的集成库。如果你想使用的推送平台在我这没有找到对应的集成库的话，那么就需要你自己写一个了。

其实拓展一个第三方推送库也不是很难，只要遵循以下4步骤就可以完成了：

• 3.创建和重写三方消息推送的消息接收器（一般是重写Receiver）。重写三方推送的的接收透传消息和通知的方法，调用XPush的transmitXXX方法，将通知、透传消息、通知点击事件、以及其他事件，转发到XPush。

主要调用以下五个方法：

• 4.增加该推送平台对应的代码混淆配置信息。

以上即完成了推送平台的集成。剩下的就是在初始化XPush的时候对推送平台进行选择了.如果你看完了还是不会的话，你可以参考项目中的和.

这里提供的应用保活机制也是借鉴了前人终结出来的各种方案的混合处理。目前在9.0及以下版本都能有很好的保活效果（只要你不主动杀死程序），如果你的应用希望能够一直在后台运行（比如推送服务）而不被系统自动杀死的话，可以尝试一下。需要注意的是，程序保活并不代表能做到程序杀不死，除非你把你的应用做成系统应用或者加入到系统的白名单内，否则也只是提高了程序的优先级权重，减少程序被系统回收杀死的概率而已。

关于保活机制的使用可以参考

推送消息转译实体，携带消息的原始数据

推送通知，由XPushMsg转化而来

自定义（透传）消息，由XPushMsg转化而来

IPushClient执行相关命令的结果信息实体

如果觉得项目还不错，可以考虑打赏一波

你的打赏是我维护的动力，我将会列出所有打赏人员的清单在下方作为凭证，打赏前请留下打赏项目的备注！

更多资讯内容，欢迎扫描关注我的个人微信公众号:【我的Android开源之旅】

最近研究一下消息推送，有点感悟，分享一下

先了解一下国内主要的消息推送运营商，比如个推，友盟等，大家原理上都差不多，相对新手来说，建议看个推的产品文档，它的更好理解，

这个图描述的很清楚，其中可以把个推SDK和APP整合为APP当作一个端，其他两端分别为个推服务器、服务端，那么我们应该如何理解这些过程？

首先，App初始化事件中，初始化SDK,，登录个推服务器，并获取clientid，clientid是APP所在设备与个推服务器唯一联系的标识；对应的代码可以参考：；

其次，按照真实业务场景，需要对业务数据进行分析，对某个或某些客户推送消息，来提醒或告知客户有业务要执行或查看业务最新状态，比如对长时间未完成任务的客户A推送消息“提醒客户A有待完成的任务工单，请完成”，因为这些分析进程是后台服务的定时任务，所以需要我们在服务端进行消息推送，所需的参数是clientid、msg（消息内容），看到这里有同学会问：“clientid是从哪里获取的？”我们现在只知道客户A的uid，如何把uid转化为clientid？其实在数据库或分布式缓存中，存储所有客户的<uid, clientid>的映射关系，根据映射关系可以很容易得到clientid；对应的服务端代码可以参考：；

看到这里，聪明的同学就想到如何管理<uid, clientid>的映射关系？这部分我在看个推资料没有找到，我说一下我的实现方式，我的业务场景是APP是需要登录后才能正常使用，而且限定一个账号同时只能登录一台设备，那么当客户登录验证成功时，可以在登录事件中增加映射关系管理接口，接口逻辑为判断是否存在uid，如果有，则更新uid的值为最新的clientid, 如果没有，则插入uid, clientid这条记录； 这样保证在数据库或分布式缓存中<uid, clientid>的映射关系始终是最新 。