求教IM客户端，插入本地sqlite时如何高效进行聊天消息去重？

收到新消息因为不保证是否重复每条都要从本地数据库查询是否重复再进行插入,在线消息还好但是离线消息可能一次收到上千条，循环遍历的话效率非常的低。现在的解决方案是直接拉出所有的本地消息id放入一个Set里进行去重，目前还好但是以后本地数据库到达一个量级这个Set的资源占用肯定是不妥的。想问下大家都是怎么做客户端消息去重的？

你这种方式，自已硬编码人肉去重太不优雅了。

首页明确一点，你一个正常用户，收到的消息几秒种能收到一条，就已经很繁忙，试想谁的消息有这么忙，那手机不是要滴滴个不停了。

其实，你在插入的时候通过数据库的事务，把主键、唯一id什么的都定义好，一般来说性能都不会太差。

难道，你们的app有什么特殊的地方？

引用：JackJiang 发表于 2019-04-03 15:01
你这种方式，自已硬编码人肉去重太不优雅了。

首页明确一点，你一个正常用户，收到的消息几秒种能收到一 ...

哈哈 确实有点特殊因为我们这个app群里是有机器人24小时不间断发消息的。普通用户一上线极有可能一次收到几千条离线消息。我也有想过用唯一主键去重但是重复的消息无法拿到id，这样就不能回ask下次上线这条消息依旧会下发下来。。。

引用：v587zyd 发表于 2019-04-03 15:35
哈哈 确实有点特殊因为我们这个app群里是有机器人24小时不间断发消息的。普通用户一上线极有可能一次收到 ...

其实也没多大文章可以做，像qq一样，如果下次上线时消息太多的话，列表里的消息其实也是一点点刷新出来。只是处理时的进度条什么的做的体验好一点，用户也能接受，必竟这么大量的消息，再傻逼的客户也能想的到很难处理的。

你可以自已试一下，模拟个几千条消息，自已先做个压力测试，找出你算法里的耗时代码，逐个地方优化，理论上性能没有想象的差。

离线消息去重优化建议

可以在消息时间上做文章
    a. 取离线消息的最小时间 mintime  和 最大时间 maxtime；
    b. 从数据库中拉取  mintime <= time <= maxtime 的消息ID做 set
    c. 利用 set 去重

mintime 和 maxtime 计算：
   mintime 和 maxtime 可以由服务器下发，也可以收完所有离线消息后自己计算

容错处理：
   计算 mintime 的时候，预防 mintime 出错，例如服务器出 bug 导致 mintime == 1970 或者 mintime == 0