【进阶】RecyclerView源码解析(一)

本系列博客基于com.android.support:recyclerview-v7:26.1.0 1.【进阶】RecyclerView源码解析(一)——绘制流程 2.【进阶】RecyclerView源码解析(二)——缓存机制 3.【进阶】RecyclerView源码解析(三)——深度解析缓存机制 4.【进阶】RecyclerView源码解析(四)——RecyclerView进阶优化使用 5.【框架】基于AOP的RecyclerView复杂楼层样式的开发框架，楼层打通，支持组件化，支持MVP(不用每次再写Adapter了～)

自从Google出了RecyclerView后，基本上列表的场景已经完全替代了原来的ListView和GridView，现在不仅仅是列表，多样式（俗称盖楼），复杂页面等，只要我们愿意，RecyclerView几乎可以代替实现80%的布局，GitHub可以发现各种各样给予RecyclerView的开源库，无论是Adapter还是LayoutManager等。阿里对应出的vlayout其实也是RecyclerView的深度拓展，所以最近感觉仅仅了解用法是不够的，使用RecyclerView越多，就越会发现这个组件的深度不能仅仅停留在使用层面，从RecyclerView可以延伸出一系列进阶的使用、拓展、优化、封装等，所以打算从源码角度来看一下RecyclerView的实现机制，更方便我们进行进阶学习使用RecyclerView。

最早的看源码可能带着一点强迫和模仿性质，大家都在看源码都在分析源码，虽然不知道看源码能干什么，但是就是看就够了，所以挑选的也是大家都在分析的Volley，所以前面看的几个框架的源码从Volley到最近的OkHttp的源码，总感觉是为了看源码而看源码，虽然最后看完后收获确实很多，但是感觉方式总是不是特别正确，这次的RecyclerView的分析想法却不是这样的，由于对RecyclerView使用的程度和频率越来越多，越来越多的不解和疑问让我想要去看一看RecyclerView的源码，总的疑惑有下面几个：

1.首先没有见过特别详细的RecyclerView的源码分析系列，所有关于RecyclerView都是停留在使用或者少数进阶使用的博客

2.RecyclerView，LayoutManager，Adapter，ViewHolder，ItemDecoration这些和RecycleView使用息息相关的类到底是什么关系

3.RecyclerView作为列表，绘制流程到底什么样的

4.RecyclerView有什么不常用的进阶使用方式，但是却很适合RecyclerView作为很“重”的组件的优化，像setRecyclerPool用处到底是什么

5.大家都只要要使用RecyclerView替代ListView和GridView，好用，都在用，但是都没有追究到底这背后的原因到底是什么，RecyclerView到底比ListView好在哪里，到底该不该替换，性能到底提升多少。

以上问题不一定看完源码都能解决(个人能力堪忧啊...)，但是带着问题来看源码总会有不错的收获，或者大家有什么关于使用RecyclerView的学习博客链接，使用经验和体会都可以在下面评论供大家一起学习讨论。

当打开RecyclerVew的源码会发现非常的复杂，感觉无从下手，不会像Volley和OkHttp从发起开始到发起结束，目标性那么明确。那么既然RecyclerView继承的是ViewGroup，也就是说RecyclerView其实就是和LinearLayout等布局一样的一个自定义ViewGroup。 既然涉及到自定义组件，那么当我们自己来实现一个自定义ViewGroup，最重要的步骤无非是下面几点：

和分析OkHttp的源码一样，这里就不放上RecyclerView中的onMeasure的所有源码了，那样只会增加我们的理解难度，所以同样选择利用伪代码进行分析。

源码放上了，现在可以一步一步分析onMeasure的过程了，先从第一个小点开始吧。

这里的mLayout其实就是我们给RecyclerView设置的LayoutManager对象，这一段代码其实就很好的解释了为什么我们有时候初次使用RecyclerView的时候忘记设置LayoutManager后，RecyclerView会没有按照我们所想的那样显示出来。 这里可以看到，如果mLayout为null的话，会走defaultOnMeasure方法。

可以看到这里的chooseSize方法其实就是更加宽高的Mode得到相应的值后直接调用setMeasuredDimension(width, height)设置宽高了，可以发现这里其实是没有进行child的测量就直接return结束了onMeasure过程的，这也就解释了为什么我们没有设置LayoutManager会导致显示空白了。 接下来技术一个判断

这里其实mAutoMeasure这个值，LinearLayoutManager还是其他两个Manager，默认值都是true。所以接着往下看。

这里解释的很清楚，如果宽和高的测量值是绝对值时，直接跳过onMeasure方法。那这里可能有疑问了，如果没有执行onMeasure方法，那么子View没有绘制，会造成空白的情况，但是实际情况是当我们给RecyclerView设置绝对值大小的时候，子View仍可以正常绘制出来。这个问题后面会解答。（onLayout里会执行子View的绘制）

接下来就要开始绘制的准备了，这里可以看到首先判断mLayoutStep，这里mLayoutStep的默认值其实就是 State.STEP_START，并且每次绘制流程结束后，会重置为 State.STEP_START。接下来执行dispatchLayoutStep1();方法dispatchLayoutStep1();其实没有必要过多分析，因为分析源码主要是对于绘制思想的理解，如果过多的纠结于每一行代码的含义，那么会陷入很大的困扰中。这里就放上官方对于dispatchLayoutStep1();的注释吧。(顺道翻译一下)

接下来就是我们的真正执行LayoutManager绘制的地方dispatchLayoutStep2()。

同样的，这里放上伪代码，便于理解。 这里注意两个地方，第一个mAdapter.getItemCount()，可以看到我们每次重写Adapter时重写的方法getItemCount方法用到的地方了。 第二个，可以看到mLayout.onLayoutChildren(mRecycler, mState);这个方法，为什么说RecyclerView将View的绘制交给了LayoutManager，这里就是最有力的体现，可以看到，这里将RecycleView内部持有的Recycler和state传给了LayoutManager的onLayoutChildren方法，单从方法的名字其实就可以看出。这里我们进入LayoutManager里看一看。(本次分析给予LinearLayoutManager)

这里虽然已经尽量删减了很多代码，但是还是很多...但是其实原理理解起来还是比较容易的。简单的说其实可以总结缩略为：

先寻找页面当前的锚点 以这个锚点未基准，向上和向下分别填充 填充完后，如果还有剩余的可填充大小，再填充一次

这样理解起来就比较容易了，接下来我们就一步一步来看一下源码。 寻找锚点

可以看到这里有两种方法。 1.updateLayoutStateToFill...() 2.fill() 第一个方法其实就是确定当前方向上锚点的相关的状态信息。 这里最主要的就是第二个方法fill(),可以看到这里至少调用了两次fill()方法，当还有剩余可以绘制的时候会再调一次fill()方法。这也证明了我们的想法，是通过锚点分别向上和向下两次绘制。这里放上一张图便于理解

这里fill其实最重要的就是看这里的layoutChunk(recycler, state, layoutState, layoutChunkResult)方法。

这个方法其实我是不忍注释的，满满的干货啊，首先是我们的next方法，千万不要因为这个next短小不起眼，就认为不重要。我只能说这个方法很重要。

第一个mSrapList其实默认是空的，只有执行layoutForPredictiveAnimations前不为空，执行完后又变为空，所以这里暂时不需要考虑。 可以看到View view = recycler.getViewForPosition(mCurrentPosition)终于看到RecyclerView中缓存策略的身影，RecyclerView的缓存不会在这篇博客讲解，但是这里不得不让我们注意下面从流程上简单的看一下View view = recycler.getViewForPosition(mCurrentPosition);这个方法

可以看到这里，getViewForPosition会调用tryGetViewHolderForPositionByDeadline方法，tryGetViewHolderForPositionByDeadline方法的注释写的很清楚从Recycler的scrap，cache，RecyclerViewPool,或者直接create创建，这里我们也看到了我们最熟悉的**mAdapter.createViewHolder(RecyclerView.this, type); **方法！ 关于RecyclerView的缓存策略不出意外应该会在下篇博客进行分析 next()方法分析结束后，其实就比较容易了。

剩下的就是RecyclerView的addView方法。添加完View后会调用

从这个方法里我们看到了子View的测量，当然还有一个需要我们注意的地方那就是mRecyclerView.getItemDecorInsetsForChild(child)

其实可以看到这里在测量子View的时候是将我们实现自定义分割线重写的getItemOffsets方法。这里其实也就可以理解了自定义分割线的原理就是在子View的测量过程前给上下左右加上自定义分割线所对应设置给这个child的边距。 测量完成后，紧接着就调用了layoutDecoratedWithMargins(view, left, top, right, bottom)对子View完成了layout。

终于到此，我们对于onMeasure方法分析结束了，这里分析完成对于后面的onLayout的分析就比较简单了。

这里的代码就比较好理解了，并且上面提到的问题也就迎刃而解了，当我们给RecyclerView设置固定的宽高的时候，onMeasure是直接跳过了执行，那么为什么子View仍然能绘制出来。 这里可以看到，如果onMeasure没有执行，mState.mLayoutStep == State.STEP_START就成立，所以仍然会执行 dispatchLayoutStep1()， dispatchLayoutStep2();也就对应的会绘制子View。 而后面的注释也比较清楚，由于我们在Layout的时候改变了宽高，也会导致dispatchLayoutStep2();，也就是子View的重新绘制。 如果上面情况都没有，那么onLayout的作用就仅仅是dispatchLayoutStep3()，而 dispatchLayoutStep3()方法的作用除了重置一些参数，外还和执行动画有关。

到此！！！对于RecyclerView的绘制流程其实我们有了一个大体的了解，总结一下关键点：

1.RecyclerView是将绘制流程交给LayoutManager处理，如果没有设置不会测量子View。 2.绘制流程是区分正向绘制和倒置绘制。 3.绘制是先确定锚点，然后向上绘制，向下绘制，fill()至少会执行两次，如果绘制完还有剩余空间，则会再执行一次fill()方法。 4.LayoutManager获得View是从RecyclerView中的Recycler.next()方法获得，涉及到RecyclerView的缓存策略，如果缓存没有拿到，则走我们自己重写的onCreateView方法。 5.如果RecyclerView宽高没有写死，onMeasure就会执行完子View的measure和Layout方法，onLayout仅仅是重置一些参数，如果写死，子View的measure和layout会延后到onLayout中执行。

基于AOP的RecyclerView复杂楼层样式的开发框架，楼层打通，支持组件化，支持MVP(不用每次再写Adapter了～)-EMvp Star👏支持一下～ 欢迎提issues讨论～