引用：深海 发表于 2021-10-01 11:05
应该是进入一个会话发现不足以展现首屏数据就从服务端拉取

「不足以展现首屏数据」这个标准不太好衡量，因为不同客户端设备的屏幕尺寸/分辨率存在严重碎片化的问题，
如果需要根据不同客户端设备进行动态计算的话算法实现太过复杂，因此这里我猜测应该是使用了「Limit」值来进行判断。

即假设拉取历史消息的「Limit」值是20条，而客户端本地消息的数目仅为15条，达不到拉取历史消息的分页标准，
此时就会自动从服务端拉取不足的历史消息。

当然，最好还是实际在钉钉上验证一下是哪种实现。

引用：椎锋陷陈 发表于 2021-10-08 10:20
「万人群成员多级缓存」那里我们的App也采用了类似的实现，当时考虑的是，大量群成员频繁的@操作去调用群组 ...

不错的方案

引用：JackJiang 发表于 2021-02-05 11:48
哈哈哈，关键地方总是一笔带过。。。
你要知道，大厂里的大牛通常都不是全栈，写这种文章的一般是后端， ...

我每次受益匪浅,自己推断呀:这种应该是会话列表类
1.每个用户一个会话列表, 这里也可以优化,比如我有10万个会话怎么处理?
2.然后进入会话,你会发现里面很多优化机会,比如先拉20条,1~2屏,随着用户上拉,没有了,则尝试从服务拉,也就是不足,按需拉.

引用：椎锋陷陈 发表于 2021-10-08 10:40
「不足以展现首屏数据」这个标准不太好衡量，因为不同客户端设备的屏幕尺寸/分辨率存在严重碎片化的问题 ...

其实验证也简单,发一堆消息,然后断网观察

站长很辛苦,希望能加快审批帖子,辛苦了站长!

引用：Frank 发表于 2023-02-23 22:04
站长很辛苦,希望能加快审批帖子,辛苦了站长!

嗯嗯 互联网上坏人多，只能一个个审

站长,几年前就关注网站,向你致敬

引用：Frank 发表于 2023-02-25 21:46
站长,几年前就关注网站,向你致敬

引用：深海 发表于 2021-10-01 11:05
应该是进入一个会话发现不足以展现首屏数据就从服务端拉取

主要是进入会话,怎么发现,没有说,一笔带过.
应该讲清楚是靠什么策略知道的