在登录之后会发生两件事:
- 执行 query,得到 conversaion 列表
- 服务端主动推送未读数过来
这两个事情的顺序是不能确定的。
如果服务端的未读数通知先到,那么 SDK 会缓存这个 conversation(这时候 unreadMessageCont 是 2),然后 query 结果到了,SDK 用更新缓存的 conversation。此时一切都符合预期(unreadMessageCont 还是 2)。
如果 query 的结果先到,那么这时候打印 conversations[0].unreadMessagesCount 会是 0(因为 query 结果是不含 unread 数的),然后服务端的未读数通知到了,此时 SDK 会将这个 conversation 的 unreadMessageCont 更新为 2。
不管顺序如何,最终我们都会收到一次 UNREAD_MESSAGE_COUNT_CHANGE 事件,并且 conversation 的 unreadMessageCont 值为 2。这是 SDK 能保证的,因此如果你用的是现代的前端框架,并且在 UNREAD_MESSAGE_COUNT_CHANGE 时更新了 View,那么最终的显示结果一定是对的。
至于「控制台显示unreadMessagesCount的值为2,但是conversations[0].unreadMessagesCount取到的值为0」,是因为遇到了后一种情况,然后前面打印的 conversation 实例,实例的 unreadMessagesCount 属性是在你展开的时候计算得到的,所以会是最终的值 2。conversations[0].unreadMessagesCount 的值是当时瞬间的值,所以是 0。