1. android 即时通信。。如何实现
Android现在即时通讯（或者消息推送）有好几个开源项目框架可以实现，可以使用XMPP来实现即时通信。
XMPP（Extensible Messageing and Presence Protocol：可扩展消息与存在协议）是目前主流的四种IM（IM：instant messaging,即时消息）协议之一，其他三种分别为：即时信息和空间协议(IMPP)、空间和即时信息协议(PRIM)、针对即时通讯和空间平衡扩充的进程开始协议SIP(SIMPLE)。
1. XMPP的前身是Jabber，一个开源形式组织产生的网络即时通信协议。XMPP目前被IETF国际标准组织完成了标准化工作。标准化的核心结果分为两部分； 核心的XML流传输协议 基于XML流传输的即时通讯扩展应用 XMPP的核心XML流传输协议的定义使得XMPP能够在一个比以往网络通信协议更规范的平台上。借助于XML易于解析和阅读的特性，使得XMPP的协议能够非常漂亮。 XMPP的即时通讯扩展应用部分是根据IETF在这之前对即时通讯的一个抽象定义的，与其他业已得到广泛使用的即时通讯协议，诸如AIM，QQ等有功能完整，完善等先进性。
2.XMPP中定义了三个角色，客户端，服务器，网关。通信能够在这三者的任意两个之间双向发生。服务器同时承担了客户端信息记录，连接管理和信息的路由功能。网关承担着与异构即时通信系统的互联互通，异构系统可以包括SMS（短信），MSN，ICQ等。基本的网络形式是单客户端通过TCP/IP连接到单服务器，然后在之上传输XML。
3.传输的是与即时通讯相关的指令。在以前这些命令要么用2进制的形式发送，要么用纯文本指令加空格加参数加换行苻的方式发送（比如MSN）。而XMPP传输的即时通讯指令的逻辑与以往相仿，只是协议的形式变成了XML格式的纯文本。这不但使得解析容易了，人也容易阅读了，方便了开发和查错。而XMPP的核心部分就是一个在网络上分片断发送XML的流协议。这个流协议是XMPP的即时通讯指令的传递基础，也是一个非常重要的可以被进一步利用的网络基础协议。
2. Android 中使用MQTT(第一篇)
MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议。它是一种发布/订阅，极其简单和轻量级的消息传递协议，专为受限设备和低带宽，高延迟或不可靠的网络而设计。它的设计思想是轻巧、开放、简单、规范，易于实现。这些特点使得它对很多场景来说都是很好的选择，特别是对于受限的环境如机器与机器的通信（M2M）以及物联网环境。相对于XMPP，MQTT更加轻量级，并且占用的宽带低。
MQTT协议有以下特点：
那么问题来了？重连连接成功后重复接收到最后一条消息
MQTT推送消息订阅端重复接收问题。
（背景）订阅端断开的时候，发布端多次推送消息。
（现象）订阅端启动时，接收到最后一条推送消息有两次；即使Qos设置为2；依然是两次。
经排查是因为
MqttMessage的Retained设置为了true;
该值很多文章上只说了是 消息保留机制，若设置为true，mqtt服务器会保留每次发布的消息；较少提到 若订阅某主题的客户端重启，则会把此主题之前发布的消息重新推送到客户端。该值默认为false;去掉修改该值即可
那么问题来了？重连连接后手动那么多遗漏的消息，怎么选择只接收最新的一条消息呢？
MQTT推送消息订阅端重复接收问题。
（背景）订阅端断开的时候，发布端多次推送消息。
（现象）订阅端启动时，接收到msg1，msg2，msg3 （这三个消息都是同一个类型消息，只需要处理最新的msg3就好，不然界面会刷新三次）这个谁有什么好办法没呢？
GitHub地址： https://github.com/eclipse/paho.mqtt.android
mqtt的官方文档： http://mqtt.org/documentation
Github上有中文翻译： https://github.com/mcxiaoke/mqtt
在mole的build.gradle文件中添加依赖
在 AndroidManifest.xml 添加限权
在 AndroidManifest.xml 注册Service （MyMqttService为自己写的服务，下文会讲到）
3. android系统的APP消息推送机制
参考文章：
http://blog.csdn.net/carson_ho/article/details/52862418
1. 主流的第三方推送平台分类
手机厂商类：小米推送、华为推送。
第三方平台类：友盟推送、极光推送、云巴（基于MQTT）
BAT大厂的平台推送：阿里云移动推送、腾讯信鸽推送、网络云推送
2. 对比其他推送方式的特点
其他推送方式还有：C2DM、轮询、SMS、MQTT协议、XMPP协议等等，相对于这些推送方式，第三方推送方式的特点分别是：
优点：
成本低
上述的推送大多数是免费的，假如自己实现则消耗过多资源（开发成本和后台管理、统计成本）
消息到达率高
如果一个手机里有多个App使用了同一家推送服务，那么这些App将共用一条消息通道，即使你家的App推送服务被杀死了，那么只要用户打开了其他集成该推送服务的App，你家的推送就能到达用户
缺点
安全性低
使用别人的服务器，所以你懂的。
服务会被杀死
由于Android系统的机制，后台推送 Service 会被各种主动的或是被动的行为给杀死，而服务一旦被杀死，意味着就接收不到推送消息。
3. 第三方推送服务方式的特点
第三方服务基本都具备免费、和到达率高的特点
那么应该如何选择呢？我们来分别看一下第三方推送各种方式的优点：
3.1 手机厂商推送
请记住一个潜规则：操作系统是不会杀死属于自己品牌的推送服务。
手机厂商的推送服务在自家的手机上属于系统级别的服务，这意味着系统不会杀死自家的推送服务
比如说，Android原生系统是不会杀死C2DM消息推送服务，MIUI系统是不会杀死小米的推送服务。
当今市场上的Android手机系统份额最高是MIUI系统，即小米（具体排名请看http://www.umindex.com/）
因为：免费、到达率高且在Android系统市场份额第一的MIUI系统上不被杀死。所以，如果要选择手机厂商的推送服务，请选择小米推送作为第三方平台实现推送服务
下面一些应用可以从侧面来证明我的推断：
腾讯新闻使用的小米推送，没有使用自己家的信鸽推送
淘宝使用了自家的阿里云推送，同时还集成了小米推送
网络视频和爱奇艺使用的是小米推送，没有用自家的网络推送
官网截图 - 集成应用：
如果希望进一步提高推送的效果，其实可以集成多个手机厂商的推送服务
比如小米渠道用小米推送，华为渠道用华为推送，但这样的实现成本会大一些
3.2 第三方平台类
请记住一个规则：推送系统会共享一条推送渠道
这意味着假设你接入了友盟推送，而恰好今日头条也接入了友盟。
有一天你的App被杀死了，但这时用户启动了今日头条，那么推送系统也就会通过共享的推送通道顺便把你推送消息送达到手机上，然后还可能把你的进程也唤醒（被“保活”了）。
所以说，关于如何选择第三方平台类的推送，推送平台的规模效应就很重要了。
那如何得知他们的规模和市场份额呢？按个人经验，主要看两点：
问内部的朋友。
看推送平台的合作客户里有哪些大的app - 参考对应官网的合作案例
3.3 BAT大厂的推送
BAT大厂其实并没有什么优势，同时谨记：
不要以为用了腾讯信鸽推送，就能占上微信的光保证你的App永远内部被杀死。
说个题外话，手机淘宝除了自家的阿里云的移动推送，同时也使用其它的第三方推送平台啊（比如友盟推送）。
4. 如何选择第三方平台推送服务？
主要从用户类别+实现成本+渠道来选择不同的使用场景
1. 如果用户群体精准（使用小米手机或华为手机居多），可以考虑只集成对应手机厂商的推送；
注意：单一的手机厂商也能工作，比如小米推送在非小米手机上当然也能工作，只不过不是系统级别的服务了，容易被杀死。
如果用户群体广泛、希望实现成本低，可以考虑只使用单一第三方平台类的推送（极光、友盟blabla，选一个规模效应最大的）
如果用户群体广泛、不在意实现成本，个人建议：
对于小米手机，使用小米推送；
对于华为手机，使用华为推送；
对于其他手机，只使用单一第三方平台类的推送（极光、友盟blabla，选一个规模效应最大的）
让不同的推送运行在各自擅长的环境里，最大化实现推送的到达率和产品的存活率
大家可以根据自己的使用场景来进行消息推送平台的选择。
5. 推送消息类别的选择
5.1 推送消息的类别
通常第三方推送平台都支持两种推送消息类型：通知栏消息和透传消息。
通知栏消息：该类消息在被送达用户的设备后，直接以系统通知栏的形式展示给用户
不会继续被传递到App
透传消息：该类消息在被送达用户的设备后，还会继续传递到App
通过回调App的某个BroadcastReceiver的形式将消息传递到App内部。然后由App决定如何处理和显示这个消息。
所以透传消息不一定会以系统通知栏的形式进行推送，由程序猿自定义
5.2 消息类别的区别与特点
二者的区别在于：透传消息在整个消息传递过程中比通知栏消息多了一步-传递到App
通知栏消息的优点：送达率高
因为透传消息在整个消息传递过程中比通知栏消息多了一步-传递到App，因此透传消息就增加一些被系统限制的概率，给系统杀死的概率就高一些，所以说，通知栏消息比透传消息应该能提供更好的送达率。
我们来看下小米推送的官方文档描述：
在一些 Android 系统(如 MIUI)中，受到系统自启动管理设置的限制,应用不能在后台自启动
在这类系统中，如果在发送消息的时候对应的应用没有被启动，透传类消息将不能顺利送达。
因此,对于对送达率要求很高的消息,建议尽量采用通知栏提醒的方式推送消息
透传消息的优点：对消息操作程度高 & 自定义程度高
提供了对消息数据的更灵活的操纵能力。
App如果仅仅通过通知栏消息，是无法接触到消息数据本身的。
可自定义通知提醒的样式（包括提示样式、提示形式如声音等等）
所以大家可以根据不同的使用场景来对推送消息类别进行选择了。
4. java服务器推送消息给android
几种常见的解决方案实现原理
1）轮询(Pull)方式：客户端定时向服务器发送询问消息，一旦服务器有变化则立即同步消息。
2）SMS(Push)方式：通过拦截SMS消息并且解析消息内容来了解服务器的命令，但这种方式一般用户在经济上很难承受。
3）持久连接(Push)方式：客户端和服务器之间建立长久连接，这样就可以实现消息的及时行和实时性。
3、消息推送解决方案概述
A、C2DM云端推送方案
在Android手机平台上，Google提供了C2DM（Cloudto Device Messaging）服务。Android
Cloud to Device Messaging (C2DM)是一个用来帮助开发者从服务器向Android应用程序发送数据的服务。该服务提供了一个简单的、轻量级的机制，允许服务器可以通知移动应用程序直接与服务器进行通信，以便于从服务器获取应用程序更新和用户数据。
该方案存在的主要问题是C2DM需要依赖于Google官方提供的C2DM服务器，由于国内的网络环境，这个服务经常不可用。
B、MQTT协议实现Android推送
采用MQTT协议实现Android推送功能也是一种解决方案。MQTT是一个轻量级的消息发布/订阅协议，它是实现基于手机客户端的消息推送服务器的理想解决方案。
wmqtt.jar
是IBM提供的MQTT协议的实现。我们可以从这里（https://github.com/toku/AndroidPushNotificationsDemo）下载该项目的实例代码，并且可以找到一个采用php书写的服务器端实现（https://github.com/toku/PhpMQTTClient）。
C、RSMB实现推送功能
Really Small Message Broker (RSMB)
，是一个简单的MQTT代理，同样由IBM提供，其查看地址是：http://www.alphaworks.ibm.com/tech/rsmb。缺省打开1883端口，应用程序当中，它负责接收来自服务器的消息并将其转发给指定的移动设备。SAM是一个针对MQTT写的PHP库。我们可以从这个http://pecl.php.net/package/sam/download/0.2.0地址下载它.
D、XMPP协议实现Android推送
Google官方的C2DM服务器底层也是采用XMPP协议进行的封装。XMPP(可扩展通讯和表示协议)是基于可扩展标记语言（XML）的协议，它用于即时消息（IM）以及在线探测。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。
androidpn是一个基于XMPP协议的java开源Android push notification实现。它包含了完整的客户端和服务器端。但也存在一些不足之处：
1）
比如时间过长时，就再也收不到推送的信息了。
2）性能上也不够稳定。
3）如果将消息从服务器上推送出去，就不再管理了，不管消息是否成功到达客户端手机上。
如果我们要使用androidpn，则还需要做大量的工作，需要理解XMPP协议、理解Androidpn的实现机制，需要调试内部存在的BUG。
5. 如何实现android和服务器的长连接
转载 这种功能实际上就是数据同步，同时要考虑手机本身、电量、网络流量等等限制因素，所以通常在移动端上有一下两个解决方案:
1.一种是定时去server查询数据，通常是使用HTTP协议来访问web服务器，称Polling（轮询）；
2.还有一种是移动端和服务器建立长连接，使用XMPP长连接，称Push（推送）。
从耗费的电量、流量和数据延迟性各方面来说，Push有明显的优势。但是使用Push的缺点是：
对于客户端：实现和维护相对成本高，在移动无线网络下维护长连接，相对有一些技术上的开发难度。
对于服务器：如何实现多核并发，cpu作业调度，数量庞大的长连接并发维护等技术，仍存在开发难点。
在讲述Push方案的原理前，我们先了解一下移动无线网络的特点。
移动无线网络的特点：
因为 IP v4 的 IP 量有限，运营商分配给手机终端的 IP 是运营商内网的 IP，手机要连接 Internet，就需要通过运营商的网关做一个网络地址转换（Network Address Translation，NAT）。简单的说运营商的网关需要维护一个外网 IP、端口到内网 IP、端口的对应关系，以确保内网的手机可以跟 Internet 的服务器通讯
GGSN（Gateway GPRS
Support Node 网关GPRS支持结点）模块就实现了NAT功能。
因为大部分移动无线网络运营商都是为了减少网关的NAT映射表的负荷，所以如果发现链路中有一段时间没有数据通讯时，会删除其对应表，造成链路中断。（关于NAT的作用及其原理可以查看我的另一篇博文：关于使用UDP(TCP)跨局域网，NAT穿透的心得）
Push在Android平台上长连接的实现：
既然我们知道我们移动端要和Internet进行通信，必须通过运营商的网关，所以，为了不让NAT映射表失效，我们需要定时向Internet发送数据，因为只是为了不然NAT映射表失效，所以只需发送长度为0的数据即可。
这时候就要用到定时器，在android系统上，定时器通常有一下两种：
1.java.util.Timer
2.android.app.AlarmManager
分析：
Timer:可以按照计划或者时间周期来执行相关的任务。但是Timer需要用WakeLock来让CPU保持唤醒状态，才能保证任务的执行，这样子会消耗大量流量；当CPU处于休眠的时候，就不能唤醒执行任务，所以应用于移动端明显是不合适。
AlarmManager：AlarmManager类是属于android系统封装好来管理RTC模块的管理类。这里就涉及到RTC模块，要更好地了解两者的区别，就要明白两者真正的区别。
RTC（Real- Time Clock）实时闹钟在一个嵌入式系统中，通常采用RTC
来提供可靠的系统时间，包括时分秒和年月日等;而且要求在系统处于关机状态下它也能够正常工作（通常采用后备电池供电），它的外围也不需要太多的辅助电路，典型的就是只需要一个高精度的32.768KHz
晶体和电阻电容等。（如果对这方面感兴趣，可以自己查阅相关资料，这里就说个大概）
好了，回来正题。所以，AlarmManager又称全局定时闹钟。这意味着，当我用使用AlarmManager来定时执行任务，CPU可以正常地休眠，只有在执行任务是，才唤醒CPU，这个过程是很短时间的。
下面简单来说明其使用：
1.类似于Timer功能：
//获得闹钟管理器
AlarmManager
am = (AlarmManager)getSystemService(ALARM_SERVICE);
//设置任务执行计划
am.setRepeating(AlarmManager.ELAPSED_REALTIME, firstTime, 5*1000,
sender);//从firstTime才开始执行，每隔5秒再执行
2.实现全局定时功能：
//获得闹钟管理器
AlarmManager
am = (AlarmManager)getSystemService(ALARM_SERVICE);
//设置任务执行计划
am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstTime,
5*1000, sender);//从firstTime才开始执行，每隔5秒再执行
总结：在android客户端使用Push推送时，应该使用AlarmManager来实现心跳功能，使其真正实现长连接。