项目简介

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

本框架充分解耦消息推送的各个环节，将消息推送中的各部分环节抽离出来，这样可最大化地提高框架的可用性和灵活性。同时，为了方便使用，又提供了一套比较通用的默认实现方式，并对Android6.0、7.0、8.0、9.0进行了兼容性适配，最大程度上帮助大家快速实现消息推送的功能。

特征

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

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

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

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

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

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

组成结构

本框架借鉴了OnePush（目前已不维护了）中的部分思想，加之我3年消息推送的经验，形成了如下几个部分：

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

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

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

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

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

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

消息推送流程

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

第三方推送平台 --- (消息) ---> 第三方推送平台内部的接收消息的Receiver --->（重写其接收的方法）---> IPushDispatcher ---> (转发消息内容为XPushMsg/XPushCommand）---> IPushReceiver ---> (如不使用XPushManager提供的消息管理，这里直接结束）

    【使用XPushManager提供的消息管理】：---IPushReceiver---> XPushManager -----> IMessageFilterStrategy --->（对消息进行过滤处理）---> IMessageObservable ---> （消息转发到具体订阅的地方）
    

为什么要做这个项目

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

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

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

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