Android RecyclerView替换完整列表时Stable IDs的性能选择问题

结论：你提到的这套方案性能反而更差，这类全量替换列表的场景更推荐开启Stable ID后再调用notifyDataSetChanged() #

具体原因如下：

• 当你调用setHasStableIds(false)之后再触发notifyDataSetChanged()，RecyclerView会默认所有条目都已失效，当前屏幕内所有可见的ViewHolder都会执行完整的重绑定、重绘流程，哪怕新旧列表里存在完全相同的条目，也会重复走一遍渲染逻辑，完全浪费算力。
• 只要你开启Stable ID（调用setHasStableIds(true)，同时重写适配器的getItemId(int position)方法，给每个条目返回唯一且固定的ID即可，比如电影榜单场景直接返回对应电影的唯一ID就行），哪怕调用的是全量更新的notifyDataSetChanged()，RecyclerView也会自动通过ID比对新旧列表的同个条目，内容没有变化的条目不会触发重绑定，仅会做必要的布局调整，整体开销远低于关闭Stable ID的写法。
• 官方推荐优先用notifyItemChanged()这类增量API，是针对可以直接拿到列表变化内容的场景，你这种全量替换列表的场景如果不想额外做差异计算，开Stable ID加全量更新已经是性价比很高的选择。

如果想要进一步优化性能，也可以用Android官方提供的DiffUtil工具类，只要写少量逻辑配置差异规则，工具会自动计算两个全量列表的差异、生成对应的增量更新操作，性能会比直接调用notifyDataSetChanged()更好。

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