一种推送模块组件化的方法及客户端与流程

本申请涉及客户端开发领域，尤其涉及一种推送模块组件化的方法及客户端。

背景技术：

随着应用(application，app)版本不断的迭代，新功能的不断增加，业务也会变的越来越复杂，app业务模块的数量有可能还会继续增加，而且每个业务模块的代码也变的越来越多。这样发展下去单一工程下的app架构势必会影响开发效率，增加项目的维护成本，每个工程师都要熟悉如此之多的代码，将很难进行多人协作开发，而且安卓(android)项目在编译代码的时候电脑会非常卡，又因为单一工程下代码耦合严重，每修改一处代码后都要重新编译打包测试，导致非常耗时，最重要的是这样的代码想要做单元测试根本无从下手。

技术实现要素：

本申请实施例提供了一种推送模块组件化的方法及客户端，用于得到的推送组件可以使得客户端的架构清晰业务组件间完成接耦合，每个业务组件都可以根据bu需求完成独立app发布，开发中使开发者更加轻松，开发中加快功能开发调试的速度，业务组件整体删除添加替换变得非常轻松，减少工程中的代码资源等冗余文件。

有鉴于此，本申请实施例第一方面提供了一种推送模块组件化的方法，可以包括：

客户端创建推送模块；

所述客户端获取推送逻辑的相关代码，所述推送逻辑的相关代码包括第一应用中不同业务功能的推送逻辑对应的代码；

所述客户端将所述推送逻辑的相关代码封装在所述推送模块中，得到推送组件；

所述客户端接收服务器发送的推送消息；

所述客户端通过所述推送组件，对所述推送消息进行解析处理，显示处理后的推送消息。

可选的，在本申请的一些实施例中，

所述客户端根据所述推送逻辑的相关代码和所述推送模块，得到推送组件，包括：

所述客户端对所述推送模块进行解耦和抽离，加入所述推送逻辑的相关代码，得到所述推送组件。

可选的，在本申请的一些实施例中，所述客户端接收服务器发送的推送消息，包括：

所述客户端通过所述推送组件接收所述服务器发送的推送消息。

可选的，在本申请的一些实施例中，所述推送消息包括用户界面推送消息和静默推送消息。

可选的，在本申请的一些实施例中，所述推送消息包括远程推送消息和本地推送消息。

可选的，在本申请的一些实施例中，所述客户端创建推送模块，包括：

所述客户端响应用户的操作，生成创建指令；

所述客户端执行所述创建指令，创建所述推送模块。

可选的，在本申请的一些实施例中，所述客户端创建推送模块，包括：

所述客户端接收服务器发送的创建指令；

所述客户端执行所述创建指令，创建所述推送模块。

本申请实施例第二方面提供一种客户端，可以包括：

创建模块，用于创建推送模块；

获取模块，用于获取推送逻辑的相关代码，所述推送逻辑的相关代码包括第一应用中不同业务功能的推送逻辑对应的代码；

得到模块，用于将所述推送逻辑的相关代码封装在所述推送模块中，得到推送组件；

接收模块，用于接收服务器发送的推送消息；

显示模块，用于通过所述推送组件，显示所述推送消息。

可选的，在本申请的一些实施例中，

所述得到模块，具体用于对所述推送模块进行解耦和抽离，加入所述推送逻辑的相关代码，得到所述推送组件。

可选的，在本申请的一些实施例中，

接收模块，具体用于通过所述推送组件接收所述服务器发送的推送消息。

可选的，在本申请的一些实施例中，所述推送消息包括用户界面推送消息和静默推送消息。

可选的，在本申请的一些实施例中，所述推送消息包括远程推送消息和本地推送消息。

可选的，在本申请的一些实施例中，

所述创建模块，具体用于响应用户的操作，生成创建指令；执行所述创建指令，创建所述推送模块。

可选的，在本申请的一些实施例中，

所述创建模块，具体用于接收服务器发送的创建指令；执行所述创建指令，创建所述推送模块。

第三方面，本发明实施例提供了一种客户端，包括存储器、处理器，所述处理器用于执行存储器中存储的计算机程序时实现如前述第一方面实施例中所述的推送模块组件化的方法的步骤。

第四方面，本发明实施例提供了一种可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如前述第一方面实施例中所述的推送模块组件化的方法的步骤。

从以上技术方案可以看出，本申请实施例具有以下优点：

在本申请实施例中，客户端创建推送模块；所述客户端获取推送逻辑的相关代码，所述推送逻辑的相关代码包括第一应用中不同业务功能的推送逻辑对应的代码；所述客户端将所述推送逻辑的相关代码封装在所述推送模块中，得到推送组件；所述客户端接收服务器发送的推送消息；所述客户端通过所述推送组件，对所述推送消息进行解析处理，显示处理后的推送消息。得到的推送组件可以使得客户端的架构清晰，业务组件间完成接耦合，每个业务组件都可以根据需求完成独立app发布，开发中使开发者更加轻松，开发中加快功能开发调试的速度，业务组件整体删除添加替换变得非常轻松，减少工程中的代码资源等冗余文件。

附图说明

为了更清楚地说明本申请实施例技术方案，下面将对实施例和现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，还可以根据这些附图获得其它的附图。

图1为本申请实施例所应用的系统架构图；

图2为本申请实施例中推送模块组件化的方法的一个实施例示意图；

图3为本申请实施例中处理推送消息的方法的一个实施例示意图；

图4为本申请实施例中客户端的一个实施例示意图；

图5a为本申请实施例中客户端的一个实施例示意图；

图5b为本申请实施例中客户端的另一个实施例示意图；

图5c为本申请实施例中客户端的另一个实施例示意图；

图6为本申请实施例中客户端的另一个实施例示意图；

图7为本发明实施例提供的一种计算机可读存储介质的实施例示意图。

具体实施方式

本申请实施例提供了一种推送模块组件化的方法及客户端，用于得到的推送组件可以使得客户端的架构清晰业务组件间完成接耦合，每个业务组件都可以根据bu需求完成独立app发布，开发中使开发者更加轻松，开发中加快功能开发调试的速度，业务组件整体删除添加替换变得非常轻松，减少工程中的代码资源等冗余文件；业务降级，业务组件在促销高峰期间可以业务为单元关闭，保证核心业务组件的顺利执行。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，都应当属于本申请保护的范围。

如今移动app市场已经是百花齐放，其中有不乏有很多大型公司、巨型公司都是通过app创业发展起来的；app类型更加丰富，有电子商务、有视频、有社交、有工具等等，基本上涵盖了各行各业每个角落，为了更加具有竞争力app不仅功能上有创性，内容也更加多元化，更加饱满，所以出现了巨大的工程。这些工程代码不停添加如果没有一个好的架构所有代码将会强耦合在一起，功能直接也会有很多依赖，那么就会出现很多问题；例如：

1、修改功能困难，牵一发动全身。很多地方如果api(applicationprogramminginterface，应用程序编程接口)写的不好，封装不好，那么就会出现改一个地方需要改很多地方的调用。

2、更新迭代工作中冗余废弃代码资源过多造成删除冗余变得很复杂，并且很可能出现很多bug。

如图1所示，为本申请实施例所应用的一个系统架构图。在图1所示中，可以包括：

dypushnotificationservice：对外提供推送api接口，包含初始化，推送配置，推送接收等，并调用内部相应的模块进行处理。

getuisdk：个推的sdk，以后可以方便替换成其他第三方sdk。

dynotificationhandlercenter：dynotificationhandler的载体，包含多个实现了dypushnotificationhandlerprotocol的实例，并负责分发推送消息至各个handler。

dypushnotificationhandlerprotocol：抽象了消息处理对象的协议。

dynotificationhandler：用于处理消息具体业务逻辑的对象，解析消息后实现各自的业务逻辑。

dynotificationtagmanager：负责管理推送标签增删改的类。

可以先对本申请所涉及的术语做一个简单的说明。如下所示：

组件一般是与展示相关，视觉变更与交互优化是一个产品最容易产生的迭代，所以多数组件相关的框架核心都是view层的实现，比如vue与react的就认为自己仅仅是“view”，虽然展示与交互不断的在改变，但是底层展示的数据却不常变化，而view是表象，数据是根本，所以如何能更好的将数据展示到view也是各个组件需要考虑的，从而衍生出了单向数据绑定与双向数据绑定等概念，组件与组件之间的通信往往也是数据为桥梁。

项目各个页面中，会产生很多重复的功能，比如弹出层提示框，像这种纯粹非业务的用户界面(userinterface，ui)，便成了通常意义上的ui组件，最初的前端组件也就仅仅指的是ui组件。

组件开发中分为两种模式一种开发测试模式、一种是发布模式：

1、开发测试模式：这种模式下面组件应该是独立module模式，module是可以独立运行的，只要保证他对其他业务没有依赖就可以独立开发测试。

2、发布模式：这时候组件应该library模式被主工程依赖组合，发布运行，所有业务将组合成完整app发布运行。

下面以实施例的方式，对本申请技术方案做进一步的说明，如图2所示，为本申请实施例中推送模块组件化的方法的一个实施例示意图，可以包括：

201、客户端创建推送模块。

示例性的，客户端可以包括一般的手持电子终端，诸如智能电话、便携式终端、终端、个人数字助理(personaldigitalassistant，pda)、便携式多媒体播放器(personalmediaplayer，pmp)装置、笔记本电脑、笔记本(notepad)、无线宽带(wirelessbroadband，wibro)终端、平板电脑(personalcomputer，pc)和智能pc。

客户端创建推送模块，可以包括但不限于以下的实现方式：

(1)所述客户端响应用户的操作，生成创建指令；所述客户端执行所述创建指令，创建所述推送模块。

(2)所述客户端接收服务器发送的创建指令；所述客户端执行所述创建指令，创建所述推送模块。

1、主工程(壳工程module)：主要负责事情不塞入任何具体业务逻辑，主要用于使用组合业务组件、初始化配置和发布应用配置等操作。

2、组件(module/library)：主要实现具体业务逻辑，尽可能保证业务独立性，例如现在手淘这样一个大型的app几乎每个bu功能块都能够拿出来作为一个独立业务app。但是没有这么大型也可以按照小一些的业务逻辑来区分组件，例如：购物车组件、收银台组件、用户中心组件等，具体更具自己的项目需要来划分。

3、公共库(library)：公共使用的工具类、sdk等库，例如eventbus、xutils、rxandroid、自定义工具类等等，这些库可以做成一个公共commonsdk、也可以实现抽离很细按照需求依赖使用。

他们之间的关系则是主工程依赖组件、组件依赖公共库。

202、所述客户端获取推送逻辑的相关代码，所述推送逻辑的相关代码包括第一应用中不同业务功能的推送逻辑对应的代码。

示例性的，第一应用可以是斗鱼应用，不同业务功能的推送逻辑可以包括广告类的推送逻辑对应的代码、视频类的推送逻辑对应的代码等。

203、所述客户端将所述推送逻辑的相关代码封装在所述推送模块中，得到推送组件。

所述客户端根据所述推送逻辑的相关代码和所述推送模块，得到推送组件，可以包括：所述客户端对所述推送模块进行解耦和抽离，加入所述推送逻辑的相关代码，得到所述推送组件。

解耦和抽离是软件开发中很常见的概念，目的是接触两个类的直接依赖关系，通常是通过增加中间层或使用抽象接口的方式。举个例子，有两个类，一个类名叫a，另一个类叫b，a类里面有一个函数方法叫抓，需要传一个参数，类型是b。这样的话，a这个类必须知道b这个类的具体，也就是说a类直接依赖了b类。解耦的做法是，将抓这个方法传入的参数改为一个抽象类型，食物。这样的话，a就不需要直接依赖b类了。另一种方式是利用中间层桥接，两个类都依赖于另一个类，这样就可以把两者隔开，互相不直接依赖。

推送这边所做的解耦抽离方案是，以前收到一个推送，需要跳转直播间，那么推送组件就必须知道直播间这个对象，也就是直接依赖。经过抽离解耦后，推送模块只负责接收推送和解析，消息解析完成后，去推送中心里去询问每个消息执行者(有很多消息执行者，他们负责不同的业务，比如直播，网页等)，谁关心这个消息。这时查询到直播执行者关心这个消息，就将消息传递给这个执行者，后面跳转直播间由它去负责，推送模块本身就可以不知道有直播间这个东西存在了。

示例性的，客户端将所述推送逻辑的相关代码封装在所述推送模块中，得到推送组件，可以包括：

(1)appdelegate推送代码抽离至组件内部，解耦；

(2)个推sdk移入组件内部，配置逻辑；

(3)dyremotenotificationmanager代码抽离，解耦，重构(可以包括：分层设计搭建，本地推送逻辑抽离，远程推送逻辑抽离，远程推送逻辑抽离)；

(4)个推标签管理逻辑从个人中心移至推送组件内部(逻辑迁移，旧代码删除，个人中心，appdelegate冗余依赖项删除)；

(5)编写主工程转发代码，解决需要转发至主工程的逻辑处理(跳转逻辑转发，本地推送状态逻辑转发)；

(6)推送handler配置(handler配置文件plist编写，配置文件解析，handler注册逻辑)。

下面对上述步骤分别进行具体说明，如下所示：

1.原有推送接收逻辑直接写在appdelegate文件内部，包括推送注册，devicetoken注册，个推sdk初始化，推送代理回调方法的具体实现。

现将这些逻辑的具体实现抽离至推送组件内部，使appdelegate内部尽量简单，职责单一，耦合度降低。appdelegate现只需调用推送模块提供的各种接口即可。

2.个推sdk作为一个底层服务sdk，原来直接被appdelegate依赖，现将整个sdk移动，封装到推送组件内部，并用一个sdkmanager对其进行封装，外部调用sdkmanager对外提供的接口，sdkmanger再去调用个推sdk的接口，使外部调用者与个推sdk隔离。

后期如需更换其他厂商的推送sdk，只需修改sdkmanager的内部实现，外部不受影响，抽离的逻辑包括个推sdk的初始化，注册devicetoken，标签操作等等。

3.原有推送消息解析，消息处理逻辑全部放在一个remotenotificationmanager内部，使其臃肿不堪，耦合严重，违反了设计模式中的单一职责，现将其拆分为3个模块：1.消息接收模块((pushnotificationservice))；2.消息处理者中心(handlercenter，负责储存各种handler，供pushnotificationservice查询)；3.消息处理模块(handler，负责处理具体的消息事件)。

4.将定义的handler配置成一个plist文件，app启动时，推送组件读取并解析这个plist文件，根据配置创建出各种handler并添加至handlercenter中。

5.当接收到推送消息时，pushnotificationservice现进行消息解析，之后向handlercenter询问哪个handler想处理此消息，handlercenter遍历自己所有的handler并调用他们的接口，当handler返回结果为自己想处理这条消息时，pushnotificationservice便将这条消息传递给此handler,handler去处理这条消息具体的业务。

可选的，在得到推送组件之后，还可以进行测试，修改bug，组件打tag，解决review问题，代码合并等操作。

在组件化工程模型中的名词含义，如下所示：

集成模式：所有的业务组件被“app壳工程”依赖，组成一个完整的app；

组件模式：可以独立开发业务组件，每一个业务组件就是一个app；

app壳工程：负责管理各个业务组件，和打包apk，没有具体的业务功能；

业务组件：根据公司具体业务而独立形成一个的工程；

功能组件：提供开发app的某些基础功能，例如打印日志、树状图等；

main组件：属于业务组件，指定app启动页面、主界面；

common组件：属于功能组件，支撑业务组件的基础，提供多数业务组件需要的功能，例如提供网络请求功能。

204、所述客户端接收服务器发送的推送消息。

所述客户端接收服务器发送的推送消息，可以包括：所述客户端通过所述推送组件接收所述服务器发送的推送消息。

示例性的，所述推送消息可以包括用户界面推送消息和静默推送消息。或者，所述推送消息可以包括远程推送消息和本地推送消息。或者，所述推送消息可以包括广告类推送消息、直播间推送消息等。

205、所述客户端通过所述推送组件，对所述推送消息进行解析处理，显示处理后的推送消息。

客户端接收服务器发送的推送消息之后，可以通过推送组件对所述推送消息进行解析处理，显示处理后的推送消息。

示例性的，客户端显示该推送消息的方式包括但不限于：悬浮的方式显示处理后的推送消息，或者，抖动的方式显示处理后的推送消息，或者，渐变的方式显示处理后的推送消息，或者，放大的方式显示处理后的推送消息，或者，先放大再缩小的方式显示处理后的推送消息。

在本申请实施例中，客户端创建推送模块；所述客户端获取推送逻辑的相关代码，所述推送逻辑的相关代码包括第一应用中不同业务功能的推送逻辑对应的代码；所述客户端将所述推送逻辑的相关代码封装在所述推送模块中，得到推送组件；所述客户端接收服务器发送的推送消息；所述客户端通过所述推送组件，对所述推送消息进行解析处理，显示处理后的推送消息。得到的推送组件可以使得客户端的架构清晰，业务组件间完成接耦合，每个业务组件都可以根据需求完成独立app发布，开发中使开发者更加轻松，开发中加快功能开发调试的速度，业务组件整体删除添加替换变得非常轻松，减少工程中的代码资源等冗余文件；进一步的业务降级，业务组件在促销高峰期间可以业务为单元关闭，保证核心业务组件的顺利执行。

如图3所示，为本申请实施例中处理推送消息的方法的一个实施例示意图，可以包括：

301、客户端获取推送消息，所述推送消息包括不同业务功能的推送消息。

示例性的，所述推送消息可以包括用户界面推送消息和静默推送消息。或者，所述推送消息可以包括远程推送消息和本地推送消息。或者，所述推送消息可以包括广告类推送消息、直播间推送消息等。

302、所述客户端在推送组件中对所述推送消息进行处理，对应得到不同的处理消息，所述推送组件中封装第一应用中不同业务功能的推送逻辑对应的代码。

所述客户端对所述推送消息进行处理，对应得到不同的处理消息，可以包括：所述客户端对所述推送消息进行解析处理，对应得到不同的处理消息。

303、所述客户端通过所述推送组件显示所述不同的处理消息。

所述客户端通过推送组件显示所述不同的处理消息，包括但不限于以下几种实现方式：

(1)所述客户端通过所述推送组件，以旋转的方式显示所述不同的处理消息。或者，

(2)所述客户端通过所述推送组件，以放大的方式显示所述不同的处理消息。或者，

(3)所述客户端通过所述推送组件，以渐变的方式显示所述不用的处理消息。

在本申请实施例中，客户端获取推送消息，所述推送消息包括不同业务功能的推送消息；所述客户端在推送组件中对所述推送消息进行处理，对应得到不同的处理消息，所述推送组件中封装第一应用中不同业务功能的推送逻辑对应的代码；所述客户端通过所述推送组件显示所述不同的处理消息。客户端使用推送组件对推送消息进行处理，对应得到不同的处理消息，再通过所述推送组件显示所述不同的处理消息，节省系统资源。

可选的，在本申请的一些实施例中，所述方法还可以包括：

所述客户端获取删除指令；

所述客户端根据所述删除指令，删除第一目标推送消息，所述推送消息包括所述第一目标推送消息。

可选的，在本申请的一些实施例中，所述方法还可以包括：

所述客户端获取添加指令；

所述客户端根据所述添加指令，添加第二目标推送消息，所述推送消息包括所述第二目标推送消息。

在本申请实施例中，将个推sdk封装在推送组件内部，不对外暴露，推送组件对外提供接口访问，后续更换sdk时推送组件对外暴露接口可以尽量保持不变；将appdelegate中推送相关的逻辑封装到推送组件内部，appdelegate不再承担过多逻辑处理，只负责调用组件提供的接口；将个推标签增删改操作从个人中心组件移动到推送组件内部，设定一个模块进行专门维护；对不同业务模块对推送消息的解析，处理，抽离成不同的解析器和处理类进行处理，相互之间独立不依赖；后续如果将推送组件复用到别的app内，根据业务场景自定义解析器即可。

示例性的，在对推送组件进行测试的时候，测试的项目可以包括但不限于以下的说明：

1、对远程推送消息的测试，可以包括：

(1)跳转直播间(type＝1，9)

例如：开播提醒，横屏，竖屏，音频。

(2)跳转视频(type＝2，6)

例如：横屏，竖屏，精选集。

(3)跳转h5(type＝3，6)

例如：普通h5，生日提醒。

(4)老站内信版本(type＝4)

(5)鱼吧(type＝7，11，12)

例如：鱼吧动态(开播提醒横幅样式)，车队，星球。

(6)电台(type＝8)

(7)log(type＝10)

2、本地推送消息的测试，可以包括：

(流量分发)-跳转直播间(type＝2)-跳转h5(type＝1)-跳转视频(type＝3，6)-视频详情页-视频话题-不跳转(type＝4)-跳转首页(其他type)

3、其他推送消息的测试，可以包括：

例如：新站内信消息

4、异常情况

颜值直播间连麦中，收到远程推送跳转的，需要提示；

开播状态下收到推送，不展示；

当前在直播间，视频详情页，h5，首页时收到相应本地推送；

通过推送热启动唤醒不展示广告；

不允许推送的状态(例如在狼人杀游戏时)，不展示推送；

直播间小窗(视频，音频)，登陆弹窗存在时，先将他们销毁掉；

跳转h5时，如果当前是横屏需要转屏(直播间，视频详情，小视频)。

5、其他注意点

例如：apns推送，个推透传，前台收到推送，后台收到推送，app未启动时收到推送，打点。

如图4所示，为本申请实施例中客户端的一个实施例示意图，可以包括：

创建模块401，用于创建推送模块；

获取模块402，用于获取推送逻辑的相关代码，所述推送逻辑的相关代码包括第一应用中不同业务功能的推送逻辑对应的代码；

得到模块403，用于将所述推送逻辑的相关代码封装在所述推送模块中，得到推送组件；

接收模块404，用于接收服务器发送的推送消息；

显示模块405，用于通过所述推送组件，显示所述推送消息。

可选的，在本申请的一些实施例中，

得到模块403，具体用于对所述推送模块进行解耦和抽离，加入所述推送逻辑的相关代码，得到所述推送组件。

可选的，在本申请的一些实施例中，

接收模块404，具体用于通过所述推送组件接收所述服务器发送的推送消息。

可选的，在本申请的一些实施例中，所述推送消息包括用户界面推送消息和静默推送消息。

可选的，在本申请的一些实施例中，所述推送消息包括远程推送消息和本地推送消息。

可选的，在本申请的一些实施例中，

创建模块401，具体用于响应用户的操作，生成创建指令；执行所述创建指令，创建所述推送模块。

可选的，在本申请的一些实施例中，

创建模块401，具体用于接收服务器发送的创建指令；执行所述创建指令，创建所述推送模块。

如图5a所示，为本申请实施例中客户端的一个实施例示意图，可以包括：

获取模块501，用于获取推送消息，推送消息包括不同业务功能的推送消息；

处理模块502，用于在推送组件中对推送消息进行处理，对应得到不同的处理消息，推送组件中封装第一应用中不同业务功能的推送逻辑对应的代码；

显示模块503，用于通过推送组件显示不同的处理消息。

可选的，在本申请的一些实施例中，如图5b所示，为本申请实施例中客户端的另一个实施例示意图，客户端还可以包括：

获取模块501，还用于获取删除指令；

删除模块504，用于根据删除指令，删除第一目标推送消息，推送消息包括第一目标推送消息。

可选的，在本申请的一些实施例中，如图5c所示，为本申请实施例中客户端的另一个实施例示意图，客户端还可以包括：

获取模块501，还用于获取添加指令；

添加模块505，用于根据添加指令，添加第二目标推送消息，推送消息包括第二目标推送消息。

可选的，在本申请的一些实施例中，

处理模块502，具体用于对推送消息进行解析处理，对应得到不同的处理消息。

可选的，在本申请的一些实施例中，

显示模块503，具体用于对推送消息进行解析处理，对应得到不同的处理消息。

可选的，在本申请的一些实施例中，

显示模块503，具体用于通过推送组件，以放大的方式显示不同的处理消息。

可选的，在本申请的一些实施例中，

显示模块503，具体用于通过推送组件，以渐变的方式显示不用的处理消息。

如图6所示，为本申请实施例中客户端的另一个实施例示意图，可以包括：

包括存储器610、处理器620及存储在存储器620上并可在处理器620上运行的计算机程序611。

在一种实现方式中，处理器620执行计算机程序611时可以实现以下步骤：

创建推送模块；

获取推送逻辑的相关代码，所述推送逻辑的相关代码包括第一应用中不同功能的推送逻辑对应的代码；

将所述推送逻辑的相关代码封装在所述推送模块中，得到推送组件；

接收服务器发送的推送消息；

通过所述推送组件，对所述推送消息进行解析处理，显示处理后的推送消息。

可选的，在本申请的一些实施例中，处理器620执行计算机程序611时还可以实现以下步骤：

对所述推送模块进行解耦和抽离，加入所述推送逻辑的相关代码，得到所述推送组件。

可选的，在本申请的一些实施例中，处理器620执行计算机程序611时还可以实现以下步骤：

通过所述推送组件接收所述服务器发送的推送消息。

可选的，在本申请的一些实施例中，所述推送消息包括用户界面推送消息和静默推送消息。

可选的，在本申请的一些实施例中，所述推送消息包括远程推送消息和本地推送消息。

可选的，在本申请的一些实施例中，处理器620执行计算机程序611时还可以实现以下步骤：

响应用户的操作，生成创建指令；

执行所述创建指令，创建所述推送模块。

可选的，在本申请的一些实施例中，处理器620执行计算机程序611时还可以实现以下步骤：

接收服务器发送的创建指令；

执行所述创建指令，创建所述推送模块。

在另一种实现方式中，处理器620执行计算机程序611时可以实现以下步骤：

获取推送消息，所述推送消息包括不同业务功能的推送消息；

在推送组件中对所述推送消息进行处理，对应得到不同的处理消息，所述推送组件中封装第一应用中不同业务功能的推送逻辑对应的代码；

通过所述推送组件显示所述不同的处理消息。

可选的，在本申请的一些实施例中，处理器620执行计算机程序611时还可以实现以下步骤：

获取删除指令；

根据所述删除指令，删除第一目标推送消息，所述推送消息包括所述第一目标推送消息。

可选的，在本申请的一些实施例中，处理器620执行计算机程序611时还可以实现以下步骤：

获取添加指令；

根据所述添加指令，添加第二目标推送消息，所述推送消息包括所述第二目标推送消息。

可选的，在本申请的一些实施例中，处理器620执行计算机程序611时还可以实现以下步骤：

对所述推送消息进行解析处理，对应得到不同的处理消息。

可选的，在本申请的一些实施例中，处理器620执行计算机程序611时还可以实现以下步骤：

通过所述推送组件，以旋转的方式显示所述不同的处理消息。

可选的，在本申请的一些实施例中，处理器620执行计算机程序611时还可以实现以下步骤：

通过所述推送组件，以放大的方式显示所述不同的处理消息。

可选的，在本申请的一些实施例中，处理器620执行计算机程序611时还可以实现以下步骤：

通过所述推送组件，以渐变的方式显示所述不用的处理消息。

请参阅图7，图7为本发明实施例提供的一种计算机可读存储介质的实施例示意图。

如图7所示，本实施例提供了一种计算机可读存储介质，其上存储有计算机程序711。

在一种实现方式中，该计算机程序711被处理器执行时可以实现如下步骤：

创建推送模块；

获取推送逻辑的相关代码，所述推送逻辑的相关代码包括第一应用中不同功能的推送逻辑对应的代码；

将所述推送逻辑的相关代码封装在所述推送模块中，得到推送组件；

接收服务器发送的推送消息；

通过所述推送组件，对所述推送消息进行解析处理，显示处理后的推送消息。

可选的，在本申请的一些实施例中，该计算机程序711被处理器执行时还可以实现如下步骤：

对所述推送模块进行解耦和抽离，加入所述推送逻辑的相关代码，得到所述推送组件。

可选的，在本申请的一些实施例中，该计算机程序711被处理器执行时还可以实现如下步骤：

通过所述推送组件接收所述服务器发送的推送消息。

可选的，在本申请的一些实施例中，所述推送消息包括用户界面推送消息和静默推送消息。

可选的，在本申请的一些实施例中，所述推送消息包括远程推送消息和本地推送消息。

可选的，在本申请的一些实施例中，该计算机程序711被处理器执行时还可以实现如下步骤：

响应用户的操作，生成创建指令；

执行所述创建指令，创建所述推送模块。

可选的，在本申请的一些实施例中，该计算机程序711被处理器执行时还可以实现如下步骤：

接收服务器发送的创建指令；

执行所述创建指令，创建所述推送模块。

在另一种实现方式中，该计算机程序711被处理器执行时可以实现如下步骤：

获取推送消息，所述推送消息包括不同业务功能的推送消息；

在推送组件中对所述推送消息进行处理，对应得到不同的处理消息，所述推送组件中封装第一应用中不同业务功能的推送逻辑对应的代码；

通过所述推送组件显示所述不同的处理消息。

可选的，在本申请的一些实施例中，该计算机程序711被处理器执行时还可以实现如下步骤：

获取删除指令；

根据所述删除指令，删除第一目标推送消息，所述推送消息包括所述第一目标推送消息。

可选的，在本申请的一些实施例中，该计算机程序711被处理器执行时还可以实现如下步骤：

获取添加指令；

根据所述添加指令，添加第二目标推送消息，所述推送消息包括所述第二目标推送消息。

可选的，在本申请的一些实施例中，该计算机程序711被处理器执行时还可以实现如下步骤：

对所述推送消息进行解析处理，对应得到不同的处理消息。

可选的，在本申请的一些实施例中，该计算机程序711被处理器执行时还可以实现如下步骤：

通过所述推送组件，以旋转的方式显示所述不同的处理消息。

可选的，在本申请的一些实施例中，该计算机程序711被处理器执行时还可以实现如下步骤：

通过所述推送组件，以放大的方式显示所述不同的处理消息。

可选的，在本申请的一些实施例中，该计算机程序711被处理器执行时还可以实现如下步骤：

通过所述推送组件，以渐变的方式显示所述不用的处理消息。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。