今天讲ListView并不打算说它的使用方法，更没有详细分析源码的想法，纯粹是一些吐槽性质的建议。对于绝大多数Android开发来说，你找工作是需要投简历的（当然你要是牛到了不需要投简历，那也不需要来我这小庙看文章了）。简历在过了HR的初步审核后就会来到负责技术面试的人这里了，肯定是技术负责人觉得这简历OK，才会让HR对候选人发起面试通知（也有可能是技术自己发通知），所简历是很重要的哦同学！尤其是在现在Android找工作困难的时候，简历都写不好，那找工作的第一关就通不过。
那么招人看简历的时候我最烦简历上写啥？老实说一时半会儿我很难讲清楚，但有2点让我记忆深刻，只要在简历上写了，我基本上就把你PASS掉了：一是写着擅长用AsyncTask实现异步网络数据获取，二是写着熟悉使用ListView并且懂得相关优化（其实就是个ViewHolder的复用）。只要你的简历上有这2条，那不好意思，我会认为是扣分项的。因为这2条都是很基础的东西，然而你却把它们放到了简历上，这就说明你认为这是你的个人能力中值得拿出来提的，那么我的想法是你的个人能力很可能并不强。
好了，说到这里，估计大家已经知道我会如何回答标题里的问题了。是的，在2019年末、2020即将到来这个时间点上，我认为一个合格的Android开发在95-99%的场景下是没有必要使用ListView的，当然老项目原有代码除外。实际上自从RecyclerView被推出来并且趋于稳定后，我在项目中的新开发就一直用RecyclerView而不再使用ListView了（GridView也是同样被RecyclerView替代的命运，与ListView是难兄难弟）。
之所以我说95-99%而没有说100%这么绝对，是因为确确实实存在一些场景，用ListView和RecyclerView不会有什么差别，那么对于一些比较顽固的、认为ListView用起来更简单的人来说，用ListView也无可厚非。
但估计还是有人会不服，凭啥我用ListView就不行？今天我无意去对这2个控件做具体的源码分析，就只说说为啥要尽可能的用RecyclerView吧。
首先，没有任何疑问的是，RecyclerView能100%实现ListView的各种功能，而反过来就不太容易了。比如动画效果，RecyclerView要比ListView丰富的多，实现起来也更容易，你费了九牛二虎之力实现的ListView动画，人家在RecyclerView里很简单就搞定了。分页加载和局部更新等，由于notifyItemRangeInserted、notifyItemRangeChanged等方法的存在使得RecyclerView天生就非常适合这些场景，而对于ListView来说，又是那句“自己实现”了。其他的诸如2个空间内部的缓存机制差异、性能差异（大部分情况下不是很明显）就不说了。
其次，我们要考虑的多一点，而不是仅仅局限于APP开发本身，也就是说要从产品层面来考虑问题。咳咳，众所周知，产品需求是不稳定的，同样一个页面，可能第一个版本是一个样子，下个版本就会有大变化，一旦你的实现方式比较生硬死板，那么下次改版就面临着比较大的工作量，而实现的灵活一些，就有更多的变通余地了。ListView如同它的名字一样，真的就只是一个纵向的、可滚动的View的集合，除此之外你不应该把它用成其他的样子（尽管费点力气也能实现），而RecyclerView人家的名字就主打的是循环回收，告诉你它的性能有保证，但绝对不是一个只用来替代ListView的东西。实际上RecyclerView几乎可以实现任何复杂的布局，大部分拥有滚动效果的布局都可以用一个RecyclerView实现，而不需要用ScrollView/NestedScrollView里面嵌套很多层级的各种控件，这样一来在整体的性能上会有很好的表现。同时，由于RecyclerView实现了NestedScrollingChild2接口，这就让它在处理嵌套滚动的问题时要容易很多，而ListView在遇到这种场景时回非常蛋疼。
也许你要问了，既然我如此推崇RecyclerView，那为何我说的是95-99%场景下不使用ListView，为什么不是100%呢？话还是不要说那么满嘛，还是有那么一些场景，用ListView也无伤大雅的。比如一些筛选小列表，仅仅是普通的展示效果，不涉及频繁的数据更新与动画，那么使用ListView跟RecyclerView没什么区别。另外，一些老项目原有的ListView如果你不是代码洁癖的话，确实也没必要去改动了。
好啦，以后再去找工作时，请你千万不要在简历上写你能熟练使用ListView了，减分项！如果你写着你熟悉ListView源码，了解其内部机制，那倒是一个不赖的加分项。
评论