长连接android
⑴ android怎么实现HTTP长连接
转载 这种功能实际上就是数据同步，同时要考虑手机本身、电量、网络流量等等限制因素，所以通常在移动端上有一下两个解决方案: 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来实现心跳功能，使其真正实现长连接。
⑵ 如何实现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来实现心跳功能，使其真正实现长连接。
⑶ android 长连接怎么省电
1）灭屏待机最省电：
a)任何App包括后台Service应该尽可能减少唤醒CPU的次数，比如IM类业务的长连接心跳、QQ提醒待机闹钟类业务的alarm硬时钟唤醒要严格控制；
b)每次唤醒CPU执行的代码应该尽可能少，从而让CPU迅速恢复休眠，比如申请wake lock的数量和持有时间要好好斟酌；
2）Wi-Fi比蜂窝数据，包括2G（GPRS）、3G更省电：
a)尽量在Wi-Fi下传输数据，当然这是废话，不过可以考虑在有Wi-Fi的时候做预加载，比如应用中心的zip包、手Q web类应用的离线资源等；
b)非Wi-Fi下，尽量减少网络访问，每一次后台交互都要考虑是否必须。虽然WiFi接入方式已经占到移动互联网用户的50%，但是是有些手机设置为待机关闭WiFi连接，即便有Wi-Fi信号也只能切换到蜂窝数据；
测试分析：
1）灭屏的情况：
a)灭屏待机，CPU处于休眠状态，最省电（7mA）；
b)灭屏传输，CPU被激活，耗电显着增加，即便是处理1K的心跳包，电量消耗也会是待机的6倍左右（45mA）；
c)灭屏传输，高负载download的时候WiFi最省电（70mA），3G（270mA）和2G（280mA）相当，是WiFi的4倍左右；
1
Android手机耗电深度解析！
2）亮屏的情况：
a)亮屏待机，CPU处于激活状态，加上屏幕耗电，整机电量消耗不小（140mA）；
b)亮屏传输，如果只是处理1K的心跳包，耗电增加不多（150mA），即便是很大的心跳包（64K），消耗增加也不明显（160mA）；
c)亮屏传输，高负载download的时候WiFi最省电（280mA），3G（360mA）和2G（370mA）相当，是WiFi的1.3倍左右；
1
Android手机耗电深度解析！
3）Alarm唤醒频繁会导致待机耗电增加：
手机灭屏后会进入待机状态，这时CPU会进入休眠状态。Android的休眠机制介绍的文章很多，这里引用一段网络文章：
Early suspend是android引进的一种机制,这种机制在上游备受争议,这里 不做评论。这个机制作用在关闭显示的时候,在这个时候,一些和显示有关的 设备,比如LCD背光,比如重力感应器,触摸屏,这些设备都会关掉,但是系统可能还是在运行状态(这时候还有wake lock)进行任务的处理,例如在扫描SD卡上的文件等.在嵌入式设备中,背光是一个很大的电源消耗,所以android会加入这样一种机制.
Late Resume是和suspend配套的一种机制,是在内核唤醒完毕开始执行的.主要就是唤醒在Early Suspend的时候休眠的设备.
Wake Lock在Android的电源管理系统中扮演一个核心的角色. Wake Lock是一种锁的机制,只要有人拿着这个锁,系统就无法进入休眠,可以被用户态程序和内核获得.这个锁可以是有超时的或者是没有超时的,超时的锁会在时间过去以后自动解锁.如果没有锁了或者超时了,内核就会启动休眠的那套机制来进入休眠.
当用户写入mem或者standby到/sys/power/state中的时候, state_store()会被调用,然后Android会在这里调用request_suspend_state()而标准的Linux会在这里进入enter_state()这个函数.如果请求的是休眠,那么early_suspend这个workqueue就会被调用,并且进入early_suspend
简单的说，当用户按power键，使得手机进入灭屏休眠状态，Android系统其实是做了前面说的一些工作：关闭屏幕、触摸屏、传感器、mp当前用户态和内核态程序运行上下文到内存或者硬盘、关闭CPU供电，当然为了支持语音通讯，modern等蜂窝信令还是工作的。
这种情况下，应用要唤醒CPU，只有两种可能：
a)通过服务器主动PUSH数据，通过网络设备激活CPU；
b)设置alarm硬件闹钟唤醒CPU；
这里我们重点分析第二种情况。首先来看看什么是alarm硬件闹钟。Google官方提供的解释是：Android提供的alarm services可以帮助应用开发者能够在将来某一指定的时刻去执行任务。当时间到达的时候，Android系统会通过一个Intent广播通知应用去完成这一指定任务。即便CPU休眠，也不影响alarm services的服务，这种情况下可以选择唤醒CPU。
显然唤醒CPU是有电量消耗的，CPU被唤醒的次数越多，耗电量会越大。现在很多应用为了维持心跳、拉取数据、主动PUSH会不同程度地注册alarm服务，导致Android系统被频繁唤醒。这就是为什么雷军说Android手机在安装了TOP100的应用后，待机时间会大大缩短的重要原因。
比较简单评测CPU唤醒次数的方法是看mpsys alarm，这里会详细记录从开机到当前的各个进程和服务唤醒CPU的次数和时间。通过对比唤醒次数和唤醒时间可以帮助我们分析后台进程和服务的耗电情况。Dumpsys alarm的输出看起来像这样：
其中544代表唤醒次数，38684ms代表唤醒时间 [保存到相册]
4）Wake locks持有时间过长会导致耗电增加：
Wake locks是一种锁机制，有些文献翻译成唤醒锁。简单说，前面讲的灭屏CPU休眠还需要做一个判断，就是看是否还有任何应用持有wake locks。如果有，CPU将不会休眠。有些应用不合理地申请wake locks，或者申请了忘记释放，都会导致手机无法休眠，耗电增加。
原始数据：
测试方法：硬件设备提供稳压电源替代手机电池供电，在不同场景下记录手机平均电流。
测试设备：Monsoon公司的Power Monitor TRMT000141
测试机型：Nexus One
1
灭屏benchmark（CPU进入休眠状态）：7mA [保存到相册] 0
灭屏WiFi：70 mA [保存到相册]
0
灭屏3G net：270 mA [保存到相册]
http://digi.it.sohu.com/20131116/n390249625.shtml
⑷ android、ios客户端和服务器通信一般使用什么方式，各有什么优缺点
1、从网络协议上来看，就http方式和socket方式。
2、http方式开发起来效率想对要高一点，但是对于推送这种来说，想对要难做点，因为http是短连接。socket这种方式开发要长，调试略微麻烦，但是做推送想对简单，可以建立一个长连接。
3、Web Service服务其实也是基于HTTP协议（它基于SOAP协议，而SOAP又是基于HTTP协议）。
最大缺点我觉得是Web Service实在是太厚重了，特别对于移动端来说，WSDL是基于XML，XML已经够厚重了，WSDL还有一些头信息，更加厚重。
而且JSON + HTTP的方式，相对来说就非常轻量级了，JSON格式数据本生就是Javascript中的数据或者对象，所以在网络传输中具有非常明显优势，可以说本来就是网络传输用的，毫无违和感嘛：）
还有一个不能算缺点的缺点：目前移动端HTTP网络库多的要死，Web Service我所知道就是ksoap2，而且非常的难用。。。
⑸ 如何在android客户端实时监控websocket长连接时服务器实时推送的
使用Socket类中的Poll方法，就可以。 Socket client //假如已经创建好了，连接到服务器端得Socket的客户端对象。 我们只要client.Poll(10,SelectMode.SelectRead)判断就行了。只要返回True是。就可以认为客户端已经断开了。 Poll 方法将会检查 Socket 的状态。指定 selectMode 参数的 SelectMode..::.SelectRead，可确定 Socket 是否为可读。指定 SelectMode..::.SelectWrite，可确定 Socket 是否为可写。使用 SelectMode..::.SelectError 检测错误条件。Poll 将在指定的时段（以 microseconds 为单位）内阻止执行。如果希望无限期的等待响应，则将 microSeconds 设置为一个负整数。如果要检查多个套接字的状态，则不妨使用 Select 方法。