作者：susion
博客地址：https://juejin.im/post/5c1369cff265da613b6fa87f
本文是recyclerview完全解析系列第三篇文章，内容是紧跟前两篇:recyclerview基本设计结构和 recyclerview刷新机制。
通过前面分析知道layoutmanager在布局子view时会向recycler索要一个viewholder。但从recycler中获取一个viewholder的前提是recycler中要有viewholder。那recycler中是如何有viewholder的呢？ 本文会分析两个问题:
recyclerview的view是在什么时候放入到recycler中的。以及在recycler中是如何保存的。
layoutmanager在向recycler获取viewholder时，recycler寻找viewholder的逻辑是什么。即何时存、怎么存和何时取、怎么取的问题。何时取已经很明显了:layoutmanager在布局子view时会从recycler中获取子view。 所以本文要理清的是其他3个问题。在文章继续之前要知道recycler管理的基本单元是viewholder，layoutmanager操作的基本单元是view，即viewholder的itemview。本文不会分析recyclerview动画时view的复用逻辑。
为了接下来的内容更容易理解，先回顾一下recycler的组成结构:
mchangedscrap : 用来保存recyclerview做动画时，被detach的viewholder。
mattachedscrap : 用来保存recyclerview做数据刷新(notify)，被detach的viewholder
mcacheviews : recycler的一级viewholder缓存。
recyclerviewpool : mcacheviews集合中装满时，会放到这里。
先看一下如何从recycler中取一个viewholder来复用。
从recycler中获取一个viewholder的逻辑
layoutmanager会调用recycler.getviewforposition(pos)来获取一个指定位置(这个位置是子view布局所在的位置)的view。getviewforposition会调用trygetviewholderforpositionbydeadline(position…), 这个方法是从recycler中获取一个view的核心方法。它就是如何从recycler中获取一个viewholder的逻辑，即怎么取, 方法太长, 我做了很多裁剪:
viewholder trygetviewholderforpositionbydeadline(int position, boolean dryrun, long deadlinens) {...if (mstate.isprelayout) { //动画相关holder = getchangedscrapviewforposition(position); //从缓存中拿吗？不应该不是缓存？fromscraporhiddenorcache = holder != ;}// 1) find by position from scrap/hidden list/cacheif (holder == ) {holder = getscraporhiddenorcachedholderforposition(position, dryrun); //从 attach 和 mcacheviews 中获取if (holder != ) {... //校验这个holder是否可用}}if (holder == ) {...final int type = madapter.getitemviewtype(offsetposition); //获取这个位置的数据的类型。 子adapter复写的方法// 2) find from scrap/cache via stable ids, if existsif (madapter.hasstableids) { //stable id 就是标识一个viewholder的唯一性， 即使它做动画改变了位置holder = getscraporcachedviewforid(madapter.getitemid(offsetposition), //根据 stable id 从 scrap 和 mcacheviews中获取type, dryrun);....}if (holder == && mviewcacheextension != ) { // 从用户自定义的缓存集合中获取final view view = mviewcacheextension.getviewforpositionandtype(this, position, type); //你返回的view要是recyclerview.layoutparams属性的if (view != ) {holder = getchildviewholder(view); //把它包装成一个viewholder...}}if (holder == ) { // 从 recyclerviewpool中获取holder = getrecycledviewpool.getrecycledview(type);...}if (holder == ) {...//实在没有就会创建holder = madapter.createviewholder(recyclerview.this, type);...}}...boolean bound = false;if (mstate.isprelayout && holder.isbound) { //动画时不会想去调用 onbinddata...} else if (!holder.isbound || holder.needsupdate || holder.isinvalid) {...final int offsetposition = madapterhelper.findpositionoffset(position);bound = trybindviewholderbydeadline(holder, offsetposition, position, deadlinens); //调用 binddata 方法}final viewgroup.layoutparams lp = holder.itemview.getlayoutparams;final layoutparams rvlayoutparams;...调整layoutparamsreturn holder;}即大致步骤是:
1. 如果执行了recyclerview动画的话，尝试根据position从mchangedscrap集合中寻找一个viewholder
2. 尝试根据position从scrap集合、hide的view集合、mcacheviews(一级缓存)中寻找一个viewholder
3. 根据layoutmanager的position更新到对应的adapter的position。 (这两个position在大部分情况下都是相等的，不过在子view删除或移动时可能产生不对应的情况)
4. 根据adapter position,调用adapter.getitemviewtype来获取viewtype
5. 根据stable id(用来表示viewholder的唯一，即使位置变化了)从scrap集合和mcacheviews(一级缓存)中寻找一个viewholder
6. 根据position和viewtype尝试从用户自定义的mviewcacheextension中获取一个viewholder
7. 根据viewtype尝试从recyclerviewpool中获取一个viewholder
8. 调用madapter.createviewholder来创建一个viewholder
9. 如果需要的话调用madapter.bindviewholder来设置viewholder。
10.调整viewholder.itemview的布局参数为recycler.layoutprams，并返回holder
虽然步骤很多，逻辑还是很简单的,即从几个缓存集合中获取viewholder，如果实在没有就创建。但比较疑惑的可能就是上述viewholder缓存集合中什么时候会保存viewholder。接下来分几个recyclerview的具体情形，来一点一点弄明白这些viewholder缓存集合的问题。
情形一 : 由无到有
即一开始recyclerview中没有任何数据，添加数据源后adapter.notifyxxx。状态变化如下图:
很明显在这种情形下recycler中是不会存在任何可复用的viewholder。所以所有的viewholder都是新创建的。即会调用adapter.createviewholder和adapter.bindviewholder。那这些创建的viewholder会缓存起来吗？
这时候新创建的这些viewholder是不会被缓存起来的。 即在这种情形下: recycler只会通过adapter创建viewholder,并且不会缓存这些新创建的viewholder
情形二 : 在原有数据的情况下进行整体刷新
就是下面这种状态:
其实就是相当于用户在feed中做了下拉刷新。实现中的伪代码如下:
datasource.cleardatasource.addall(newlist)adapter.notifydatasetchanged在这种情形下猜想recycler肯定复用了老的卡片(卡片的类型不变)，那么问题是 : 在用户刷新时旧viewholder保存在哪里？ 如何调用旧viewholder的adapter.bindviewholder来重新设置数据的？
其实在上一篇文章recycler刷新机制中，linearlayoutmanager在确定好布局锚点view之后就会把当前attach在recyclerview上的子view全部设置为scrap状态:
void onlayoutchildren(recyclerview.recycler recycler, recyclerview.state state) {...onanchorready(recycler, state, manchorinfo, firstlayoutdirection); // recyclerview指定锚点，要准备正式布局了detachandscrapattachedviews(recycler); // 在开始布局时，把所有的view都设置为 scrap 状态...}什么是scrap状态呢？ 在前面的文章其实已经解释过: viewholder被标记为flag_tmp_detached状态，并且其itemview的parent被设置为。
detachandscrapattachedviews就是把所有的view保存到recycler的mattachedscrap集合中:
public void detachandscrapattachedviews(@non recycler recycler) {for (int i = getchildcount - 1; i >= 0; i--) {final view v = getchildat(i);scraporrecycleview(recycler, i, v);}}private void scraporrecycleview(recycler recycler, int index, view view) {final viewholder viewholder = getchildviewholderint(view);...删去了一些判断逻辑detachviewat(index); //设置recyclerview这个位置的view的parent为， 并标记viewholder为flag_tmp_detachedrecycler.scrapview(view); //添加到mattachedscrap集合中...}所以在这种情形下linearlayoutmanager在真正摆放子view之前，会把所有旧的子view按顺序保存到recycler的mattachedscrap集合中
接下来继续看,linearlayoutmanager在布局时如何复用mattachedscrap集合中的viewholder。
前面已经说了linearlayoutmanager会当前布局子view的位置向recycler要一个子view，即调用到trygetviewholderforpositionbydeadline(position..)。我们上面已经列出了这个方法的逻辑，其实在前面的第二步:
尝试根据position从scrap集合、hide的view集合、mcacheviews(一级缓存)中寻找一个viewholder
即从mattachedscrap中就可以获得一个viewholder:
viewholder getscraporhiddenorcachedholderforposition(int position, boolean dryrun) {final int scrapcount = mattachedscrap.size;for (int i = 0; i < scrapcount; i ) {final viewholder holder = mattachedscrap.get(i);if (!holder.wasreturnedfromscrap && holder.getlayoutposition == position&& !holder.isinvalid && (mstate.minprelayout || !holder.isremoved)) {holder.addflags(viewholder.flag_returned_from_scrap);return holder;}}...}即如果mattachedscrap中holder的位置和入参position相等，并且holder是有效的话这个holder就是可以复用的。所以综上所述，在情形二下所有的viewholder几乎都是复用recycler中mattachedscrap集合中的。 并且重新布局完毕后recycler中是不存在可复用的viewholder的。
情形三 : 滚动复用
这个情形分析是在情形二的基础上向下滑动时viewholder的复用情况以及recycler中viewholder的保存情况, 如下图:
在这种情况下滚出屏幕的view会优先保存到mcacheviews, 如果mcacheviews中保存满了，就会保存到recyclerviewpool中。
在前一篇文章recyclerview刷新机制中分析过，recyclerview在滑动时会调用linearlayoutmanager.fill方法来根据滚动的距离来向recyclerview填充子view，其实在个方法在填充完子view之后就会把滚动出屏幕的view做回收:
int fill(recyclerview.recycler recycler, layoutstate layoutstate,recyclerview.state state, boolean stoponfocusable) {...int remainingspace = layoutstate.mavailable layoutstate.mextra;...while ((layoutstate.minfinite || remainingspace > 0) && layoutstate.hasmore(state)) {...layoutchunk(recycler, state, layoutstate, layoutchunkresult); //填充一个子viewif (layoutstate.mscrollingoffset != layoutstate.scrolling_offset_nan) {layoutstate.mscrollingoffset = layoutchunkresult.mconsumed;if (layoutstate.mavailable < 0) {layoutstate.mscrollingoffset = layoutstate.mavailable;}recyclebylayoutstate(recycler, layoutstate); //根据滚动的距离来回收view}}}即fill每填充一个子view都会调用recyclebylayoutstate来回收一个旧的子view,这个方法在层层调用之后会调用到recycler.recycleviewholderinternal。这个方法是viewholder回收的核心方法，不过逻辑很简单:
1. 检查mcacheviews集合中是否还有空位，如果有空位，则直接放到mcacheviews集合
2. 如果没有的话就把mcacheviews集合中最前面的viewholder拿出来放到recyclerviewpool中，然后再把最新的这个viewholder放到mcacheviews集合
3. 如果没有成功缓存到mcacheviews集合中，就直接放到recyclerviewpool
mcacheviews集合为什么要这样缓存? 看一下下面这张图 :
我是这样认为的，如上图，往上滑动一段距离，被滑动出去的viewholder会被缓存在mcacheviews集合,并且位置是被记录的。如果用户此时再下滑的话，可以参考文章开头的从recycler中获取viewholder的逻辑:
1. 先按照位置从mcacheviews集合中获取
2. 按照viewtype从mcacheviews集合中获取
上面对于mcacheviews集合两步操作，其实第一步就已经命中了缓存的viewholder。并且这时候都不需要调用adapter.bindviewholder方法的。即是十分高效的。
所以在普通的滚动复用的情况下，viewholder的复用主要来自于mcacheviews集合, 旧的viewholder会被放到mcacheviews集合, mcacheviews集合挤出来的更老的viewholder放到了recyclerviewpool中
近期文章：
-
冲击手机应用榜单top3，高手都做了这些
-
为什么？为什么程序员总是加班！！
-
移动端开发就不需要学习css了？
今日问题：
recyclerview使用过程中都遇到过哪些坑？
留言格式：
打卡x 天，答：xxx。
参与打卡活动：
