APP聊天功能开发怎样处理Radis协议格式，深圳APP开发公司在前面的文章中介绍过开发APP聊天功能MySQL通信协议的流程与技巧，移动网络时代我们几乎所有的APP项目都离不开在线沟通，基于此因素，博纳网络本文继续分享APP聊天功能开发时怎样高效Radis协议格式。
Redis协议是以CR LF (CRLF)结尾，协议格式如下。
*参数个数CR LF
S第一个参数的字符串占用字节数CR LF
参数数据CR LF
....................
S第N个参数的字符串占用字节数字CR LF
参数数据CR LF
Redis命令“set name jeff”根据Redis协议可表示如下。
*3\r\n$3\nsete\n$4\rnname\r\n$4\r\njeff\r\n
根据公开的资料，陌陌是采用了和Redis协议相似的协议作为陌陌的通信协议。
根据Redis协议的格式，程序也很容易完整地获取个数据包的所有数据，APP开发爱好者如果需要开发私有协议，可以上面介绍的两种协议格式作为模板，打造属于自己的协议
由于移动互联网的弱网络性，经常会出现丢包的情况（即客户端收不到服务器发送的数据），对于推送、聊天这类应用来说，丢包后有下面两个问题需要处理。
·怎么确定客户端是否接收到消息7
·怎么确定需要重发哪些消息？
深圳APP开发公司下面先介绍基于队列的协议在解决上面两个问题上的缺点，APP开发公司现在介绍新式的协议是如何有效解决以上的两个问题
1．聊天功能基于队列的消息协议
传统的IM协议一般是基于队列的消息发送和反馈机制。假设服务器中要发送的消息队列如下。
服务器按顺序把消息队列中的消息依次发送给客户端，当客户端收到消息后给服务端发送“确认收到”的应答。如果过了一段时间服务器还没收到客户端的应答，就重发该条消息。服务器与客户端之间的消息交互过程如图9-10所示
。
APP开发聊天功能队列协议处理示意图9-10基于队列的服务器和App的消B交互过程
这种方式有下面两个问题：
·如果客户端已收到消息并且发送了“确认收到”的应答，但由于网络中断等原因造成服务器收不到应答，这样服务器就会重发该消息
导致客户端收到重复的消息。
·由于移动互联网的弱网络性，每条消息都需要应答的方式极其费时，服务器要维护每个消息的状态也容易出错。这种方式对网络的要求比较高，适用于基于网线、Wi-Fi等网络信号比较强的情况
2.APP开发聊天功能基于版本号的消息协议
服务器上消息按照如下的结构存储，每个消息有一个自增不重复的版本号，
服务器和App之间的消息交互，基于版本号的方式如图9-11所示。
APP开发聊天功能消息协议处理方法示意图9-11基于版奉号的服务器和-App之间的交互过程
在图9-11中，当服务器准备推送消息给App时，服务器向App发送“消息推送”消息，App收到这个信息向服务器返回“消息同步”消息（附上最后收到的消息版本号），服务器根据这个版本号，把大于该版本号的所有消息按照版本号依次推送给App。
假设在图9-11中．App收到消息(2.msg2)后网络中断了，等网络恢复后App向服务端发送“消息同步”信号（默认情况下App连上网络后发送这个信号到服务器同步消息）．附上最后收到的版本号2，服务器把版本号大于2的所有消息再次推送到App。
这种交互方式最大的好处是减少了交互的次数，而且依赖客户端维护消息版本号的方式保证服务器上的消息都能同步到客户端，不会丢失消息。据公开的资料，陌陌和微信采用了类似上面所描述的基于版本号的消息协议
聊天还有个常见的功能：发送图片、声音等文件。APP开发公司建议是在聊天中采用纯文本的方案发送这些数据，流程如下。
(1)假设用户a向用户b发送了张图片，发送前App先把该图片上传到文件服务器后得到个可访问的URL: http://file. test. com/l.Jpg.
(2) App聊天模块对接收到的下面几种文本类型的数据做不同的处理，如下所示。
发送图片声音等文件流程如图9-12所示。
APP聊天功能开发经验示意图9-12发送图片声音等文件流程
采用纯文本传输图片、声音等消息的好处如下：
（1）无论是App端或者是聊天后台，只处理又本的话都比较简单
（2）把文件放在文件服务中，可以统优化文件的性能（例如使用文件云存储或者CDN），不需要单独优化聊天相关的文件。好了，APP开发公司本文关于聊天功能开发时对于消息队列协议处理的流程与经验本文就分享到这里。谢谢关注，博纳网络编辑整理。
