我们的App在进行技术演进的时候，是把用户的相关信息从消息体中剥离出来的。
也就是本地数据库会分离出两张表，一张Message表，一张User表。
Message表只会保留收发对象的用户ID，User表保留所有接触过的用户信息(单聊对象、群成员等)。

查询数据时两个表进行联表查询，展示为MessageVO(视图对象，包含消息与必要的用户信息)，
发送消息同样只会携带收发对象的用户ID。

我们在每次启动时必定会执行几项工作：同步离线消息/同步会话/同步好友/同步群组，
本地都会保留一个最后更新的时间戳，以便下次请求时进行增量更新而非全量更新，减少请求数据量。
同步好友操作时就会对好友的用户信息进行更新。
另外就是在收取消息时，发现本地User表没有相关信息时，就会主动请求接口更新用户信息。

引用：厚礼蟹不肉 发表于 2021-09-28 23:27
你好我想请教一下你们每次登录启动的时候，同步好友的时候，是会有一张好友表吗。我现在是每次登录的同时 ...

我们有一张「联系人」表，应该与你们的「好友」表性质也类似。你们这种方式属于全量更新，而我们的方式属于增量更新。
具体做法就是本地会保留一个最后更新的时间戳，每次同步好友信息时都会携带这个时间戳。
后端会返回给我们在这个时间戳之后的有更新的好友信息，而不是所有的好友信息，并返回新的时间戳。
首次没有同步过好友信息时，时间戳传0，这种情况才是返回所有的好友信息。

引用：JackJiang 发表于 2021-09-29 12:27
你的做法是，服务端在更新任何一个用户的任何信息时，同时更新它的时间戳对吧

刚去回顾了旧项目的代码，传递的是版本号而不是时间戳，不过原理是一样的。
服务端负责维护这个版本号，客户端只是保存下来并在同步好友时原样传递。
服务端对该版本号的更新时机，应该是在客户端请求同步好友接口时。
服务端返回了增量的好友信息，更新了版本号，然后随增量的好友信息一起返回给客户端。

引用：厚礼蟹不肉 发表于 2021-09-29 15:53
你们这个同步方法是只管好友有没有增量吗，对于之前的好友的个人信息是否修改不在这里返回。再用另外的接 ...

这里所谓的增量更新，内容就包括新增的好友信息以及有变动的好友信息，都是在启动时的同步好友接口返回的。

引用：林北lpepsi 发表于 2021-09-29 16:00
你们这个同步方法是只处理增量好友吗，无论之前的好友的个人信息是否修改都不在这个方法返回。然后再用另 ...

处理包括新增的好友信息以及有变动的好友信息，都是在这个接口返回的。

引用：小张 发表于 2021-10-09 20:36
我这边设计，基本都是文章中的一个套路（非一次性全量拉取，采用推拉方式）。但是，这些设计方式，对于单 ...

「基于时间序的数据都天然带有冷热分明属性」，即用户通常只关心最新最近的数据，而很少会追溯到很久以前的数据。
我们App最初的架构是不支持多端同步和消息漫游的，对于离线消息的存储也是有一定的时间限制的，超过这个时间没有拉取的就不保留了，
这样做也是基于聊天数据冷热分明属性的考虑。

至于针对你这种情况的做法，Jack Jiang大佬已经说了，「只尝试加载最近多少条，只在用户下拉加载更新时，再去拉取一页」，
我再补充一点，每个会话的未读消息的数目你可以另外单独推送，这样，在用户的角度上能得知正确的消息未读数，感觉是消息已经全部拉下来了，
在使用上由于进行了分页加载，避免了一下子同步几万条消息形成瓶颈从而造成卡顿甚至ANR，用户体验也就更友好。