请选择 进入手机版 | 继续访问电脑版

默认
发表评论 25
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
引用:厚礼蟹不肉 发表于 2021-09-29 15:53
你们这个同步方法是只管好友有没有增量吗,对于之前的好友的个人信息是否修改不在这里返回。再用另外的接 ...

这里所谓的增量更新,内容就包括新增的好友信息以及有变动的好友信息,都是在启动时的同步好友接口返回的。
引用:林北lpepsi 发表于 2021-09-29 16:00
你们这个同步方法是只处理增量好友吗,无论之前的好友的个人信息是否修改都不在这个方法返回。然后再用另 ...

处理包括新增的好友信息以及有变动的好友信息,都是在这个接口返回的。
引用:小张 发表于 2021-10-09 20:36
我这边设计,基本都是文章中的一个套路(非一次性全量拉取,采用推拉方式)。但是,这些设计方式,对于单 ...

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

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

会话太活跃的话,保存时限可以定的更短一点,否则从体验上来说,也没什么意义,那么多消息,。。
签名: 《IM开发干货分享:万字长文,详解IM“消息“列表卡顿优化实践》http://www.52im.net/thread-3732-1-1.html
引用:椎锋陷陈 发表于 2021-10-11 10:00
「基于时间序的数据都天然带有冷热分明属性」,即用户通常只关心最新最近的数据,而很少会追溯到很久以前 ...

谢谢你的分析,可能我表述不清楚,并不是一下拉几万条,其实我这边是设计和文章的95%一样。只是目前,对于单个会话有可能短期内用户聊天太多,导致数据库查询较慢。也许我这边需要在sql或者对这些单个会话太多的想些策略,比如只给使用N条记录,超过就当成冷数据不给使用之类的。
签名: 第一次
引用:JackJiang 发表于 2021-10-11 10:20
会话太活跃的话,保存时限可以定的更短一点,否则从体验上来说,也没什么意义,那么多消息,。。

嗯,这个方向是可以。
签名: 第一次
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部