FMouse优化之路——复用socket，固定数据包长度

在第一个版本中，FMouse 表现不尽人意，客户端每次通讯时都会重新创建一个套接字，在Android 移动端的表现是，在连续操作一段时间后，会出现blockqueue已满，这里移动端开了线程池，检测到触碰移动事件的时候，开线程将数据传送给服务器。由于移动端作为虚拟鼠标，触碰移动事件过于平凡，秒级5~10条数据，数据格式使用的JSON。每发送一个数据就会开启新socket，socket断开也需要时间。导致生成的大量数据没法及时发送出去。积压在线程池等待队列中，最终发生异常。

第一个优化版本主要优化的是通讯方式方面的优化。

优化方式

1.将原有的每个数据包 一个线程 一个新的socket 改变为 保持全局的单长连接 socket，实现socket的复用

2.原本的数据格式为json格式，平均60个字符长度的数据包，转换为二进制数组表示，压缩到30个字节的长度。传输效率提升9倍。由于采用了单长连接socket作为通讯方式，这里约定，没收到30个字节 服务器就认为客户端已经完成了通讯。同时设置timeout时间为300毫秒。在300毫秒内，未收到客户端传输数据，则断开socket，等待下一次的连接。

期望：在客户端的每一次 手势操作：如指尖down 到up 这个手势输入，使用同一个socket与服务器进行通讯，利用的是移动端的触控采集频率要低于300毫秒每次。调节timeout 可是实现，在连续操作的情况下复用socket。

结果：使用电脑模拟客户端发送数据时，秒级 百条数据，稳定运行。在客户端上实际调试的时候，出现了，卡顿。优化后的效果甚至不如一个数据包 一个线程 一个socket时的流程。

此处猜想问题原因：使用pc模拟请求时，并未出现这种状况。客户端与pc模拟之间的区别在于，一个是实际的手势采集，一个是模拟数据，一个走了完成的网络链路，一个是本地回调。此处推测最大的可能性是自定义的通讯 协议有问题。

还不知道FMouse是什么：FMouse是啥子？