Android文档显示:
RecyclerView小部件是一个更高级和灵活的版本
列表视图。这个小部件是用于显示大型数据集的容器
通过保持有限的数量,可以非常有效地滚动
的观点。当您有数据收集时,使用RecyclerView小部件
哪些元素在运行时根据用户操作或网络更改
事件
实际上,如果效率不重要,ListView可以做以上所有的事情,当我们使用RecyclerView取代ListView时,我们发现了许多问题:
没有用于列表项选择的onItemClickListener() -解决方案
没有分割线之间的列表项目-解决方案
没有内置重叠选择器,当您单击列表项-解决方案时,没有视觉反馈
没有addHeaderView的列表标题-解决方案
也许还有更多问题……
因此,当我们使用RecyclerView来代替ListView时,我们必须做很多额外的编码来达到与ListView相同的效果。
问题:
用RecyclerView完全取代ListView值得吗?
如果不是,那么在哪种情况下,我们应该更好地使用RecyclerView而不是ListView,反之亦然?
如果ListView适合你,就没有迁移的理由。
如果您正在编写一个新的UI,那么最好使用RecyclerView。
当你需要定制你的列表或你想要更好的动画时,RecyclerView是强大的。ListView中那些方便的方法给人们带来了很多麻烦,这就是为什么RecyclerView为他们提供了一个更灵活的解决方案。
The major change you need to make for migration is in your adapter. If you want to keep calling notifyDataSetChanged, you lose most of the animation & binding benefits. But if you can change your adapter to dispatch detailed notify events (added/removed/moved/updated), then you get much better animations and performance. These events let RecyclerView choose correct animations and it also helps it avoid unnecessary onBind calls. You'll get a huge benefit if your item views are complex. Also, going forward, there will be more components around RecyclerView.
直到最近我还在用ListView来做简单的列表。例如,如果我想显示一个简单的文本选项列表……
我基于“人为因素”的决定,如果性能不重要的话,用更少的代码创建一个简单的ListView会更好。我经常想起大学里的一位教授,他喜欢说:“我的老师,伟大的Niclaus Wirth, Pascal的发明者,曾经说过,如果一个程序的代码超过50行,那么它肯定是错误的……”
但是,说服我停止使用ListView的原因是,它最近与RelativeLayout一起被移到了Android Studio设计工具的“Legacy”类别中。
我认为这是“弃用”的“软”形式。如果它真的被弃用了,并且所有认真的开发人员都将他们的代码转移到RecyclerView,那就太有破坏性了。
此外,ListView的介绍在顶部警告说,RecyclerView是一个更好的选择:“对于一个更现代、更灵活、更高效的显示列表的方法,使用RecyclerView。”
https://developer.android.com/reference/android/widget/ListView
同样,ListView指南仍然在谈论游标加载器,但是getSupportCursorLoader()本身在API 28中已经被弃用。
https://developer.android.com/guide/topics/ui/layout/listview
Android Studio的最新增强:
文件->新建->片段->片段(列表)
这给了我们一个完全工作的RecylerView填充基本文本。这消除了我使用ListView的最后一个真正原因,因为现在设置一个基本的RecylerView非常容易。
总之,我根本不打算在新的开发中使用ListView,因为标记它有“遗留”是弃用它的一步之遥。