怎么使用androidpn实现android手机消息推送

由于目前的web项目中要用到android手机消息推送，尝试过很多中方式之后发现，利用androidpn的部分代码来实现这个功能是比较方便的。经过使用tsung进行简单的压力测试，证明这个框架能够满足大多数简单应用的需求。

Androidpn包含有server和client两个包，server部分可以作为服务器单独运行，也可以嵌入到web项目的servlet中，在tomcat环境中与web项目的其他部分交互。androidpn的简单用法网上已经有很多文章介绍，这里就不细说了。主要谈谈如何将androidpn和自己的web程序整合到一起。

Server部分的主要包结构如下：

其中organdroidpnserverdao，organdroidpnservermodel和organdroidpnserverservice为使用hibernate链接数据库并实现简单的用户登录认证，开发中可以用我们自己的认证模块替换。剩下的包就是推送的主体实现。

接下来逐个包来看：

1util包中的类用来加载resources中的配置文件，在配置文件中可指定监听端口和ssl证书目录等属性。

2organdroidpnserverxmpp包里面定义了一些异常类型，主要是包含有入口类XmppServer，这个类用来启动和停止server程序。

3organdroidpnserverxmppauth包里面是认证的一些类，我们自己的认证模块可以在这里与androidpn进行结合。

4organdroidpnserverxmppcodec是XMPP协议的XML文件解析包，server收到和发送的消息都要通过这个包来进行xmpp协议编码和解码。

5organdroidpnserverxmpphandler包主要是对消息的处理，我们可以针对不同的消息类型定义自己的handler，

6organdroidpnserverxmppnet包负责维护与client之间的持久连接，并实现了一些传输方式供发送xmpp消息时使用。

7organdroidpnserverxmpppresence里面只包含PresenceManager类，用来维护client的在线状态。

8organdroidpnserverxmpppush包里面的NotificationManager类包含有向client发送消息的接口。

9organdroidpnserverxmpprouter包负责将收到的信息包发送到相应的handler进行处理，是一个路由包。

10organdroidpnserverxmppsession包定义了用来表示持久链接的session，每个session包含一条连接的状态信息。

11organdroidpnserverxmppssl是对连接进行ssl认证的工具包。

server发送消息的整个流程主要是：

1 NotificationManager的push接口被调用。

2使用SessionManager在当前session集合中查找相应的client链接。

3定义自己的XMPP消息格式并组装。

4通过相应session，向client发送消息。

在这个流程中我们需要修改的是步骤3，也就是需要定义和组装自己的xmpp消息，以便于将适当的信息传到客户端并便于客户端解析。一个简单的消息组装例子如下：

private IQ createMessageIQ(String title, String message, String userId,

String json) {

Element notification = DocumentHelpercreateElement(QNameget(

"message", INQURIE_NAMESPACE));

notificationaddElement("title")setText(title);

notificationaddElement("text")setText(message);

notificationaddElement("userId")setText(userId);

notificationaddElement("json")setText(json);

IQ iq = new IQ();

iqsetType(IQTypeset);

iqsetChildElement(notification);

return iq;

}

要注意的是在创建element的时候，传入的namespace要和client解析使用的namespace相匹配。

server端接收和处理消息的流程是：

1connection收到packet，使用tscpushserverxmppcodec解码。

2router根据packet的namespace等信息，将packet路由到相应的handler。

3handler进行处理。

相应的router和handler类在androidpn中都有例子可以参考，这里就不贴代码了。开发中只要根据client发送消息的格式，定义自己的router和handler类，然后在PacketRouter中注册router，在IQRouter中注册handler即可。

Client部分的主要包结构如下：

这边包含有消息的收发，解析以及持久连接的发起，重连等功能呢，十分强大，我们开发时完全不用管底层的连接，也不用担心断线，可以专注于业务部分的开发。

同时，代码结构也很简单。去除android的Service和BroadCast类以及一些工具类和常量类不谈：

1NotificationIQ,NotificationIQProvider,NotificationPacketListener三个类负责对收到的Notification格式的消息进行解析和处理，

2XmppManager是主控制器，NotificationService通过这个类，在后台维护androidpn连接。

3PersistentConnectionListener，PhoneStateChangeListener，ReconnectionThreadjava三个类则负责监听手机的状态并进行断线重连。

我们自定义消息时需要定义3个类：在IQ中定义消息的实体，在IQProvider中将消息转化为IQ实体，在PacketListener中对实体进行处理，具体的实现可参考NotificationIQ,NotificationIQProvider,NotificationPacketListener三个类。在定义这些类之后，还需要在XmppManager中将这3个类中注册到connection中，代码如下：

//ConnectTask

connectionconnect();

Logi(LOGTAG, "XMPP connected successfully");

// packet provider

ProviderManagergetInstance()addIQProvider("message",

ConstantsNOTIFICATION_NAMESPACE,

new NotificationIQProvider());

//LoginTask

// packet filter

PacketFilter packetFilter = new PacketTypeFilter(

NotificationIQclass);

// packet listener

PacketListener packetListener = xmppManager

getNotificationPacketListener();

connectionaddPacketListener(packetListener, packetFilter);

需要注意的是，注册IQProvider时，传入的namespace需要和服务端组装消息时使用的namespace一致，才能正确的收到。

一、消息中间件相关知识

1、概述

消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。当今市面上有很多主流的消息中间件，如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发RocketMQ等。

2、消息中间件的组成

21 Broker

消息服务器，作为server提供消息核心服务

22 Producer

消息生产者，业务的发起方，负责生产消息传输给broker，

23 Consumer

消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理

24 Topic

25 Queue

26 Message

消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输

3 消息中间件模式分类

31 点对点

PTP点对点:使用queue作为通信载体

说明：

消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。

消息被消费以后，queue中不再存储，所以消息消费者不可能消费到已经被消费的消息。 Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

说明：

queue实现了负载均衡，将producer生产的消息发送到消息队列中，由多个消费者消费。但一个消息只能被一个消费者接受，当没有消费者可用时，这个消息会被保存直到有一个可用的消费者。

4 消息中间件的优势

41 系统解耦

交互系统之间没有直接的调用关系，只是通过消息传输，故系统侵入性不强，耦合度低。

42 提高系统响应时间

例如原来的一套逻辑，完成支付可能涉及先修改订单状态、计算会员积分、通知物流配送几个逻辑才能完成；通过MQ架构设计，就可将紧急重要（需要立刻响应）的业务放到该调用方法中，响应要求不高的使用消息队列，放到MQ队列中，供消费者处理。

43 为大数据处理架构提供服务

通过消息作为整合，大数据的背景下，消息队列还与实时处理架构整合，为数据处理提供性能支持。

44 Java消息服务——JMS

Java消息服务（Java Message Service，JMS）应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。

5 消息中间件应用场景

51 异步通信

有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

52 解耦

降低工程间的强依赖程度，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

53 冗余

有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。

54 扩展性

因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。

55 过载保护

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

56 可恢复性

系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

57 顺序保证

在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。

58 缓冲

在任何重要的系统中，都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。

59 数据流处理

分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择。

6 消息中间件常用协议

61 AMQP协议

AMQP即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。

优点：可靠、通用

62 MQTT协议

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。

优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统

63 STOMP协议

STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。

优点：命令模式（非topic\queue模式）

64 XMPP协议

XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。

优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大

65 其他基于TCP/IP自定义的协议

有些特殊框架（如：redis、kafka、zeroMq等）根据自身需要未严格遵循MQ规范，而是基于TCP\IP自行封装了一套协议，通过网络socket接口进行传输，实现了MQ的功能。

7 常见消息中间件MQ介绍

71 RocketMQ

阿里系下开源的一款分布式、队列模型的消息中间件，原名Metaq，30版本名称改为RocketMQ，是阿里参照kafka设计思想使用java实现的一套mq。同时将阿里系内部多款mq产品（Notify、metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构，目前主要多用于订单交易系统。

具有以下特点：

官方提供了一些不同于kafka的对比差异：

https://rocketmqapacheorg/docs/motivation/

72 RabbitMQ

使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了Broker架构，核心思想是生产者不会将消息直接发送给队列，消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)、数据持久化都有很好的支持。多用于进行企业级的ESB整合。

73 ActiveMQ

Apache下的一个子项目。使用Java完全支持JMS11和J2EE 14规范的 JMS Provider实现，少量代码就可以高效地实现高级应用场景。可插拔的传输协议支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、Net,、Python、 Php、 Ruby等。

74 Redis

使用C语言开发的一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

75 Kafka

Apache下的一个子项目，使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统，具有以下特性：

76 ZeroMQ

号称最快的消息队列系统，专门为高吞吐量/低延迟的场景开发，在金融界的应用中经常使用，偏重于实时数据通信场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，开发成本高。因此ZeroMQ具有一个独特的非中间件的模式，更像一个socket library，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序本身就是使用ZeroMQ API完成逻辑服务的角色。但是ZeroMQ仅提供非持久性的队列，如果down机，数据将会丢失。如：Twitter的Storm中使用ZeroMQ作为数据流的传输。

ZeroMQ套接字是与传输层无关的：ZeroMQ套接字对所有传输层协议定义了统一的API接口。默认支持 进程内(inproc) ，进程间(IPC) ，多播，TCP协议，在不同的协议之间切换只要简单的改变连接字符串的前缀。可以在任何时候以最小的代价从进程间的本地通信切换到分布式下的TCP通信。ZeroMQ在背后处理连接建立，断开和重连逻辑。

特性：

二、主要消息中间件的比较

socket是套接字，在你的语境下，多指传输层网络接口。

webSocket，是一个应用层协议，说的是，目前浏览器实现的一套通信协议，用来解决之前HTTP，请求响应模型不合适的场合。

XMPP，是一个应用层协议，协议基于XML结构设计。

其实websocket是socket的简约实现，与socket相比，可以节省额外的端口占用，直接使用一个公网域名访问。另外协议对报文的流量消耗做了优化。xmpp与websocket比也是比较臃肿的

xmpp是im的使用比较广泛的协议，早期的手机端推送为了省事就用的这种协议，但是后来发现这种协议比较臃肿耗流量，而且对服务器要求比较高

刚开始研究XEP-0045，感觉它应该能实现群的基本功能。

某个xmpp账号加入某个多人聊天（房间），如果房间不存在，服务器会临时创建，则此账号的岗位（affiliation）自动被为owner，便可以对房间进行配置（可以用pidgin感受一下，创建room后消息框里输入"/config"），比如设置群为永久群，设置主题（类似群名称）、设置为只允许成员加入、设置成员不能改变主题等，还可以添加删除成员（pidgin消息框中输入"/affiliate member abc@localhost"，abc@localhost登录后加入此房间，便可发言、接收发言、查询成员列表等）

<img src="https://pic4zhimgcom/90be25b77f184e762d1af4b7ede9b717_bjpg" data-rawwidth="1222" data-rawheight="1424" class="origin_image zh-lightbox-thumb" width="1222" data-original="https://pic4zhimgcom/90be25b77f184e762d1af4b7ede9b717_rjpg">

这些功能理论上都应该能用程序实现，只是难易的问题，就看所用的xmpp客户端库对XEP-0045实现的如何。

我这里服务器使用的ejabberd，账号登录是通过外部服务认证，账号状态、消息都要通过外部服务记录（要写扩展，利用ejabberd的钩子和事件，现成的相关插件有ejabberd_auth_http、mod_http_offline、mod_muc_log_http、mod_post_log），ejabberd本身只是起到一个消息枢纽的作用，所以离线消息的存储，我不打算通过ejabberd本身实现，外部服务保存消息时若发现账号离线，可通过推送通知到客户端，客户端启动后可直接从外部服务获取。

我也刚才入门不久，不一定理解得全对，提供一些线索供参考。另外，我也在考虑mqtt是不是能满足需求。

1、Openfire 采用Java开发，开源的实时协作（RTC）服务器基于XMPP（Jabber）协议。　您可以使用它轻易的构建高效率的即时通信服务器　Openfire安装和使用都非常简单，并利用Web进行管理。单台服务器可支持上万并发用户。　由于是采用开放的XMPP协议，您可以使用各种支持XMPP协议的IM客户端软件登陆服务

2、Adobe的FMS是一个多媒体应用平台，使用该平台，你可以通过网络存储录制下来的音频、视频，也可以共享数据对象，并且可以将这些音频、视频和共享数据对象传递给多个客户端，实现实时同步共享。该平台集成了通讯功能和应用程序功能，它通过Flash Player(Flash player6或更高)在客户端提供音频共享，视频共享和数据流。在这个平台上，可以实现多媒体流的点播、直播、交互等多种应用，由于Adobe公司在网络多媒体应用上的雄厚实力，以及Adobe Flash Player在网络上应用的广泛性，因此，FMS成为诸多多媒体应用的服务器端主要应用平台。

3、Red5的主要功能和Macromedia公司的FMS类似，提供基于Flash的流媒体服务的一款基于Java的开源流媒体服务器。它由Java语言编写，使用RTMP作为流媒体传输协议，这与FMS完全兼容。它具有流化FLV、MP3文件，实时录制客户端流为FLV文件，共享对象，实时视频播放、Remoting等功能。用Red5替换FMS后,客户端不用更改可正常运行。

这3个产品你可以参考一下 都是用java来开发的 目前的视频聊天功能已经比较成熟了。 希望能帮到你····

英文翻译：无法连接到XMPP服务器。检查xmpp流。主机名!

这个网络游戏无法实现连接，所以出现以上提示。你如果点击确认，它会一直检查连接，所以浪费电池是自然的。如果飞行模式下电池仍然很浪费，那可能是该游戏在后台安装了恶意程序，请超载该程序，并进行杀毒，而后重新开机试试。

如帮助到你请采纳，如有疑问请交流！