求助关于IM中离线消息拉取时本地存储的msgID疑问

[img]blob:http://www.52im.net/8bcc482c-37ff-41a8-875a-dd75ad13b56c[/img]我看了下你的离线消息拉取原理。。我发现app本地的msgID是递增的。。比如100条离线消息，msgID =1 ~ 100,最新的消息msgID越大，假如我们设定size=20 ,msgID=0 ，那则就加载  msgID=1 ~ msgID=20 , 此时app本地保存的msgID最大就是msgID=20,然后第二次就从 msgID=21~msgID=40, 这样轮询没有错，但是我们往往进入群聊则先加载 最后的那么20条（msgID=100 ~ msgID =81）,第二次则加载（80~61），此时app本地保存的最大的msgID=61 ，假若此时群中有人发言，你当前打开的群收到了这消息（msgID=101）,那app本地保存的msgID不是马上变更成了msgID=101了？    那之前还有 （60~1）这段的消息还是未读的？

注意过微信或者手机QQ聊天界面里的这个“6条新消息”提示功能吗？
这个6条消息就相当于你说的“60~1”这60条未读消息的情况。
（我聊天界面里没有截到图，所以用的是公告号界面的，原理是一样的）


你可以在手机qq或微信上测试体会一下这个功能，你平时尤其在群聊的时候，很久没打开的时候，再打开聊天界面时，就会出现这种情况，你点击这个“xx条新消息”按钮时，它会自动将你说的这“60-1”条消息加载进来给你们。不信你试着体验体验，应该能解决你的疑问。

例如 你上次进这个页面最后的msgid=10 , 这次你进来共有6条新的（即11，12，13，14，15，16【最新的就是16】）。。一进来是就加载了msgid=16 , app本地保存最大的msgID=16了吧？ 在不点“6条的新消息”按钮的前提下，我下拉想加载“15，14，13，12，11”，  但是我从你的“拉取离线消息一文”中，你是判断app中msgID最大的ID是什么， 然后提交给服务器查   (离线消息ID)> msgID 这样得出结果， 但是 msgID=16已经是最大了， 而未读的却比16还小  明显用  (离线消息ID)> msgID 是查不出结果呀？难道我理解错误了吗？

引用：JackJiang 发表于 2018-09-11 21:42
注意过微信或者手机QQ聊天界面里的这个“6条新消息”提示功能吗？
这个6条消息就相当于你说的“60~1”这60 ...

例如 你上次进这个页面最后的msgid=10 , 这次你进来共有6条新的（即11，12，13，14，15，16【最新的就是16】）。。一进来是就加载了msgid=16 , app本地保存最大的msgID=16了吧？ 在不点“6条的新消息”按钮的前提下，我下拉想加载“15，14，13，12，11”，  但是我从你的“拉取离线消息一文”中，你是判断app中msgID最大的ID是什么， 然后提交给服务器查   (离线消息ID)> msgID 这样得出结果， 但是 msgID=16已经是最大了， 而未读的却比16还小  明显用  (离线消息ID)> msgID 是查不出结果呀？难道我理解错误了吗？

引用：ayuan9900 发表于 2018-09-12 10:57
例如 你上次进这个页面最后的msgid=10 , 这次你进来共有6条新的（即11，12，13，14，15，16【最新的就是1 ...

其实你不用纠结这些，真要像你说的这么干，客户端和服务端的逻辑就太复杂了。

比较实际的思路就是，实际上这些数据已经按最大msgId拉取到你的本地Sqllite中存储好了，提示你只是告诉你还未读，但数据早就在本地准备好了，只是UI界面对应的数据模型以及UI显示技巧而已（主要是为了提升体验）。

不管什么功能，如果涉及到的逻辑太复杂，那么一定会选择简单的方案，即使不是最优解，因为互联网分布式的情况下。简单的逻辑已经能让技术实现变的很复杂了，何况本身就很复杂的逻辑，那从整个架构来说，以后就是噩梦。

有的时候考虑问题，应该跳出当前思维，从上帝视解来看它，就能找到更实际可行的方案。