聊天消息排序异常：Lambda比较被置灰，替换Comparator.comparing后失效

问题场景 #

对聊天消息集合chatMessages排序时，原Lambda比较逻辑被编辑器提示替换为Comparator.comparing，但替换后出现异常：接收方消息固定显示，发送方消息持续停在列表上方。改用List自带的sort方法后恢复正常，同时需要优化Adapter的更新策略，减少全量刷新的使用。

原排序代码 #

最初使用Collections.sort结合Lambda实现排序：

Collections.sort(chatMessages,
                (obj1, obj2) -> obj1.dateObject.compareTo(obj2.dateObject));
if(count == 0) {
    chatAdapter.notifyDataSetChanged();
} else {
}

修复后的排序实现 #

改用List自身的sort方法搭配Comparator.comparing，代码如下，可正常实现消息按时间排序：

// 可正常工作的排序代码
chatMessages.sort(Comparator.comparing(obj -> obj.dateObject));
if(count == 0) {
    chatAdapter.notifyDataSetChanged();
}

注：虽然Collections.sort与List.sort核心排序逻辑一致，但List.sort是集合自身的方法，实现上更适配当前集合的类型，能避免一些潜在的集合操作问题。

Adapter更新优化：精准替换全量刷新 #

notifyDataSetChanged()会强制刷新整个列表，性能开销较大，应仅作为最后手段使用。针对聊天场景，推荐使用更精准的更新方法：

• 新增单条消息：调用notifyItemInserted(position)，传入消息最终在列表中的位置
• 修改单条消息内容：调用notifyItemChanged(position)
• 删除单条消息：调用notifyItemRemoved(position)
• 批量新增/修改消息：使用notifyItemRangeInserted(startPosition, itemCount)或notifyItemRangeChanged(startPosition, itemCount)

如果排序后只是调整了已有消息的顺序，还可以结合DiffUtil计算数据差异后再做精准刷新，进一步提升性能。

内容的提问来源于stack exchange，提问作者Sunny Dowari