本人在业余时间开发了一款 游戏 + 社区 app
由于此项目的核心是 游戏 和 社交 ，所以采用了 长连接实现
后端采用 Tio , 项目地址为 ： https://gitee.com/tywo45/t-io
android 采用 netty ,项目地址为 https://github.com/netty/netty
tio 是一款国人开发的优秀 aio 网络编程框架，上手简单，易扩展
netty 是 jboss 开源的一款框架，许多优秀的项目都是基于此框架实现例如 dubbo、RocketMQ 等
下面我说一下，在开发过程中遇到的问题
因为 TCP 是一个流的协议、流并没有界限，TCP作为传输层协议并不不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行数据包的划分，所以在业务上认为是一个完整的包，可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，所以就会造成粘包、断包等
tio 采用 ByteBuffer 做好了解码工作，然而 netty 却并不是这么智能，所以我会着重说明一下 netty 内置的四种解码器
LineBasedFrameDecoder ： 换行解码器 ,发送的消息以回车换行符作为消息结束的标识
DelimiterBasedFrameDecoder : 特殊符号解码器，以指定消息结束的分隔符，它可以自动完成以分隔符作为码流结束标识的消息的解码。回车换行解码器实际上是一种特殊的DelimiterBasedFrameDecoder解码器
FixedLengthFrameDecoder ：固定长度解码器，它能够按照指定的长度对消息进行自动解码。对于定长消息，如果消息实际长度小于定长，则往往会进行补位操作，它在一定程度上导致了空间和资源的浪费。但是它的优点也是非常明显的，编解码比较简单
LengthFieldBasedFrameDecoder ：大多数的协议（私有或者公有），协议头中会携带长度字段，用于标识消息体或者整包消息的长度，例如 Http header 中的 Content-Length
综合考虑 ，我决定使用 LengthFieldBasedFrameDecoder 解码器
编码器代码如下
对此 ，粘包，断包的问题就解决了
初次写博客 ，写的不好，请见谅