最近刚完成有一个项目，主要是我方的Android客户端和厂商的多台硬件通讯，硬件这边有大牛和我对接。项目开始的时候为了便捷，我们约定全部采用UDP的形式通讯，在大部分功能开发调试完成之后，我们发现完全基于UDP协议有点行不通了。
UDP 遇到的问题：
1.网络不稳定，延迟高。
2.数据丢包
考虑到我们对于实时性，可靠性的要求较高。 经决定：换用UDP+TCP的双重保证机制。
完整的通讯流程如图1.1：
应用启动，以bind方式启动MessageService服务， 在MessageService服务中启动
TCP服务端，UDP收发端。
如图1.1所示：
1.此时UDP开始持续广播报文出去。
2.硬件客户端收到广播，获取发送方IP地址，以事先约定好的端口创建TCP套接字，从而和服务端建立连接。
3.发生某些异常导致不能完成通讯的情况处理：
a.客户端收到UDP广播，判断是否保持连接，如否，则重新建立TCP连接。
b.TCP确实连接，但客户端发送数据超时，则断开，重新连接。
4.直到客户端全部任务完成，自动断开。
一切看似美好，但我们遇到了粘包的问题。(关于粘包的解释，请自行百度。)
接下来，我们把大牛请到我们公司，一起研究怎么解决这个问题。
他提出了一种标准的解决办法：
A .客户端或者服务端每次发送的消息加一个有3个字节长度的头部，用16进制表示。
字节位1表示消息类型，字节位2和3 合起来表示消息长度len。一次读取len长度的消息。
再次从头读，再读取一个长度len2的消息，周而复始。
我们按照这种方式足足调试了半天，总之问题太多，最终我提出了另一种解决思路，算是取巧吧：
B.我建议把消息头去掉，加一个特殊符号的消息尾，后来我们为了降低出错概率，用了@@@。读取的时候，除非读到@@@，否则一直读取，读取到的内容，放在一个StringBuilder中，直到读到@@@，然后做一次处理，StringBuilder 清空。再以@@@ 分割成数组，这样即使意外读取了多条粘在一起的消息，也可以逐条处理。
代码改过后，调试确实可行，粘包问题解决了。
关于并发以及性能的考虑：
SendMsgThread：消息发送线程（UDP,TCP）
RecvThread：UDP消息接收线程
TCPClientAcceptThread：TCP接收线程
因为这三个线程是工作线程，且要长时间执行，所以直接在MessageService 的onBind()回调方法中启动。
当一个客户端以TCP的方式连到手机服务端，此时必须单独为其分配一个线程。如果是多个客户端的话，就要分配多个客户端。考虑到具体的业务场景，我们不知道具体是几个硬件设备会主动连接。所以我使用了ExecutorService 的 CachedThreadPool。
CachedThreadPool 相比 FixedThreadPool更适用于我的场景，因为我不知道具体的客户端数量，如果预先设置的线程数多了，则会浪费Android内存，如果设置少了，就会等待直到有可用线程，如此就影响了设备的连接速度。
最关键的是，我们的硬件设备可能会反复断开，重连，所以CachedThreadPool是最佳选择。
经过验证，一台3G内存的红米手机当TCP服务端,一次创建20个连接，同时发送百万次数据，手机内存占用增加大约不到10MB ，CPU占用40%-50%。粘包问题的取巧，毕竟只是为了解决一时只需，恰好满足当前场景，还是应当用RFC标准。
