引用：天然呆 发表于 2018-03-02 11:38
这样正常吗？

网络还可以，不能算差。

你把服务端日志都清空，然后整一个清爽点的log出来对照着网络质量分析分析

引用：天然呆 发表于 2018-03-02 11:00
这两个问题先不说，丢包时什么问题

你的log太乱了，整理个清爽一点的抓出来分析一下。

另外，建议你评估一下你的服务端与手机间的网络质量：比如你可以用ping工具在服务器上持续ping这台手机（下载地址：http://www.52im.net/thread-610-1-1.html），然后根据网络状况来从理论上评判丢包是否正常，然后再来看看为何框架中丢包的容错处理逻辑是否合理。

网络通信程序，一定是对着网络质量来分析才有意义：

引用：JackJiang 发表于 2018-03-02 10:54
你这log相当乱，看的头晕。

但我有几个建议给你。。。

这两个问题先不说，丢包时什么问题

你这log相当乱，看的头晕。

但我有几个建议给你。。。

1）同一个群的消息乱序的问题：你可以自已实现一个消费者生产者模型（简单说就是写个简化的队列就好了），这样就能保证顺序了。否则，通常的服务端框架，为了高性能，无论从网络发送、还是线程调度，肯定都是异步、多线程实现的，这是跟客户端编程的最大差别。所以，你在你自已写个简单的队列，相当于在应用层为系统的消息分发排好序了，而不是扔给它让他们自已异步群魔乱舞，系统以为只要高效地发出去就好了。

2）我有看到你发送消息时，不在线的人你也尝试发送：虽然这不会有问题，因为对方不在线框架会自动交给离线处于代码。但这会让你的log看起来比较冗余，不利于调试（这也是为什么你的log看起来这么乱的原因），你完全可以在发送之前就判断一下对方在不在线——你自已决定是实时发送、还是马上就交给离线处理代码，判断对方在不在线的API，你看看OnlineProcessor的API接口就能用了。