CN113098936A - 一种向移动端推送消息的方法、装置及设备 - Google Patents

Abstract

本申请实施例公开了一种向移动端推送消息的方法、装置及设备。用于解决***柜服务器推送消息的压力逐渐增大，以致难以准确将不同类型的消息推送给指定移动端的问题。接收Web端发布的预设类型的消息；根据所述预设类型的消息确定出对应的接口方式；将所述预设类型的消息以及对应的所述接口方式，推送给第三方服务器；其中所述第三方服务器包含有预先收集的不同移动端的设备标识，以便所述第三方服务器在接收到推送请求后，根据所述设备标识，将所述预设类型的消息通过对应的接口方式下发给指定的移动端。通过上述方法，解决了难以准确将不同类型的消息推送给指定移动端的问题。

Description

一种向移动端推送消息的方法、装置及设备

技术领域

本申请涉及计算机领域，尤其涉及一种向移动端推送消息的方法、装置及设备。

背景技术

随着互联网技术的迅速发展，软件产品及服务也经历了翻天覆地的变化。WEB项目与移动端并列运行项目也越来越多。主流的移动平台都已经有***级的推送产品，Android上有GCM(谷歌云消息Google Cloud Messaging)，iOS上有APNS(苹果推送通知服务ApplePush Notification service)。GCM在国内又处于不可用状态，所以国内的移动应用就采用另外一种做法，即在后台运行一个service，维持应用于服务端的TCP长连接，以达到实时消息送达的效果。

现有技术通常使用***柜服务器与大量的移动端建立连接，以便将不同类型的消息推送给指定移动端。但是随着安装移动应用的移动端的数量逐渐增多，***柜服务器推送消息的压力也逐渐增大，以致难以准确将不同类型的消息推送给指定移动端，从而对不同移动端造成干扰。

发明内容

本申请实施例提供了一种向移动端推送消息的方法、装置及设备，用于解决如下技术问题：***柜服务器推送消息的压力逐渐增大，以致难以准确将不同类型的消息推送给指定移动端。

本申请实施例采用下述技术方案：

本申请实施例提供一种向移动端推送消息的方法。接收Web端发布的预设类型的消息；根据预设类型的消息确定出对应的接口方式；将预设类型的消息以及对应的所述接口方式，推送给第三方服务器；其中第三方服务器包含有预先收集的不同移动端的设备标识，以便第三方服务器在接收到推送请求后，根据设备标识，将预设类型的消息通过对应的接口方式下发给指定的移动端。

本申请实施例通过预设类型的消息确定出相应的接口方式，能够清晰的将消息根据相应的接口推送给指定设备，保障信息推送的稳定运行。并且，本申请实施例将选定的接口方式以及消息推送给第三方服务器，通过第三方服务器将信息推送给指定移动端。能够解决因设备数量较多，以致服务器难以将消息准确推送给相应移动端的问题。进而确保推送消息的准确推送。

在本申请的一种实现方式中，根据预设类型的消息确定出对应的接口方式，具体包括：根据预设类型的消息需要下发的用户类型，确定出对应的接口类型，其中，用户类型包括单个用户、所有用户与特定用户；根据接口类型确定出与接口类型对应的参数；根据预设类型的消息需要下发的移动端的类型，对接口方式进行区分，以便接口方式与移动端的类型对应；根据接口类型、所述参数以及移动端类型，确定出接口方式。

本申请实施例根据不同类型的消息确定出不同的接口方式，能够确保服务器稳定的对消息进行推送。并且本申请实施例还根据接收消息的移动端的类型，选定不同的接口方式，能够确保推送消息正确推送至相应类型移动端设备上。进而减少对不同移动端的干扰。

在本申请的一种实现方式中，以便第三方服务器在接收到推送请求后，根据设备标识，将预设类型的消息通过对应的接口方式下发给指定的移动端之前，方法还包括：通过第三方服务器与移动端建立长连接通道，以便第三方服务器接收移动端发送的设备标识信息；其中，移动端在用户注册、登录移动应用的情况下，收集移动端信息，并将移动端信息发送给第三方服务器；通过长连接通道，使得第三方服务器根据设备标识，将与移动应用相关的消息推送至指定移动端。

本申请实施例通过第三方服务器收集不同移动端的设备信息，从而能够将接收到的不同类型的消息，根据设备标识发送至相应的移动端。以此降低将消息推送给不同移动端的错误率，减少对其它移动端的干扰。

在本申请的一种实现方式中，以便所述第三方服务器在接收到推送请求后，根据设备标识，将预设类型的消息通过对应的接口方式下发给指定的移动端之前，方法还包括：在移动端为安卓类型的情况下，对移动端内的移动应用的权限以及移动应用的包名进行设置；在移动端为IOS类型的情况下，通过移动端内的APNs将移动应用对应的移动端的设备标识发送给第三方服务器，并且IOS类型的移动端通过APNs接收推送消息，并将消息发送给移动端。

在本申请的一种实现方式中，在移动端为安卓类型的情况下，对移动端内的移动应用的权限以及移动应用的包名进行设置，具体包括：在移动端为安卓类型的情况下，在移动端内的移动应用的com.***.push.example包路径下的PushDemoActivity.java文件中，设置对应的不同厂商的API Key，以便移动应用与厂商进行绑定，并在当前工程的AndroidManifest.xml文件中，添加权限和声明信息，将YourPackageName替换为当前移动应用的包名，以便移动应用获取消息推送权限。

在本申请的一种实现方式中，通过移动端内的APNs将移动应用对应的移动端的设备标识发送给第三方服务器，并且IOS类型的移动端通过APNs接收推送消息，并将消息发送给移动端，具体包括：在移动端为IOS类型的情况下，通过IOS***中APNs，对装有移动应用的移动端颁发设备标识，并将设备标识发送至第三方服务器；IOS类型的移动端通过APNs接收第三方服务器发送的带有设备标识的消息，并将消息发送给相应的移动端。

在本申请的一种实现方式中，IOS类型的移动端通过APNs接收第三方服务器发送的带有设备标识的消息，并将消息发送给相应的移动端，具体包括：IOS类型的移动端通过APNs接收第三方服务器发送的带有设备标识的消息；通过APNs对备标识进行验证，在设备标识正确的情况下，将消息推送给设备标识对应的设备。

在本申请的一种实现方式中，以便第三方服务器在接收到推送请求后，根据设备标识，将预设类型的消息通过对应的接口方式下发给指定的移动端之后，方法还包括：在移动端连网的情况下，将因无网络连接或者建立长连接通道失败而导致无法发送、且没有过期的消息，自动推送至移动端。

本申请实施例提供一种向移动端推送消息的装置，包括：接收单元，接收Web端发布的预设类型的消息；提供接口单元，根据预设类型的消息确定出对应的接口方式；消息推送单元，将预设类型的消息以及对应的接口方式，推送给第三方服务器；其中第三方服务器包含有预先收集的不同移动端的设备标识，以便第三方服务器在接收到推送请求后，根据设备标识，将预设类型的消息通过对应的接口方式下发给指定的移动端。

本申请实施例提供一种向移动端推送消息的设备，包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够：接收Web端发布的预设类型的消息；根据预设类型的消息确定出对应的接口方式；将预设类型的消息以及对应的所述接口方式，推送给第三方服务器；其中第三方服务器包含有预先收集的不同移动端的设备标识，以便第三方服务器在接收到推送请求后，根据设备标识，将预设类型的消息通过对应的接口方式下发给指定的移动端。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：本申请实施例通过预设类型的消息确定出相应的接口方式，能够清晰的将消息根据相应的接口推送给指定设备，保障信息推送的稳定运行。并且，本申请实施例将选定的接口方式以及消息推送给第三方服务器，通过第三方服务器将信息推送给指定移动端。能够解决因设备数量较多，以致服务器难以将消息准确推送给相应移动端的问题。进而确保推送消息的准确推送。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。在附

图中：

图1为本申请实施例提供的一种向移动端推送消息的方法流程图；

图2为本申请实施例提供的一种向移动端推送消息的业务逻辑流程图；

图3为本申请实施例提供的一种向移动端推送消息装置结构图；

图4为本申请实施例提供的一种向移动端推送消息设备的结构示意图。

具体实施方式

本申请实施例提供一种向移动端推送消息的方法、装置及设备。

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本说明书实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

现有技术中向移动端推送消息的方法，移动端在不使用GCM的情况下就需要通过***柜服务器与设备建立一条长连接，通过长连接进行消息推送。现有技术中通过***柜服务器将不同类型的信息进行推送时，因移动端数量较大且移动端的类型也不相同，面对大规模的消息下发，***柜服务器的压力较大，从而难以将消息推送给指定设备，容易造成对不同移动端的干扰。

为了解决上述问题，本申请实施例提供一种向移动端推送消息的方法、装置及设备。根据接收到的Web端发布的预设类型的消息，确定出对应的接口方式，从而能够使消息通过对应的接口传递给指定的移动端，使得推送过程更为清晰。其次，将对应的接口方式以及相应的推送消息推送给第三方服务器，通过第三方服务器将消息推送给指定移动端。从而通过第三方服务器缓解***柜服务器的压力，进而减少推送消息的失误，确保不同类型的消息能够推送至指定移动端。

下面通过附图对本申请实施例提出的技术方案进行详细的说明。

图1为本申请实施例提供的一种向移动端推送消息的方法流程图。如图1所示，向移动端推送消息包括如下步骤：

S101、我方服务器接收Web端发布的预设类型的消息。

在本申请的一个实施例中，Web端发布不同类型的消息时，选择好对应的消息类型。消息类型选择后，编辑对应的消息内容，将消息类型和消息内容打包传递给我方服务器处理。

具体的，Web端发布的不同类型的消息，可以为单个用户消息、特定用户消息以及群体用户消息。例如，粮企云产品中对单个用户的叫号消息、对粉丝用户的特定用户消息、群体用户的群体消息等。

需要说明的是，本申请实施例中Web端发布的不同类型的消息，不仅仅限于上述单个用户消息、特定用户消息以及群体用户消息。本申请实施例可以根据实际应用对消息类型进行不同的区分。

S102、我方服务器根据所述预设类型的消息确定出对应的接口方式。

在本申请的一个实施例中，我方服务器接收到Web端发布的不同类型的消息。并根据预设类型的消息，在MessagePushManager类中确定出对应的接口方式。

在本申请的一个实施例中，根据预设类型的消息需要下发的用户类型，确定出对应的接口类型。其中，用户类型包括单个用户、所有用户与特定用户。

具体的，在向单用户推送消息的情况下，可以选择pushMsgToSingleDevice接口，在推送消息给所有用户的情况下，可以选择pushMsgToAll接口，即广播推送。在向特定用户推送消息的情况下，可以选择pushMsgToTag接口，即特定组播。

在本申请的一个实施例中，根据所述接口类型确定出与所述接口类型对应的参数。

具体的，不同推送接口的参数不同。其中，PushMsgToSingleDeviceRequest为单用户推送消息的参数对象类，PushMsgToAllRequest为所有用户推送消息的参数对象类，PushMsgToTagRequest为特定用户推送消息的参数对象类。

在本申请的一个实施例中，根据预设类型的消息需要下发的移动端的类型，对接口方式进行区分，以便接口方式与移动端的类型对应。

具体的，因为Android的推送实现依赖于普通service的连接服务。而IOS应用的推送大部分情况下都要依赖苹果生态提供的APNs(Apple Push Notification Service)服务。因此，接收推送消息的移动端可以区分为Android移动端或IOS移动端。在对Android移动端推送消息的情况下，在接口实现AndroidPushManager类的调用，即Android设备推送类。在对IOS移动端推动消息的情况下，在接口实现IOSPushManager类调用，即IOS设备推送类。

在本申请的一个实施例中，根据接口类型、参数以及移动端类型，确定出接口方式。

S103、将预设类型的消息以及对应的所述接口方式，推送给第三方服务器。其中第三方服务器包含有预先收集的不同移动端的设备标识，以便第三方服务器在接收到推送请求后，根据设备标识，将预设类型的消息通过对应的接口方式下发给指定的移动端。

在本申请的一个实施例中，通过第三方服务器与移动端建立长连接通道，以便第三方服务器接收移动端发送的设备标识信息。其中，移动端在用户注册、登录移动应用的情况下，收集移动端信息，并将移动端信息发送给第三方服务器。

在本申请的一个实施例中，在移动端为Android移动端的情况下，第三方服务器与Android移动端建立长连接通道。在用户登录注册移动应用的情况下，收集到当前移动端的的设备信息，并将该移动端的设备信息发送给第三方服务器。以便第三方服务器根据设备标识，将推送消息发送给指定移动端。

在本申请的一个实施例中，在移动端为安卓类型的情况下，对移动端内的移动应用的权限以及移动应用的包名进行设置。

具体的，在移动应用的com.***.push.example包路径下的PushDemoActivity.java文件中，设置对应的不同手机厂商的API Key。以此将该移动应用与当前移动端的厂商进行绑定。并在当前工程的AndroidManifest.xml文件中，添加权限和声明信息。如需开启厂商代理，声明对应厂商的推送必需组件。配置Manifest文件之后，将YourPackageName替换成用户自己的包名。以此实现移动端对不同厂商的设备申请消息推送权限，例如，手机里的APP向手机厂商申请消息推送权限。

在本申请的一个实施例中，当设备接收到通知消息后，查看手机的通知栏，可以看到通知栏内的新通知展示。通知到达时，该通知会被用户点击，此时会回调onNotificationClicked函数，以在移动端界面查看推送消息。

在本申请的一个实施例中，在本申请的一个实施例中，在移动端为IOS移动端的情况下，第三方服务器与IOS移动端建立长连接通道。

在本申请的一个实施例中，在移动端为IOS类型的情况下，通过移动端内的APNs将移动应用对应的移动端的设备标识发送给第三方服务器，并且IOS类型的移动端通过APNs接收推送消息，并将消息发送给移动端。

具体的，在移动端为IOS类型的情况下，通过IOS***中APNs，对装有移动应用的移动端颁发设备标识，并将设备标识发送至第三方服务器。IOS类型的移动端通过APNs接收第三方服务器发送的带有设备标识的消息，并将消息发送给相应的移动端。

具体的，应用运行在iOS设备上时，设备和第三方服务器做绑定操作：作为设备标识的device-token是由APNs颁发的，App开发者或者第三方推送平台做的工作是收集这个device-token，APNs的推送是要求基于APNs颁发的device-token来推送的。

在本申请的一个实施例中，IOS类型的移动端通过APNs接收第三方服务器发送的带有设备标识的消息。通过APNs对备标识进行验证，在设备标识正确的情况下，将所消息推送给设备标识对应的设备。

在本申请的一个实施例中，正确的device-token会被APNs接受。如果是一个错误的、或者无效的device-token，比如App已经卸载了，APNs就不会接受。

在本申请的一个实施例中，我方服务器向第三方服务发送推送请求，向指定iOS设备推送消息。第三方推送平台在收到开发者的推送请求后，向APNS转发推送消息。将推送内容与范围选定之后的内容，通过第三方推送平台进行推送，第三方推送平台将信息提交给APNs，剩下的操作全部都由APNs来进行完成，整个过程第三方推送平台就不能控制了。APNS收到推送消息的命令，向iOS设备推送消息，开发者或者Web端想要推送的消息成功到达指定设备。

在本申请的一个实施例中，通过使用第三方服务器将消息推送给指定移动端的方式，成本较低，通过云和端之间建立的长连接，可以实时的推送消息到达用户端。保持与用户的沟通，大大提升用户活跃度和留存率。并且第三方服务一般为分布式部署或云服务部署，专门的服务器做长连接。此外，第三方服务器支持单个推送、群体推送、标签人群推送，不同类型信息仅推送给相关用户，可以最大程度减少对于用户的干扰。

需要说明的是，每一个设备都有一个自己的设备标识，而设备中的App又都有一个唯一的包名。所以服务器只需要找到设备标识与包名就可以定位到某个设备的某个应用，而这设备标识与包名会一起构成一个标识符，即为device_token。

在本申请的一个实施例中，在移动端连网的情况下，将因无网络连接或者建立长连接通道失败而导致无法发送、且没有过期的消息，自动推送至所述移动端。

具体的，通过第三方服务器将信息直接下发给需要的设备，第三方服务器与移动端建立一条长连接通道，并且将消息路由到相应移动端的App中。对于无网络连接或是没有成功建立长连接通道的设备，会在设备连网且推送消息没有过期的情况下自动收到由第三方推送服务提供商推送过来的消息，保证消息不会丢失。

图2为本申请实施例提供的一种向移动端推送消息的业务逻辑流程图。如图2所示，Web端将需要推送的消息推送给我方服务器，我方服务器对消息的类型进行区分，以对不同类型的推送消息选定不同的接口方式。我方服务器会将推送消息内容，以及选定的接口方式推送给第三方服务器。第三方服务器根据消息类型进行消息推送。例如，若接收到的为个体用户消息，则将消息推送给单个用户的移动端，若接收到的为用户群体消息，则将消息推送给用户群体的移动端，若接收到的为特定用户消息，则将消息推送给特定用户的移动端。以此，通过第三方服务器实现将消息推送给指定设备的目的。

图3为本申请实施例提供的一种向移动端推送消息装置结构图。装置包括：接收单元S301、提供接口单元S302、消息推送单元S303。

接收单元S301，接收Web端发布的预设类型的消息；

提供接口单元S302，根据所述预设类型的消息确定出对应的接口方式；

消息推送单元S303，将所述预设类型的消息以及对应的所述接口方式，推送给第三方服务器；其中所述第三方服务器包含有预先收集的不同移动端的设备标识，以便所述第三方服务器在接收到推送请求后，根据所述设备标识，将所述预设类型的消息通过对应的接口方式下发给指定的移动端。

图4为本申请实施例提供的一种向移动端推送消息设备的结构示意图。设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

接收Web端发布的预设类型的消息；

根据所述预设类型的消息确定出对应的接口方式；

将所述预设类型的消息以及对应的所述接口方式，推送给第三方服务器；其中所述第三方服务器包含有预先收集的不同移动端的设备标识，以便所述第三方服务器在接收到推送请求后，根据所述设备标识，将所述预设类型的消息通过对应的接口方式下发给指定的移动端。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请的实施例可以有各种更改和变化。凡在本申请实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

1.一种向移动端推送消息的方法，其特征在于，所述方法包括：

接收Web端发布的预设类型的消息；

根据所述预设类型的消息确定出对应的接口方式；

将所述预设类型的消息以及对应的所述接口方式，推送给第三方服务器；其中所述第三方服务器包含有预先收集的不同移动端的设备标识，以便所述第三方服务器在接收到推送请求后，根据所述设备标识，将所述预设类型的消息通过对应的接口方式下发给指定的移动端。

2.根据权利要求1所述的一种向移动端推送消息的方法，其特征在于，所述根据所述预设类型的消息确定出对应的接口方式，具体包括：

根据所述预设类型的消息需要下发的用户类型，确定出对应的接口类型，其中，所述用户类型包括单个用户、所有用户与特定用户；

根据所述接口类型确定出与所述接口类型对应的参数；

根据所述预设类型的消息需要下发的移动端的类型，对所述接口方式进行区分，以便所述接口方式与所述移动端的类型对应；

根据所述接口类型、所述参数以及所述移动端类型，确定出接口方式。

3.根据权利要求1所述的一种向移动端推送消息的方法，其特征在于，所述以便所述第三方服务器在接收到推送请求后，根据所述设备标识，将所述预设类型的消息通过对应的接口方式下发给指定的移动端之前，所述方法还包括：

通过所述第三方服务器与所述移动端建立长连接通道，以便所述第三方服务器接收所述移动端发送的设备标识信息；其中，所述移动端在用户注册、登录移动应用的情况下，收集所述移动端信息，并将所述移动端信息发送给所述第三方服务器；

通过所述长连接通道，使得所述第三方服务器根据所述设备标识，将与所述移动应用相关的消息推送至指定移动端。

4.根据权利要求1所述的一种向移动端推送消息的方法，其特征在于，所述以便所述第三方服务器在接收到推送请求后，根据所述设备标识，将所述预设类型的消息通过对应的接口方式下发给指定的移动端之前，所述方法还包括：

在所述移动端为安卓类型的情况下，对移动端内的移动应用的权限以及所述移动应用的包名进行设置；

在所述移动端为IOS类型的情况下，通过所述移动端内的APNs将所述移动应用对应的移动端的设备标识发送给所述第三方服务器，并且所述IOS类型的移动端通过所述APNs接收推送消息，并将消息发送给移动端。

5.根据权利要求4所述的一种向移动端推送消息的方法，其特征在于，所述在所述移动端为安卓类型的情况下，对移动端内的移动应用的权限以及所述移动应用的包名进行设置，具体包括：

在所述移动端为安卓类型的情况下，在所述移动端内的移动应用的com.***.push.example包路径下的PushDemoActivity.java文件中，设置对应的不同厂商的API Key，以便所述移动应用与所述厂商进行绑定，并在当前工程的AndroidManifest.xml文件中，添加权限和声明信息，将YourPackageName替换为当前移动应用的包名，以便所述移动应用获取消息推送权限。

6.根据权利要求4所述的一种向移动端推送消息的方法，其特征在于，所述通过所述移动端内的APNs将所述移动应用对应的移动端的设备标识发送给所述第三方服务器，并且所述IOS类型的移动端通过所述APNs接收推送消息，并将消息发送给移动端，具体包括：

在所述移动端为IOS类型的情况下，通过所述IOS***中APNs，对装有所述移动应用的移动端颁发设备标识，并将所述设备标识发送至所述第三方服务器；

所述IOS类型的移动端通过所述APNs接收所述第三方服务器发送的带有所述设备标识的消息，并将所述消息发送给相应的移动端。

7.根据权利要求6所述的一种向移动端推送消息的方法，其特征在于，所述IOS类型的移动端通过所述APNs接收所述第三方服务器发送的带有所述设备标识的消息，并将所述消息发送给相应的移动端，具体包括：

所述IOS类型的移动端通过所述APNs接收所述第三方服务器发送的带有所述设备标识的消息；通过所述APNs对所述备标识进行验证，在所述设备标识正确的情况下，将所述消息推送给所述设备标识对应的设备。

8.据权利要求1所述的一种向移动端推送消息的方法，其特征在于，所述以便所述第三方服务器在接收到推送请求后，根据所述设备标识，将所述预设类型的消息通过对应的接口方式下发给指定的移动端之后，所述方法还包括：

在所述移动端连网的情况下，将因无网络连接或者建立长连接通道失败而导致无法发送、且没有过期的消息，自动推送至所述移动端。

9.一种向移动端推送消息的装置，其特征在于，包括：

接收单元，接收Web端发布的预设类型的消息；

提供接口单元，根据所述预设类型的消息确定出对应的接口方式；

消息推送单元，将所述预设类型的消息以及对应的所述接口方式，推送给第三方服务器；其中所述第三方服务器包含有预先收集的不同移动端的设备标识，以便所述第三方服务器在接收到推送请求后，根据所述设备标识，将所述预设类型的消息通过对应的接口方式下发给指定的移动端。

10.一种向移动端推送消息的设备，其特征在于，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

接收Web端发布的预设类型的消息；

根据所述预设类型的消息确定出对应的接口方式；

将所述预设类型的消息以及对应的所述接口方式，推送给第三方服务器；其中所述第三方服务器包含有预先收集的不同移动端的设备标识，以便所述第三方服务器在接收到推送请求后，根据所述设备标识，将所述预设类型的消息通过对应的接口方式下发给指定的移动端。

Images