开发社交类APP项目，我们都知道离不开聊天功能，那么聊天App后台架构应该怎样布局结构更高效？因为聊天是目前移动互联网流行的通信方式，聊天功能是当今App后台功能中的重要部分，比如当用户a向用户b发送了段消息后，用户b在线的话就能立刻收到消息等等，这些问题是我们APP开发人员需要面对解决的问题，深圳APP开发公司本文与各位一起分享我们开发工程师在处理这方面问题的经验。研究聊天功能，就要先明白移动互联网有别于PC互联网的特性，从而更好地明白协议和架构背后的原理，下面我们先分享移动网络的特性：
APP开发经验之移动互联网的网络特性
当数据从网络的端发送到另外端（例如从App端到App后台），只有通过一个共同的约定（即协议），双方才能正确解析这些数据协议就相当于一套语言（例如中文和英语），通信的双方必须知道每个数据是什么含义，才能准确解析数据。
因为移动互联网的特性，所以传统的PC通信协议不适用于移动互联网。下面从移动互联网的特性出发，详细讲述聊天的协议移动互联网有两个显著的特点。
·弱网络性
·对流量敏感
1．APP开发聊天功能移动网络环境之弱网络性
弱网络性是指由于手机不断移动（例如在7气车、地铁上）的特性，有可能处于快速移动当中，因此出现信号不稳定、响应时间变长、出现经常丢包等情况。例如有时在地铁上，从App发送请求到App后台，App后台处理完毕后返回数据这个过程因为延迟就可能需要10秒，该流程如图9-2所示。
APP开发知识移动网络之弱网络特性案例示意图9-2地铁车厢中App请求耗时
因此针对弱网络环境，开发者在没计协议时必须考虑尽量减少数据往返的次数，数据往返的次数越多，耗时越长。另外由于弱网络性，App以长连接的形式连接到服务器，可能会出现App和服务器的连接忽然中断的情况，而且这种情况是没法通过连接端口的异常判断。例如当地铁高速行驶导致网络中断，App没法向服务器的端口发送断开的信息，服务器还是以为和App直保持着连接，这种现象称为TCP half-open。
TCP half-open对我们APP开发功能的危害如下
·占用了服务器的资源（服务器维持个连接是需要耗费内存的）
·发送消息的异常。
有效防止TCP half-open的方法是使用应用层心跳机制：在App和服务器保持连接的过程中，App在规定时间间隔内向服务器发送一个数据（为了节省流量，数据可以只是个字符“h”，因为是隔定时间就发送次，这种数据被形象地称为“心跳数据”）。服务器收到这个数据知道这个连接是有效的。对于那些超过规定时间间隔还未收到心跳数据的连接，服务器就主动断开连接，通过这种机制就能有效解决TCP half-open的现象。
服务器检查App的连接有3种方式。
(1)服务器记录每个连接收到心跳包的最后时间，每隔一段时间检查所有连接，如果发现某个连接最后收到心跳包的时间减去当前时间的值大干超时时间，就把那个连接断开。如图9-3所示，服务器的当前时间为“2018-09-03 17:53:02”，各个连接最后收到心跳包的时间如下。
APP开发聊天功能与网络协议处理流程图9-3服务器忙存的连接的时间
假设服务器设定的超时时间是60秒，经比较，琏接l最后收到心跳包的时司超过了60秒，那么连接l将会被服务器断开这种方式的主要缺点是服务器需要同时检查所有连接，如果连接的数目很大（例如上万，上十万），检查连接时对系统的性能影响大
(2)服务器为每个连接建立个定时器，到了规定的超时时司没有收到心跳包定时器就触发把当前的连接断开，如果收到心跳包，就重设定时器，不断重复前面的过程。下面举个例子说明。
当前服务器的时司是2018-09-03 20:02:02．设定超时时间是60秒当App和服务器建立连接，根据超时时间为这个连接设置了定时器的触发时间为2018-09-03 20：03：02，如图9-4所示。
APP开发经验示意图9-4建立连接，初始化定时器
在2018-09-03 20:03:00，App向服务器发送了个心跳包，服务器收到心跳包后把定时器的触发重设h201s-09-03 20:04:00．如图9-5所示。
APP开发聊天功能与服务器协议流程示意图9-5服务器收到心跳包后重设定时器
如果服务器到了定时的触发时间2018-09-03 20:04:OO还没有收到App新发送的心跳包，则定时器被触发，主动端口了服务器和App的连接，如图9-6所示。
APP开发聊天功能与服务器传送协议流程示意图9—6没收到心跳包触发时器断开连接
这种方式的主要缺点是为每个连接建立个独立的定时器，如果连接的数目很大（例如上万、上十万）．就会建立上万、上十万的定时器，也会消耗大量的系统资源。
(3)这种方式是(1)和(2)的折中，称为时间轮片(Timing Wheel)。按照超时时司的长短，每秒设置一个桶，如果超时时间为60秒就设置60个桶．60个桶组成个循环队列。第一个桶欣秒后将要超时的连接，第二个桶欣两秒后将要超时的连接，每个连接收到心跳包就把自己放在第60个桶，然后在每秒的定时器中把第个桶的所有连接断开，把这个空桶挪到队尾。时间轮片的模型如图9-7所示。
APP开发聊天功能与服务器传送协议示意图9-7时间轮片模型
这种服务器检查App的连接的方式，好处是不需要检查所有的连接，节省了大量的系统资源。
2．APP开发聊天功能移动网络环境之对流量敏感
在非Wi-Fi环境下用户使用手机卡的流量套餐上网，用户对流量比较敏感，各种安全监控App也经常提醒用户，某某应用耗费了多少流量，用户看到这种消息就非常紧张，如果是生活必备的App用户可能就忍了，但其他App用户可能就直接卸载。以上问题APP开发公司提醒我们程序员在处理聊天类项目功能时必须要注意避免的。好了，本文关于聊天类APP制作时对于移动网络特性了解方面的经验就分享到这里。谢谢关注，博纳网络编辑整理。
当前文章链接：/construction/appkaifa/1736.html
如果您觉得案例还不错请帮忙分享：
[声明]本网转载网络媒体稿件是为了传播更多的信息，此类稿件不代表本网观点，本网不承担此类稿件侵权行为的连带责任。故此，如果您发现本网站的内容侵犯了您的版权，请您的相关内容发至此邮箱【qin@198bona.com 】，我们在确认后，会立即删除，保证您的版权。
