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

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

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

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

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

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

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

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

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

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

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

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

不错的方案

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

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

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

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

「万人群成员多级缓存」那里我们的App也采用了类似的实现，当时考虑的是，大量群成员频繁的@操作去调用群组接口获取数据,
一方面会增加服务端的请求压力，另一方面输入@后弹出群成员列表的动作也会因网络操作延迟，因此在客户端也实现了一层缓存，
记录了群组资料的数据。

但是增加客户端缓存又可能造成群成员列表更新不及时的问题，因此我们还增加了一个「最后更新时间」的记录值，
这个值会在每次有群成员列表更新的动作(如打开App时同步群组、查看群资料、群组更新主动通知)时更新。

当触发@操作时，会去检查这个最后更新时间是否超过限定值，如果超过就需要调用群组接口获取数据并更新本地缓存，
如果未超过就直接使用本地缓存，通过这样平衡服务端请求压力与数据更新不及时的问题。

自high较多，就聊天机器人功能，给它发送打卡，它回复好的马上去打卡，简直是个沙雕设计 ，Apple store评分2.4，从哪里得出受到了用户广泛好评的结论

引用：手写的从前 发表于 2021-02-05 10:10
《最近的消息通过同步协议推送到达客户端本地。而历史的消息，服务端不曾推送，客户端本地没有入库。在用户 ...

应该是进入一个会话发现不足以展现首屏数据就从服务端拉取

学习了

引用：手写的从前 发表于 2021-02-05 10:10
《最近的消息通过同步协议推送到达客户端本地。而历史的消息，服务端不曾推送，客户端本地没有入库。在用户 ...

哈哈哈，关键地方总是一笔带过。。。
你要知道，大厂里的大牛通常都不是全栈，写这种文章的一般是后端，所以，前端到底怎么实现的，他应该是不太清楚的，哈哈

《最近的消息通过同步协议推送到达客户端本地。而历史的消息，服务端不曾推送，客户端本地没有入库。在用户进入会话时，如果客户端发现本地消息不足，自动从服务端拉取不足的历史消息。采用这种推拉结合的协议，保证了消息不管多么久远，都可以毫无遗漏的从服务端同步下来。》，这里的《如果客户端发现本地消息不足》客户端是怎么发现本地消息不足的啊

引用：Monkey 发表于 2020-07-28 20:55
干货有些少

钉钉几乎不做技术分享，这样的分享对于钉钉来说已经很少见了

干货有些少

引用：JackJiang 发表于 2020-04-20 10:05
没有。

哈哈,目前想到的方案就是离线状态下缓存有新消息的会话id..

引用：Sudo 发表于 2020-04-19 23:53
看了站里的钉钉的文章,他们是从写扩散优化成了读扩散了.

请问楼主有钉钉怎么给客户端提示哪些会话有新 ...

没有。