Android+push+notification方案比较-CSDN博客

1

、

C2DM

的介绍及特点

在开发

Android

和

iPhone

应用程序时，我们往往需要从服务器不定的向

手机客户端即时推送各种通知消息。在

Android

手机平台上，

Google

提供

了

C2DM

（

Cloudto Device Messaging

）服务：

Android Cloud to Device Messaging (C2DM)

是一个用来帮助开发者从服

务器向

Android

应用程序发送数据的服务。该服务提供了一个简单的、

轻量级的机制，允许服务器可以通知移动应用程序直接与服务器进行

通信，以便于从服务器获取应用程序更新和用户数据。

C2DM

服务负

责处理诸如消息排队等事务并向运行于目标设备上的应用程序分发这

些消息。

但这个服务存在很大的问题：

1

）

C2DM

内置于

Android

的

2.2

系统上，无法兼容老的

1.6

到

2.1

系统

;

2

）

C2DM

需要依赖于

Google

官方提供的

C2DM

服务器，由于国内的

网络环境，这个服务经常不可用，如果想要很好的使用，我们的

App Server

必须也在国外，这个恐怕不是每个开发者都能够实现的

;

3

）

C2DM

要求用户拥有

Gmail

账号，而

Gmail

在国内并不普及

有了上述三个使用及普及上的制约，我们最终放弃了这个方案，而采

用

MQTT

协议或

XMPP

协议实现

Android

推送。

2

、

XMPP

XMPP(

可扩展通讯和表示协议

)

是基于可扩展标记语言（

XML

）的协

议，它用于即时消息（

IM

）以及在线探测。这个协议可能最终允许因特

网用户向因特网上的其他任何人发送即时消息。

Demo AndroidPN

是一个基于

XMPP

协议的

java

开源

Android push

notification

实现。它包含了完整的客户端和服务器端。环境搭建请参考

http://www.cnblogs.com/devxiaobai/archive/2011/07/09/2101794.html

。

服

务端及客户端源码于附件中。

此

Demo

有待解决问题：

A

、

若

server

端重启，

client

怎么实现有效的重连接。我在项目中

利用了

AndroidPN

，就是

server

重启，需要重启

client

，才可

以保证

push

成功。

B

、

只是完成

Android

的

Push

功能使用

XMPP

协议感觉很笨重。

XPMM

有将近

60%

的信息冗余量。

C

、

目前源码功能

Service

和

Application

没有分离，即

Application

被关闭

Service

也随之销毁。

D

、

XPMM

采用的是长连接，若客户端进入休眠状态连接将会断

开。

3

、

MQTT

是一个轻量级的消息发布

/

订阅协议，它是实现基于手机客户

端的消息推送服务器的理想解决方案。附件中

Really Small Message

Broker (RSMB)

是一个简单的

MQTT

代理，由

IBM

提供。缺省打开

1883

端口，应用程序当中，它负责接收来自服务器的消息并将其转发给指定的

移动设备。

4

、

MQTT

机制

5

、

MQTT

优缺点



使用

Last Will

和

Testament

特性通知有关各方客户端异常中

断的机制。



小型传输，开销很小（固定长度的头部是

2

字节），协议交

换最小化，以降低网络流量。



MQTT

应用的是短连接



利用

MQTT

协议，

broker

属于小型代理服务，连接数有上限

（暂不明确具体上线），到了一定程度后就无法连接了，这将

导致消息很难发送出去。

6

、

长连接和短连接的选择

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。

每个

TCP

连接都需要三步握手，这需要时间，如果每个操作都是先连接，

再操作那么处理速度会降低很多，所以每个操作完后都不断开，下次处

理时直接发送数据包就

OK

了，不用建立

TCP

连接。例如：数据库的连

接用长连接，如果用短连接频繁的通信会造成

socket

错误，而且频繁的

socket

创建也是对资源的浪费。

长连接的操作步骤是：

建立连接

——

数据传输

...

（保持连接）

...

数据传输

——

关闭连接

而如

WEB

网站的

http

服务一般都用短链接，因为长连接对于服务端

来说会耗费一定的资源，而像

WEB

网站这么频繁的成千上万甚至上亿客

户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千

上万的用户，如果每个用户都占用一个连接的话，服务器负载过重。所

以并发量大，但每个用户无需频繁操作情况下需用短连好。

短连接的操作步骤是：

建立连接

——

数据传输

——

关闭连接

...

建立连接

——

数据传输

——

关闭连接

综上所述，需根据软件需求，即推送用户量、推送消息频率

选择合适的协议。

7

、

提供协议比较的若干资源

:

1

、

http://stackoverflow.com/questions/7129821/mqtt-vs-xmpp-which-should-i-choose

2

、

http://blog.csdn.net/joshua_yu/article/details/6563587

（三协议比较）

3

、

http://ceit.uq.edu.au/content/using-xmpp-home-and-building-automation-first-post

（此资

源将

MQTT

和

XMPP

两协议融合）

PS

：

C2DM

XPMM

MTQQ

长

/

短连接

长

短

连接数

多

较多

少

开源代码量

较多

较少

大陆稳定性

不稳定

稳定

重连机制

需自己编写

提供

流量耗费

较大

较小

A​n​d​r​o​i​d​+​p​u​s​h​+​n​o​t​i​f​i​c​a​t​i​o​n​方​案​比​较

Android+push+notification方案比较