引用：某非著名程序 发表于 2021-02-05 09:24
文中第5条优化2一般一次性拉取，主流的的移动端IM（比如微信、手Q等）通常都是以“优化方案2”为主。然后第 ...

作者前后的描述其实并不矛盾，因为关注的重点不同。

前者主要涉及的是读扩散和写扩散的问题，
所谓读扩散，假设用户有500个好友，那就要执行500个HTTP请求，除了作者说的那些问题，还有
无效请求的问题，即某些好友并没有新增的离线消息。
所谓写扩散，就是有一个额外的「收件箱」，用于存储所有好友的离线消息，每次都要额外写入
一次，用户拉取所有离线消息只需要从这个收件箱拉取即可，拉取之后再在本地进行分组，可以
大大减少请求次数。

后者是在前者的基础上，考虑了离线消息比较多的情况，造成数据量很大，请求速度慢，本地频繁
存储后刷新引起卡顿，因此改成了分页拉取，减少每次拉取和要处理的数据量，边拉取边处理。

引用：某非著名程序 发表于 2021-02-05 09:24
文中第5条优化2一般一次性拉取，主流的的移动端IM（比如微信、手Q等）通常都是以“优化方案2”为主。然后第 ...

作者前后的描述其实并不矛盾，因为关注的重点不同。

前者主要涉及的是读扩散和写扩散的问题，
所谓读扩散，假设用户有500个好友，那就要执行500个HTTP请求，除了作者说的那些问题，还有
无效请求的问题，即某些好友并没有新增的离线消息。
所谓写扩散，就是有一个额外的「收件箱」，用于存储所有好友的离线消息，每次都要额外写入
一次，用户拉取所有离线消息只需要从这个收件箱拉取即可，拉取之后再在本地进行分组，可以
大大减少请求次数。

后者是在前者的基础上，考虑了离线消息比较多的情况，造成数据量很大，请求速度慢，本地频繁
存储后刷新引起卡顿，因此改成了分页拉取，减少每次拉取和要处理的数据量，边拉取边处理。