DevStore技术支持:Android推送方案

摘要:移动推送服务,就是通过建立一条手机与服务器的链路,当有消息需要发送到手机时,通过此链路发送即可。

安卓推送的实现方式包括:

方案1、使用C2DM服务(Google Cloud Messaging)

简介:Google推出的云消息服务,即第二代的G2DM。

优点:Google提供的服务、原生、简单,无需实现和部署服务端。

缺点:Android版本限制(必须大于2.2版本),该服务在国内不够稳定、需要用户绑定Google帐号,受限于Google。

方案2、使用XMPP协议(Openfire + Spark + Smack)

简介:基于XML协议的通讯协议,前身是Jabber,已由IETF国际标准化组织完成了标准化工作。

优点:协议成熟、强大、可扩展性强、主要应用于许多聊天系统中,且已有开源的Java版的开发实例androidpn。

缺点:协议较复杂、冗余(基于XML)、费流量、费电,部署硬件成本高。

方案3、使用MQTT协议

简介:轻量级的、基于代理的“发布/订阅”模式的消息传输协议。

优点:协议简洁、小巧、可扩展性强、省流量、省电,应用到企业领域,且已有C++版的服务端组件rsmb。

缺点:不够成熟、实现较复杂、服务端组件 rsmb 不开源,部署硬件成本较高。

方案4、使用第三方推送服务

简介:通过嵌入SDK使用第三方提供的推送服务,主流的有

Google 云推送服务:鉴于国内的特殊情况,大部分国产手机都砍掉了Google服务,所以这种实现方式不太现实。

百度云推送服务:这个推送方案实施起来比较简单,直接集成相关的sdk,就可以实现推送,而且服务端的sdk有PHP,Java,Python版本,也可以直接通过url推送相关消息。

极光推送:这个文档比较全,号称3分钟快速Demo,集成起来相对就简单多了。

优点:稳定,成熟,节省开发和探索时间,相对自己开发成本低,推送管理界面及统计程序完善。

缺点:有程序嵌入顾虑。

下面小编就简单的介绍下第三种方案的使用方法,希望可以帮助开发者在开发过程中少走弯路~

1、首先下载rsmb包,并解压,找到对应服务器的文件夹,小编展示的是linux_ia32,这个支持多种服务器。

2、把目录及里面的文件上传到服务器上,进入到用命令行并进入到该目录,然后自行 ./broker这样便启动了推送服务。

3、准备推送页面(通过网页进行推送测试)下载PHP端的推送代码(点击此处进行下载),解压进 入etc目录更改 config.php里的IP地址为你的服务器IP地址。

4、打开对应的url既可以看到如下的页面

Server status显示为 Online说明服务器正常启动了。

5、下面开始准备android客户端(点我点我

下载-->解压-->导入eclipse-->修改PushService里的MQTT_HOST为你的服务器的IP地址-->运行

启动推送服务,然后在上边的网页上把那一串字符输入到上边的输入框,下边输入要推送的内容。

如果出现如下错误的话~

【点击查看更多】》》

时间: 2024-10-14 06:04:09

DevStore技术支持:Android推送方案的相关文章

Android推送方案

移动推送服务,就是通过建立一条手机与服务器的链路,当有消息需要发送到手机时,通过此链路发送即可. 安卓推送的实现方式包括: 方案1.使用C2DM服务(Google Cloud Messaging) 简介:Google推出的云消息服务,即第二代的G2DM. 优点:Google提供的服务.原生.简单,无需实现和部署服务端. 缺点:Android版本限制(必须大于2.2版本),该服务在国内不够稳定.需要用户绑定Google帐号,受限于Google. 方案2.使用XMPP协议(Openfire + Sp

Android推送方案分析(MQTT/XMPP/GCM)

本文主旨在于,对目前Android平台上最主流的几种消息推送方案进行分析和对比,比较客观地反映出这些推送方案的优缺点,帮助大家选择最合适的实施方案. 方案1.使用GCM服务(Google Cloud Messaging)简介:Google推出的云消息服务,即第二代的C2DM.优点:Google提供的服务.原生.简单,无需实现和部署服务端.缺点:Android版本限制(必须大于2.2版本),该服务在国内不够稳定.需要用户绑定Google帐号,受限于Google. 方案2.使用XMPP协议(Open

[转]Android推送方案分析(MQTT/XMPP/GCM)

转自:http://m.oschina.net/blog/82059 本文主旨在于,对目前Android平台上最主流的几种消息推送方案进行分析和对比,比较客观地反映出这些推送方案的优缺点,帮助大家选择最合适的实施方案. 方案1. 使用GCM服务(Google Cloud Messaging) 简介:Google推出的云消息服务,即第二代的G2DM. 优点:Google提供的服务.原生.简单,无需实现和部署服务端. 缺点:Android版本限制(必须大于2.2版本),该服务在国内不够稳定.需要用户

Android推送技术研究

前言 近期研究Android推送的实现, 研究了两天一夜, 有了一点收获, 写下来既为了分享, 也为了吐槽. 须要说明的是有些东西偏底层硬件和通信行业, 我对这些一窍不通, 仅仅能说说自己的理解. 为什么要研究Android推送技术? 主要还是毕业设计要做一个即时通信app, 我是不喜欢做什么社交app的, 也就象牙塔里的人想得出来, 说实话有这功夫还不如钻研一个小技术点, 把一个点研究透彻, 比搞个大而全, 还没用的东西好得多, 只是谁叫咱们是普通人, 没得选呢. Android推送服务的几种

Android 基于Netty的消息推送方案之Hello World(一)

消息推送方案(轮询.长连接) 轮询 轮询:比较简单的,最容易理解和实现的就是客户端去服务器上拉信息,信息的及时性要求越高则拉信息的频率越高.客户端拉信息的触发可以是一些事件,也可以是一个定时器,不断地去查询服务器.所以这个方案的弊端也是显而易见的,在轮询的频率较高时,服务器端的压力很大,通讯的流量也很大,并且大部分时间都是做的无用功. 长连接 长连接:客户端和服务端维持一个长连接,服务端在有信息推送的时候,借助这个连接把信息发送到客户端.这个方案的优点是信息推送的及时性很高,基本是实时的,并且除

Android 基于Netty的消息推送方案(一)

消息推送方案(轮询.长连接) 轮询 轮询:比较简单的,最容易理解和实现的就是客户端去服务器上拉信息,信息的及时性要求越高则拉信息的频率越高.客户端拉信息的触发可以是一些事件,也可以是一个定时器,不断地去查询服务器.所以这个方案的弊端也是显而易见的,在轮询的频率较高时,服务器端的压力很大,通讯的流量也很大,并且大部分时间都是做的无用功. 长连接 长连接:客户端和服务端维持一个长连接,服务端在有信息推送的时候,借助这个连接把信息发送到客户端.这个方案的优点是信息推送的及时性很高,基本是实时的,并且除

Android 基于Netty的消息推送方案之概念和工作原理(二)

上一篇文章中我讲述了关于消息推送的方案以及一个基于Netty实现的一个简单的Hello World.为了更好的理解Hello World中的代码,今天我来解说一下关于Netty中一些概念和工作原理的内容,假设你认为本篇文章有些枯燥.请先去阅读<Android 基于Netty的消息推送方案之Hello World(一)> ChannelEvent Netty是基于事件驱动的,就是我们上文提到的.发生什么事.就通知"有关部门". 所以.不难理解.我们自己的业务代码中,一定有跟这

Android 基于Netty的消息推送方案之对象的传递(四)

在上一篇文章中<Android 基于Netty的消息推送方案之字符串的接收和发送(三)>我们介绍了Netty的字符串传递,我们知道了Netty的消息传递都是基于流,通过ChannelBuffer传递的,那么自然,Object也需要转换成ChannelBuffer来传递.好在Netty本身已经给我们写好了这样的转换工具.ObjectEncoder和ObjectDecoder,下面我们介绍一个案例. 1. 我们构造一个用来传输的对象(JavaBean) [java] view plaincopy

Android 基于Netty的消息推送方案之字符串的接收和发送(三)

在上一篇文章中<Android 基于Netty的消息推送方案之概念和工作原理(二)> ,我们介绍过一些关于Netty的概念和工作原理的内容,今天我们先来介绍一个叫做ChannelBuffer的东东. ChannelBuffer Netty中的消息传递,都必须以字节的形式,以ChannelBuffer为载体传递.简单的说,就是你想直接写个字符串过去,对不起,抛异常.虽然,Netty定义的writer的接口参数是Object的,这可能也是会给新上手的朋友容易造成误会的地方.Netty源码中,是这样