android平台的app、手机客户端和后台服务器怎么进行数据交互？

首先不要管安卓端还是苹果端，现在一般都是响应式的app，你放到安卓或者苹果或者pc或者平板都是没有问题的。一般采用的是http接口通讯，或者socket连接。具体你要去查资料找Demo了。而且现在主流是采用html5开发或者混合开发了。所以最好是服务器提供appAPI接口，通过http访问服务器，获取数据，数据一般是json，或者xml，拿到后解析数据就可以了，然后再用UI框架或者其他框架或者自定义的UI封装下格式很漂亮了，至于cookie和session等，看你的习惯，网络验证和签名那些也自己看习惯，如果涉及到大数据，还需要引入第三方框架的，直接引入就可以了，不过推荐自己写，防止侵权。都是很通用的。

数据交换（Data Switching）是指在多个数据终端设备（DTE）之间，为任意两个终端设备建立数据通信临时互连通路的过程。数据交换可以分为：电路交换、报文交换、分组交换和混合交换。电路交换原理与电话交换原理基本相同。电路交换的缺点是电路的利用率低，双方在通信过程中的空闲时间，电路不能得到充分利用。

报文交换的原理是当发送方的信息到达报文交换用的计算机时，先存放在外存储器中，待中央处理机分析报头，确定转发路由，并选到与此路由相应的输出电路上进行排队，等待输出。一旦电路空闲，立即将报文从外存储器[1]  取出后发出，这就提高了这条电路的利用率。报文交换虽然提高了电路的利用率，但报文经存储转发后会产生较大的时延。分组交换也是一种存储转发交换方式，但与报文交换不同，它是把报文划分为一定长度的分组，以分组为单位进行存储转发。这就不但具备了报文交换方式提高电路利用率的优点，同时克服了时延大的缺点。

与电文交换相比，分组交换的优点是：

①在电文交换中，总的传输时延是每个节点上接收与转发整个电文时延的总和，而在分组交换中，某个分组发送给一个结点后，就可以接着发送下一个分组，这样总的时延就减小；

②每个节点所需要的缓存器容量减小，这有利于提高节点存储资源的利用率；

③传输有差错时，只要重发一个或若干个分组，不必重发整个电文，这样可以提高传输效率。分组交换的缺点是每个分组要附加一些控制信息，这会使传输效率降低，尤以长电文为甚。一般分组交换提供虚电路和数据报两种基本业务。[2] 

混合交换

在一个计算机网络中同时采用电路交换和分组交换方式，称为混合交换。混合的方法是将传送信道分为不同的带宽，将一部分带宽分配给电路交换使用，而将另一部分带宽分配给分组交换使用。这里所谓的带宽就是指在一条传输信道上允许传输信息的频带宽度，即能从信道上通过信号的最高频率。

打开背包向服务器申请数据服务器下发被背包内的物品 ID 、Count（结构体形式以List发送到客户端）

客户端根据接受的ID、Count去本地配置表中配置物品然后显示在背包中

（从服务器接受后在本地查找ID对应的 属性 类型后加入Count显示在背包中）

点击物品，将物品ID发送到服务器，服务器扣除物品数量，并将使用物品后所需的效果（如 增加经验、属性等），增加完毕之后将数值返回给客户端，客户端更新背包内容并将对应属性同步刷新显示（如果物品用完 将物品从储存的List中将物品进行删除操作）

服务器向背包发送ID、Count，在本地配置表中生成后 刷新显示到背包中。

客户端发送 角色ID 到客户端，客户端在库中搜索角色

         （1）玩家2同意添加好友，玩家2客户端向服务器发送消息，服务器将两 人绑定为好友关系，将数据（玩家ID等）下发到双方客户端，并刷新 显示双方客户端好友列表。

         （2）玩家2拒绝添加好友，玩家2客户端向服务器发送消息，服务器向玩 家1发送消息，玩家1客户端显示被拒绝消息提醒。

玩家1向服务器发送消息，服务器取消双方好友关系的绑定，并将数据发回双方客户 端，客户端更新显示好友框。

通常以动态生成和隐藏方式显示，只显示上下5个范围内容。。。。。

客户端向服务器发送消息，服务器判断当前时间，并判断当天是否签到过，如未签到 过，向客户端发送信息，客户端显示签到成功，并修改签到按钮为已经签到，如需领 取签到奖励，参考背包获得物品。

服务器记录账号签到天数，如需要补签将补签日期ID发送到服务器，服务器判定当 天是否签到，未签到则执行签到操作，获取奖励物品。

服务器向客户端发送消息（邮件名、邮件内容、是否有附件、附件ID、Count），客 户端接受信息后显示有新邮件的提示，在本地配置表中填入接受的消息，并显示在邮 件中。客户端点击领取附件（向服务器发送消息，已经领取），并且做背包操作，参 考背包系统获取物品。

玩家1编辑邮件，点击发送按钮，将邮件（名称、内容、是否有附件、附件、收件 人）发送到服务器，服务器在库中索搜收件人，然后参考系统附件邮件操作。

把服务器看成是文件中转站就行了，从客户端接收消息，再转发到目标客户端。

source

<->

server

<=>

destination

在游览器与WEB服务器之间信息交互的过程中使用的协议是HTTP。

HTTP是一个客户端和服务器端请求和应答的标准（TCP）。客户端是终端用户，服务器端是网站。通过使用Web浏览器、网络爬虫或者其它的工具，客户端发起一个到服务器上指定端口（默认端口为80）的HTTP请求。（我们称这个客户端）叫用户代理（user agent）。

应答的服务器上存储着（一些）资源，比如HTML文件和图像。（我们称）这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在多个中间层，比如代理，网关，或者隧道（tunnels）。

尽管TCP/IP协议是互联网上最流行的应用，HTTP协议并没有规定必须使用它和（基于）它支持的层。 事实上，HTTP可以在任何其他互联网协议上，或者在其他网络上实现。HTTP只假定（其下层协议提供）可靠的传输，任何能够提供这种保证的协议都可以被其使用。

扩展资料：

协议功能

HTTP协议（HyperText Transfer Protocol，超文本传输协议）是用于从WWW服务器传输超文本到本地浏览器的传输协议。它可以使浏览器更加高效，使网络传输减少。

它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。

HTTP包含命令和传输信息，不仅可用于Web访问，也可以用于其他因特网/内联网应用系统之间的通信，从而实现各类应用资源超媒体访问的集成。

--http

最简单的模式就是，

客户端接收键盘，鼠标等的消息，然后发送个服务器。

服务器收到这些消息后，发送给其他（指定或者所有的）客户端

就像你在WEB聊天室聊天一样。首先键盘输入了一大堆文字。然后按下“递交”按钮，于是客户端收集你填写的那些文字内容，然后发送给服务器。（也许里面有些色情暴力的字眼）

服务器在接收的这些消息后，发送给其他用户。（服务器可能和谐掉那些色情暴力的字眼，变成了XXOO）

网络游戏的客户端和服务器也是一样的道理

客户端纪录所有的消息指令，一般来说，如果该消息指令可能影响到其他人的，或者需要被其他人看到，这个消息就会需要被发送到服务器。

服务器处理这些消息进行处理，发送给其他相关的客户端。

直白点来说，服务器端与客户端分别处理哪些事情？你是老板，你说了算。

一、消息推送基础

消息推送，就是在互联网上通过定期传送用户需要的信息来减少信息过载的一项新技术。推送技术通过自动传送信息给用户，来减少用于网络上搜索的时间。它根据用户的兴趣来搜索、过滤信息，并将其定期推给用户，帮助用户高效率地发掘有价值的信息

当我们开发需要和服务器交互的移动应用时，基本上都需要和服务器进行交互，包括上传数据到服务器，同时从服务器上获取数据。

一般情况下，客户端与服务器之间通讯客户端是主动的，但这就存在一个问题就是一旦服务器数据有更新或者服务器要下发通知给客户端只能等客户端连接的时候才能实现。这种方式使消息失去了实时性。

如何使客户端能够实时的收到服务器的消息和通知，总体来说有两种方式，第一种是客户端使用Pull（拉）的方式，就是隔一段时间就去服务器上获取一下信息，看是否有更新的信息出现。第二种就是 服务器使用Push（推送）的方式，当服务器端有新信息了，则把最新的信息Push到客户端上。这样，客户端就能自动的接收到消息。 

虽然Pull和Push两种方式都能实现获取服务器端更新信息的功能，但是明显来说Push方式比Pull方式更优越。因为Pull方式更费客户端的网络流量，更主要的是费电量，还需要我们的程序不停地去监测服务端的变化。  

二、几种常见的解决方案实现原理

1）轮询(Pull)方式：客户端定时向服务器发送询问消息，一旦服务器有变化则立即同步消息。

2）SMS(Push)方式：通过拦截SMS消息并且解析消息内容来了解服务器的命令，但这种方式一般用户在经济上很难承受。

3）持久连接(Push)方式：客户端和服务器之间建立长久连接，这样就可以实现消息的及时行和实时性。

三、消息推送解决方案概述

A、C2DM云端推送方案

在Android手机平台上，Google提供了C2DM（Cloudto Device Messaging）服务。Android Cloud to Device Messaging (C2DM)是一个用来帮助开发者从服务器向Android应用程序发送数据的服务。该服务提供了一个简单的、轻量级的机制，允许服务器可以通知移动应用程序直接与服务器进行通信，以便于从服务器获取应用程序更新和用户数据。

该方案存在的主要问题是C2DM需要依赖于Google官方提供的C2DM服务器，由于国内的网络环境，这个服务经常不可用。

B、MQTT协议实现Android推送

采用MQTT协议实现Android推送功能也是一种解决方案。MQTT是一个轻量级的消息发布/订阅协议，它是实现基于手机客户端的消息推送服务器的理想解决方案。

wmqttjar 是IBM提供的MQTT协议的实现。我们可以从这里（https://githubcom/tokudu/AndroidPushNotificationsDemo）下载该项目的实例代码，并且可以找到一个采用PHP书写的服务器端实现（https://githubcom/tokudu/PhpMQTTClient）。

C、RSMB实现推送功能

Really Small Message Broker (RSMB) ，是一个简单的MQTT代理，同样由IBM提供，其查看地址是：http://wwwalphaworksibmcom/tech/rsmb。缺省打开1883端口，应用程序当中，它负责接收来自服务器的消息并将其转发给指定的移动设备。SAM是一个针对MQTT写的PHP库。我们可以从这个http://peclphpnet/package/sam/download/020地址下载它

D、XMPP协议实现Android推送

Google官方的C2DM服务器底层也是采用XMPP协议进行的封装。XMPP(可扩展通讯和表示协议)是基于可扩展标记语言（XML）的协议，它用于即时消息（IM）以及在线探测。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。

androidpn是一个基于XMPP协议的java开源Android push notification实现。它包含了完整的客户端和服务器端。但也存在一些不足之处：

1） 比如时间过长时，就再也收不到推送的信息了。

2）性能上也不够稳定。

3）如果将消息从服务器上推送出去，就不再管理了，不管消息是否成功到达客户端手机上。

如果我们要使用androidpn，则还需要做大量的工作，需要理解XMPP协议、理解Androidpn的实现机制，需要调试内部存在的BUG。

E、使用第三方平台

目前国内、国外有一些推送平台可供使用，但是涉及到收费问题、保密问题、服务质量问题、扩展问题等等，又不得不是我们望而却步。

四、消息推送完美方案

综合以上论述，在建立Android消息推送方面可谓方案多多，但每一款方案都有其优缺点。但无论如何，还是自己搭建一个推送平台是上策。因为你有、他有不如自己有。

举个例子，在搭建自有推送平台上建议使用《某某Android消息推送组件》。该组不仅可以拿来即用，并且还可以提供源码以便扩展，实现自己的特殊需求。

A、推送原理

Android消息推送组件基于XMPP协议实现Android推送。XMPP（可扩展通讯和表示协议）是基于可扩展标记语言（XML）的协议，它用于即时消息（IM）以及在线探测。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。