android与服务器交互用post好还是get
要根据实际应用的需求和数据量。
HTTP 定义了与服务器交互的不同方法,最基本的方法是 GET 和 POST。
事实上 GET 适用于多数请求,而保留 POST 仅用于更新站点。根据 HTTP 规范,GET 用于信息获取,而且应该是 安全的和 幂等的。所谓安全的意味着该操作用于获取信息而非修改信息。换句话说,GET 请求一般不应产生副作用。幂等的意味着对同一 URL 的多个请求应该返回同样的结果。完整的定义并不像看起来那样严格。从根本上讲,其目标是当用户打开一个链接时,它可以确信从自身的角度来看没有改变资源。比如,新闻站点的头版不断更新。虽然第二次请求会返回不同的一批新闻,该操作仍然被认为是安全的和幂等的,因为它总是返回当前的新闻。反之亦然。
POST 请求就不那么轻松了。POST 表示可能改变服务器上的资源的请求。仍然以新闻站点为例,读者对文章的注解应该通过 POST 请求实现,因为在注解提交之后站点已经不同了(比方说文章下面出现一条注解);
在FORM提交的时候,如果不指定Method,则默认为GET请求,Form中提交的数据将会附加在url之后,以分开与url分开。字母数字字符原样发送,但空格转换为“+“号,其它符号转换为%XX,其中XX为该符号以16进制表示的ASCII(或ISO Latin-1)值。GET请求请提交的数据放置在HTTP请求协议头中,而POST提交的数据则放在实体数据中;
GET方式提交的数据最多只能有1024字节,而POST则没有此限制。
提出问题:这种功能必须涉及client(客户端)和server(服务器),所以到底client如何和server实现实时连接通讯?
分析问题:这种功能实际上就是数据同步,同时要考虑手机本身、电量、网络流量等等限制因素,所以通常在移动端上有一下两个解决方案:
1一种是定时去server查询数据,通常是使用HTTP协议来访问web服务器,称Polling(轮询);
2还有一种是移动端和服务器建立长连接,使用XMPP长连接,称Push(推送)。(按照本人理解:客户端的实现时:
while(true) {
request(timeout);
request(timeout);
}
客户端发出一个“长”请求,如果服务器发送消息或者时间out了,客户端就断开这个请求,再建立一个长请求
)
从耗费的电量、流量和数据延迟性各方面来说,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系统上,定时器通常有一下两种:
1javautilTimer
2androidappAlarmManager
分析:
Timer:可以按照计划或者时间周期来执行相关的任务。但是Timer需要用WakeLock来让CPU保持唤醒状态,才能保证任务的执行,这样子会消耗大量流量;当CPU处于休眠的时候,就不能唤醒执行任务,所以应用于移动端明显是不合适。
AlarmManager:AlarmManager类是属于android系统封装好来管理RTC模块的管理类。这里就涉及到RTC模块,要更好地了解两者的区别,就要明白两者真正的区别。
RTC(Real- Time Clock)实时闹钟在一个嵌入式系统中,通常采用RTC 来提供可靠的系统时间,包括时分秒和年月日等;而且要求在系统处于关机状态下它也能够正常工作(通常采用后备电池供电),它的外围也不需要太多的辅助电路,典型的就是只需要一个高精度的32768KHz 晶体和电阻电容等。(如果对这方面感兴趣,可以自己查阅相关资料,这里就说个大概)
好了,回来正题。所以,AlarmManager又称全局定时闹钟。这意味着,当我用使用AlarmManager来定时执行任务,CPU可以正常地休眠,只有在执行任务是,才唤醒CPU,这个过程是很短时间的。
下面简单来说明其使用:
1类似于Timer功能:
//获得闹钟管理器
AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE);
//设置任务执行计划
amsetRepeating(AlarmManagerELAPSED_REALTIME, firstTime, 51000, sender);//从firstTime才开始执行,每隔5秒再执行
2实现全局定时功能:
//获得闹钟管理器
AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE);
//设置任务执行计划
amsetRepeating(AlarmManagerELAPSED_REALTIME_WAKEUP, firstTime, 51000, sender);//从firstTime才开始执行,每隔5秒再执行
总结:在android客户端使用Push推送时,应该使用AlarmManager来实现心跳功能,使其真正实现长连接。
在服务器端的实现:
在服务器端,可以使用很多语言来实现,如C/C++,java,Erlang等等,如我们国内比较好的极光推送(C开发),openfire(java开发)等等。
最近我看了极光推送的介绍和原理,下面我就说说他们是遇到什么难题,然后使用什么技术或者方案来解决呢。
当有大量的手机终端需要与服务器维持长连接时,对服务器的设计会是一个很大的挑战。
假设一台服务器维护10万个长连接,当有1000万用户量时,需要有多达100台的服务器来维护这些用户的长连接,这里还不算用于做备份的服务器,这将会是一个巨大的成本问题。那就需要我们尽可能提高单台服务器接入用户的量,也就是业界已经讨论很久了的 C10K 问题。
C2000K
针对这个问题,他们专门成立了一个项目,命名为C2000K,顾名思义,他们的目标是单机维持200万个长连接。最终他们采用了多消息循环、异步非阻塞的模型,在一台双核、24G内存的服务器上,实现峰值维持超过300万个长连接。
最后总结:
因为我最近用java在做一个PC、服务器、android的即时通讯系统(说白了就是模仿QQ,后面希望有不同的功能)。我的原则是用别人的原理,自己来实现,这样才更好深入了解一些框架。所以,估计难点是在通讯开发和服务器上的开发,必须深刻了解多消息循环、异步非阻塞的模型。之后我会发表关于这方面的实现。
在现在的android平台上,已经不是android单机的世界了(我不是说做单机游戏没有前途)。现在都是依靠发展蓬勃的互联网来支撑整个IT体系,所以,要成为一个android应用开发高手,必须朝着android、硬件、云服务这一体系来发展。
APP开发流程包括以下步骤:
1、需求评估:提交方案后,需要找前端与后端开发人员探讨方案可行性,包括功能开发的难度、实际开发的费用以及时间。
2、UI设计与项目开发:项目各个部门开始讨论,UI设计部门针对产品开展设计UI界面跟UE。
3、项目启动:根据产品功能需求文档进行评估,提出测评、预发跟正式发布时间。
4、程序开发:前端开发-程序开发-接口对接-第三方接入(支付宝等)-定期项目会议沟通和管控项目开展-开发预算审计。
5、程序测试:由测试专员针对APP进行多机型测试,测试内容包括:APP内容测试、APP性能测试、APP功能测试、APP视觉测试、对于BUG调试修复。测试合格,确认没有BUG后与客户进行沟通,开始走验收流程。
6、APP上线:APP上线审核一般苹果的APP
STORE审核大概需要一个星期,安卓审核在3天左右,所以APP开发测试一定要提前半个月完成,给长线审核预留一定的时间。
1 socket,自己用socket来实现服务器,自己指定交互规则,达到和客户端交互。
2 网站web,然后提供一个访问接口,安卓客户端可以通过这个接口与服务器交互,获取数据,传递数据等。具体来说服务器就是一个web工程,所以你需要搭建服务器(tomcat等),把你的web应用发布到服务器上。至于交互一般可以用servlet来和安卓客户端交互,进而可以用action,这其实是j2e方面的知识了,所以你可以去了解下这方面的知识。
总体来说的话个人感觉第二种方法较好,因为交互层是别人写好的,你自己写的话有时候问题比较多。
0条评论