商业级Android Socket编程实践

        最近刚完成有一个项目，主要是我方的Android客户端和厂商的多台硬件通讯，硬件这边有大牛和我对接。项目开始的时候为了便捷，我们约定全部采用UDP的形式通讯，在大部分功能开发调试完成之后，我们发现完全基于UDP协议有点行不通了。

UDP 遇到的问题：

1.网络不稳定，延迟高。

2.数据丢包

考虑到我们对于实时性，可靠性的要求较高。 经决定：换用UDP+TCP的双重保证机制。

完整的通讯流程如图1.1：

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 清空。再以@@@ 分割成数组，这样即使意外读取了多条粘在一起的消息，也可以逐条处理。

代码改过后，调试确实可行，粘包问题解决了。

1.2

关于并发以及性能的考虑：

SendMsgThread：消息发送线程（UDP,TCP）

RecvThread：UDP消息接收线程

TCPClientAcceptThread：TCP接收线程

因为这三个线程是工作线程，且要长时间执行，所以直接在MessageService 的onBind()回调方法中启动。

当一个客户端以TCP的方式连到手机服务端，此时必须单独为其分配一个线程。如果是多个客户端的话，就要分配多个客户端。考虑到具体的业务场景，我们不知道具体是几个硬件设备会主动连接。所以我使用了ExecutorService 的 CachedThreadPool。

CachedThreadPool 相比 FixedThreadPool更适用于我的场景，因为我不知道具体的客户端数量，如果预先设置的线程数多了，则会浪费Android内存，如果设置少了，就会等待直到有可用线程，如此就影响了设备的连接速度。 

最关键的是，我们的硬件设备可能会反复断开，重连，所以CachedThreadPool是最佳选择。

1.3

1.4

1.5

经过验证，一台3G内存的红米手机当TCP服务端,一次创建20个连接，同时发送百万次数据，手机内存占用增加大约不到10MB ，CPU占用40%-50%。粘包问题的取巧，毕竟只是为了解决一时只需，恰好满足当前场景，还是应当用RFC标准。