RecyclerView 源码启示录

当列表数据变更时，调用 notifyDataSetChanged() 是最省事的。无需关心变更的细节，一股脑统统刷一遍就完事了。但这样做也是最昂贵的。读完这一篇源码走查就知道为啥它这么昂贵了。

上一篇介绍了手指滑动过程中，列表的滚动是如何实现的。那脱手之后，列表仍会滚动一段距离，即 fling，这又是如何实现的？走查源码一探究竟。

RecyclerView 是一个展示列表的控件，其中的子控件可以被滚动。这是怎么实现的？以走查源码的方式一探究竟。 切入点：触摸事件 阅读源码时，如何在浩瀚的源码中选择合适的切入点很重要，选好了能少走

引子 上一篇用“动画”方案实现了弹幕效果，但该方案的性能有待改善，这一篇用“自定义LayoutManager”重新实现一下。

该系列介绍如何高效地量化绘制性能，上两篇的 4 种优化手段已经把表项加载速度减半，这一篇在此基础上继续把加载时间打对折。

在什么情况下 RecyclerView 的缓存机制会失效？即本该被回收的表项没能回收，无法回收就无法复用，这对列表的性能会有多大影响？从一个实例出发，探究下答案。 列表表项是一个 TextView，它在做水平位移动画。 运行 Demo，滑动列表，发现只有onFailedToRe…

上一篇介绍了如何高效地量化绘制性能，并对 RecyclerView 加载速度做了 2 次优化，使得表项加载耗时从 370 ms 缩减到 288 ms。这一篇继续介绍后续的 2 种优化手段

RecyclerView 出场率很高。它的加载性能影响着用户体检。本篇分享一次完整的 RecyclerView 性能优化过程：从用工具定位问题，再不断尝试各种优化方案，最终达成 50% 的性能优化。

缓存是 RecyclerView 时间性能优越的重要原因。缓存池是所有缓存中速度最慢的。这一篇从源码出发，探究哪些情况下表项会被缓存到缓存池。

又一道关于 RecyclerView 面试题：“RecyclerView 滚动时，新表项是如何一个个被填充进来的？旧表项是如何一个个被回收的？”这篇以走读源码的方式，解答这个问题。

RecyclerView 表项动画的属性值是怎么获取的，又存储在哪里？这一篇继续通过 走查源码 的方式解答这个疑问。

RecyclerView 缓存之一的 scrap 结构中存的是什么？为什么要 scrap 缓存？pre-layout 及 post-layout 过程中 scrap 缓存内容如何变化？读源码来解答。

RecyclerView 表项动画是怎么实现的？RecyclerView 在做表项动画时会布局几次？pre-layout 是什么意思？一起来读一读源码，对这些问题追根溯源。

如何让列表加载分页数据过程无感知。一种实现方案是预加载，即在一页数据还未看完时就请求下一页数据。这一篇介绍一个超简单的预加载实现方案。

每次数据变化都全量刷新整个列表是很奢侈的，不仅整个列表会闪烁一下，而且所有可见表项都会重新绑定一遍数据。这一篇对 DiffUtil 进行二次封装以让其更易于使用。

上篇介绍了一种新的监听 RecyclerView 表项点击事件的方法。实现了将点击事件和RecyclerView.Adapter解耦。这一篇介绍如何监听 RecyclerView 表项子控件点击事件。

App 界面愈发复杂，元素越来越多，将不同类型的元素组织成 RecyclerView 就可以超越屏幕的限制。常用的RecyclerView在使用时有诸多痛点。这一篇尝试让扩展列表数据类型变得简单。

RecyclerView 内存性能优越，这得益于它独特的缓存机制。第一篇中遗留的一个问题还没有解决：复用表项时优先级最高的scrap view是用来干嘛的？这篇文章试着通过阅读源码解答这个问题。

RecyclerView 性能优越，得益于它独特的缓存机制，上两篇分析了其缓存机制会回收哪些表项，及如何从缓存中获取表项。本篇在此基础上继续走读源码，分析回收表项的存储形式。

RecyclerView 缓存机制是面试中的常客。上一篇文章讲述了“从哪里获得回收的表项”，这一篇会结合实际回收场景分析下“回收哪些表项？”。