你对MobileIMSDK这一块的代码理解的很到位，赞一个！但就事论事来说，MobileIMSDK的有些东西是经过权衡后决定的。

抛开MobileIMSDK现在的实现方案不说，你可以假设一下，如果这些逻辑你来做，并把它们都放到服务端来实现的话，那会是什么样的？

我们随便来展开一下便可知：

1）假设按照每秒4万吞吐的满载情况来计算，最理想的情况下，重传列表每秒钟将稳定维护在大约20万个；
2）由此导致，每个C2C的消息包的去重判断、超时判断，都将在这以几十万消息中进行，性能损耗会是非常明显，尤其IM这种讲究高吞吐、高性能的应用；
3）毫无疑问，理想情况下，这个QoS列表，每秒都在高效地进和出，大量小对象都在不断地进行分配和释放操作，稍有不健壮的代码让服务器抽个风，几秒内的消息堆积都是惊人的，那么以IM这种高吞吐、高并发场景，很容易就让服务器发生雪崩（连锁反应啊）；
4）还有一个比较严重的问题，因为这个QoS由服务端保证，那么万一服务端崩溃或意外情况，导致停机、掉电，这消息马上就丢了，影响的是大量用户的QoS消息，你可以说我再做持久化，当然这肯定是可以做，但你的代码只会越来越复杂。跟QoS只在客户端做相比，即使发生意外，影响的也只是这个用户自已，再说一个用户频繁聊天的话，根据经验，一个人5秒能完成一条消息的发送就很快了（你可以拉一个秒表，以真实情况来手机上打字、发一条消息试试看）。

综上所述：MobileIMSDK的设计原则（尤其是服务端），就是为了保持极简的逻辑，因为IM核心回归到本质就是消息从这头到达那头，而MobileIMSDK的服务端始终给自已的定位就是一个消息通道，各种复杂的逻辑能在客户端做的（或许并非完美，但QQ的设计原则也同样是允许万有一失，这就是取舍）绝不放到服务端。

总之：服务端一旦变的复杂，它的扩展性一定会是噩梦。一个胖子做什么事都是笨拙的，而一个瘦子作什么事都更敏捷，就是这个道理。同样的设计理念，你回头看看redis为何能始终保持轻量级和高性能，也是这个道理。

你对MobileIMSDK这一块的代码理解的很到位，赞一个！但就事论事来说，MobileIMSDK的有些东西是经过权衡后决定的。

抛开MobileIMSDK现在的实现方案不说，你可以假设一下，如果这些逻辑你来做，并把它们都放到服务端来实现的话，那会是什么样的？

我们随便来展开一下便可知：

1）假设按照每秒4万吞吐的满载情况来计算，最理想的情况下，重传列表每秒钟将稳定维护在大约20万个；
2）由此导致，每个C2C的消息包的去重判断、超时判断，都将在这以几十万消息中进行，性能损耗会是非常明显，尤其IM这种讲究高吞吐、高性能的应用；
3）毫无疑问，理想情况下，这个QoS列表，每秒都在高效地进和出，大量小对象都在不断地进行分配和释放操作，稍有不健壮的代码让服务器抽个风，几秒内的消息堆积都是惊人的，那么以IM这种高吞吐、高并发场景，很容易就让服务器发生雪崩（连锁反应啊）；
4）还有一个比较严重的问题，因为这个QoS由服务端保证，那么万一服务端崩溃或意外情况，导致停机、掉电，这消息马上就丢了，影响的是大量用户的QoS消息，你可以说我再做持久化，当然这肯定是可以做，但你的代码只会越来越复杂。跟QoS只在客户端做相比，即使发生意外，影响的也只是这个用户自已，再说一个用户频繁聊天的话，根据经验，一个人5秒能完成一条消息的发送就很快了（你可以拉一个秒表，以真实情况来手机上打字、发一条消息试试看）。

综上所述：MobileIMSDK的设计原则（尤其是服务端），就是为了保持极简的逻辑，因为IM核心回归到本质就是消息从这头到达那头，而MobileIMSDK的服务端始终给自已的定位就是一个消息通道，各种复杂的逻辑能在客户端做的（或许并非完美，但QQ的设计原则也同样是允许万有一失，这就是取舍）绝不放到服务端。

总之：服务端一旦变的复杂，它的扩展性一定会是噩梦。一个胖子做什么事都是笨拙的，而一个瘦子作什么事都更敏捷，就是这个道理。同样的设计理念，你回头看看redis为何能始终保持轻量级和高性能，也是这个道理。