RecyclerView 源码分析（一） —— 绘制流程解析
概述
对于 RecyclerView 是那么熟悉又那么陌生。熟悉是由于做为一名 Android 开发者，RecyclerView 是常常会在项目里面用到的，陌生是由于只是知道怎么用，可是殊不知道 RecyclerView 的内部实现机制。html
但凡是一位有所追求的开发者，都不会只让本身停留在只会使用上，而是会研读相关源码，知其然知其因此然。android
对于 RecyclerView 的源码解析一篇文章确定是不够的，后续有时间会继续更新。每一篇都会有本身的主题。RecyclerView 的使用，本文也就不讲了，具体能够查看以前的文章：RecyclerView 使用指南。算法
对于用过 RecyclerView 的开发者来讲，这个 View 的功能确实强大，能够在平常开发的不少场景均可以使用。在讲解 RecyclerView 绘制源码的时候，我但愿你们去思考一些问题：缓存
-
若是是你，你会怎么来设计 RecyclerView 的绘制过程，和普通的 View 同样？app
-
RecyclerView 能够支持不一样的流式布局，一列，多列，因此里面的绘制逻辑它是如何设计的？less
-
分割线是能够定制的，那我要如何设计这块的代码？ide
其实也还有其余的问题，可是本文只讲绘制流程，所以，其余问题就在其余模块去思考。要是在之前呢，我也是为了分析源码而分析源码，而后把文章发出去。不多去思考源码背后的一些东西。直到最近本身须要去重构一个模块的时候，发现设计一个技术方案是多么的难。oop
本文源码版本：androidx.recyclerView:1.1.0 源码分析
measure 测量
对于 view 来讲，必有的三大流程：测量，布局，绘制。所以 RecyclerView 也是同样。若是你如今仍是对 View 的绘制流程，不了解能够推荐看文章：布局
下面进入正题，首先来看下 RecyclerView 类的定义：
public class RecyclerView extends ViewGroup implements ScrollingView, NestedScrollingChild2, NestedScrollingChild3 { // ...... }
能够看到 RecyclerView 是一个 ViewGroup，也就是说，RecyclerView 本质是一个自定义 view，须要本身去管理绘制流程。对于了解自定义 View 来讲，其实就是须要重写 onMeasure 方法。
在 Android 自定义 View 详解 一文中总结了 onMeausre 的具体逻辑，到这里，依然能够作个参考：
-
super.onMeasure 会先计算自定义 view 的大小；
- 调用 measureChild 对子 View 进行测量；
-
自定义 view 设置的宽高参数不是 MeasureSpec.EXACTLY 的话，对于子 View 是 match_parent 须要额外处理，同时也须要对 MeasureSpec.AT_MOST 状况进行额外处理。
-
当自定义View 的大小肯定后，在对子 View 是 match_parent 从新测量；
下面来看下 RecyclerView 的 onMeausre 代码：
protected void onMeasure(int widthSpec, int heightSpec) { if (mLayout == null) { // 第一种状况 } if (mLayout.isAutoMeasureEnabled()) { // 第二种状况 } else { // 第三种状况 } }
onMeasure方法仍是有点长，这里我将它分为3种状况，我将简单解释这三种状况：
-
mLayout即LayoutManager的对象。咱们知道，当RecyclerView的LayoutManager为空时，RecyclerView不能显示任何的数据，在这里咱们找到答案。 -
LayoutManager开启了自动测量时，这是一种状况。在这种状况下，有可能会测量两次。 -
第三种状况就是没有开启自动测量的状况，这种状况比较少，由于
RecyclerView 为了支持warp_content属性，系统提供的LayoutManager都开启自动测量的，不过仍是要分析的。
首先咱们来第一种状况。
一、LayoutManager == null
这种状况下比较简单，咱们来看看源码：
if (mLayout == null) { defaultOnMeasure(widthSpec, heightSpec); return; }
这里是调用了 defaultOnMeasure 方法，
void defaultOnMeasure(int widthSpec, int heightSpec) { // calling LayoutManager here is not pretty but that API is already public and it is better // than creating another method since this is internal. final int width = LayoutManager.chooseSize(widthSpec, getPaddingLeft() + getPaddingRight(), ViewCompat.getMinimumWidth(this)); final int height = LayoutManager.chooseSize(heightSpec, getPaddingTop() + getPaddingBottom(), ViewCompat.getMinimumHeight(this)); setMeasuredDimension(width, height); }
在 defaultOnMeasure 方法里面，主要是经过 LayoutManager 的 chooseSize 方法来计算宽高，最后调用 setMeasuredDimension 方法来设置宽高。下面来看下 chooseSize 的具体逻辑：
public static int chooseSize(int spec, int desired, int min) { final int mode = View.MeasureSpec.getMode(spec); final int size = View.MeasureSpec.getSize(spec); switch (mode) { case View.MeasureSpec.EXACTLY: return size; case View.MeasureSpec.AT_MOST: return Math.min(size, Math.max(desired, min)); case View.MeasureSpec.UNSPECIFIED: default: return Math.max(desired, min); } }
这里主要是根据不一样的设置，来返回最终的大小。这块逻辑不是很懂的读者能够阅读前面提到的文章，里面详细解读了。可是这里有个问题须要指出来的就是没有测量子 view 的大小，这也是白屏的缘由。由于 RecyclerView 的绘制实际上是委托给 LayoutManager 来管理呢，LayoutManager = null 的状况下测量子 view 没有任何的意义。
二、LayoutManager 开启了自动测量
在分析这种状况以前，咱们先对了解几个东西。
RecyclerView 的测量分为两步，分别调用 dispatchLayoutStep1 和 dispatchLayoutStep2。同时，了解过 RecyclerView 源码的同窗应该知道在 RecyclerView 的源码里面还一个dispatchLayoutStep3 方法。这三个方法的方法名比较接近，因此容易让人搞混淆。本文会详细的讲解这三个方法的做用。
因为在这种状况下，只会调用 dispatchLayoutStep1 和 dispatchLayoutStep2 这两个方法，因此这里会重点的讲解这两个方法。而 dispatchLayoutStep3 方法的调用在RecyclerView 的 onLayout 方法里面，因此在后面分析 onLayout 方法时再来看 dispatchLayoutStep3 方法。
咱们在分析以前，先来看一个东西 —— mState.mLayoutStep。这个变量有几个取值状况。咱们分别来看看：
| 取值 | 含义 |
|---|---|
| State.STEP_START |
|
| State.STEP_LAYOUT |
当 |
| State.STEP_ANIMATIONS |
当 |
从上表中，咱们了解到 mState.mLayoutStep 的三个状态对应着不一样的 dispatchLayoutStep 方法。这一点，咱们必须清楚，不然接下来的代码将难以理解。
if (mLayout.isAutoMeasureEnabled()) { final int widthMode = MeasureSpec.getMode(widthSpec); final int heightMode = MeasureSpec.getMode(heightSpec); /** * This specific call should be considered deprecated and replaced with * {@link #defaultOnMeasure(int, int)}. It can't actually be replaced as it could * break existing third party code but all documentation directs developers to not * override {@link LayoutManager#onMeasure(int, int)} when * {@link LayoutManager#isAutoMeasureEnabled()} returns true. */ mLayout.onMeasure(mRecycler, mState, widthSpec, heightSpec); final boolean measureSpecModeIsExactly = widthMode == MeasureSpec.EXACTLY && heightMode == MeasureSpec.EXACTLY; if (measureSpecModeIsExactly || mAdapter == null) { return; } // 开始测量 if (mState.mLayoutStep == State.STEP_START) { dispatchLayoutStep1(); } // set dimensions in 2nd step. Pre-layout should happen with old dimensions for // consistency mLayout.setMeasureSpecs(widthSpec, heightSpec); mState.mIsMeasuring = true;
// 第二次 dispatchLayoutStep2(); // now we can get the width and height from the children. mLayout.setMeasuredDimensionFromChildren(widthSpec, heightSpec); // if RecyclerView has non-exact width and height and if there is at least one child // which also has non-exact width & height, we have to re-measure. if (mLayout.shouldMeasureTwice()) { mLayout.setMeasureSpecs( MeasureSpec.makeMeasureSpec(getMeasuredWidth(), MeasureSpec.EXACTLY), MeasureSpec.makeMeasureSpec(getMeasuredHeight(), MeasureSpec.EXACTLY)); mState.mIsMeasuring = true; dispatchLayoutStep2(); // now we can get the width and height from the children. mLayout.setMeasuredDimensionFromChildren(widthSpec, heightSpec); } }
首先，咱们来看看 onMeasure 方法。
public void onMeasure(@NonNull Recycler recycler, @NonNull State state, int widthSpec, int heightSpec) { mRecyclerView.defaultOnMeasure(widthSpec, heightSpec); }
RecyclerView 的
defaultOnMeasure 方法，其实就是前面咱们介绍过的自定义 View 的三个步骤：先是测量本身自己的大小。
dispatchLayoutStep1
/** * The first step of a layout where we; * - process adapter updates * - decide which animation should run * - save information about current views * - If necessary, run predictive layout and save its information */ private void dispatchLayoutStep1() {
// 这里还用到了断言 mState.assertLayoutStep(State.STEP_START); fillRemainingScrollValues(mState); mState.mIsMeasuring = false; startInterceptRequestLayout(); mViewInfoStore.clear(); onEnterLayoutOrScroll();
// 处理 adapter 更新 processAdapterUpdatesAndSetAnimationFlags(); saveFocusInfo(); mState.mTrackOldChangeHolders = mState.mRunSimpleAnimations && mItemsChanged; mItemsAddedOrRemoved = mItemsChanged = false; mState.mInPreLayout = mState.mRunPredictiveAnimations; mState.mItemCount = mAdapter.getItemCount(); findMinMaxChildLayoutPositions(mMinMaxLayoutPositions); // 是否要运行动画 if (mState.mRunSimpleAnimations) { // Step 0: Find out where all non-removed items are, pre-layout int count = mChildHelper.getChildCount(); for (int i = 0; i < count; ++i) { final ViewHolder holder = getChildViewHolderInt(mChildHelper.getChildAt(i)); if (holder.shouldIgnore() || (holder.isInvalid() && !mAdapter.hasStableIds())) { continue; } final ItemHolderInfo animationInfo = mItemAnimator .recordPreLayoutInformation(mState, holder, ItemAnimator.buildAdapterChangeFlagsForAnimations(holder), holder.getUnmodifiedPayloads()); mViewInfoStore.addToPreLayout(holder, animationInfo); if (mState.mTrackOldChangeHolders && holder.isUpdated() && !holder.isRemoved() && !holder.shouldIgnore() && !holder.isInvalid()) { long key = getChangedHolderKey(holder); // This is NOT the only place where a ViewHolder is added to old change holders // list. There is another case where: // * A VH is currently hidden but not deleted // * The hidden item is changed in the adapter // * Layout manager decides to layout the item in the pre-Layout pass (step1) // When this case is detected, RV will un-hide that view and add to the old // change holders list. mViewInfoStore.addToOldChangeHolders(key, holder); } } } if (mState.mRunPredictiveAnimations) { // Step 1: run prelayout: This will use the old positions of items. The layout manager // is expected to layout everything, even removed items (though not to add removed // items back to the container). This gives the pre-layout position of APPEARING views // which come into existence as part of the real layout. // Save old positions so that LayoutManager can run its mapping logic. saveOldPositions(); final boolean didStructureChange = mState.mStructureChanged; mState.mStructureChanged = false; // temporarily disable flag because we are asking for previous layout mLayout.onLayoutChildren(mRecycler, mState); mState.mStructureChanged = didStructureChange; for (int i = 0; i < mChildHelper.getChildCount(); ++i) { final View child = mChildHelper.getChildAt(i); final ViewHolder viewHolder = getChildViewHolderInt(child); if (viewHolder.shouldIgnore()) { continue; } if (!mViewInfoStore.isInPreLayout(viewHolder)) { int flags = ItemAnimator.buildAdapterChangeFlagsForAnimations(viewHolder); boolean wasHidden = viewHolder .hasAnyOfTheFlags(ViewHolder.FLAG_BOUNCED_FROM_HIDDEN_LIST); if (!wasHidden) { flags |= ItemAnimator.FLAG_APPEARED_IN_PRE_LAYOUT; } final ItemHolderInfo animationInfo = mItemAnimator.recordPreLayoutInformation( mState, viewHolder, flags, viewHolder.getUnmodifiedPayloads()); if (wasHidden) { recordAnimationInfoIfBouncedHiddenView(viewHolder, animationInfo); } else { mViewInfoStore.addToAppearedInPreLayoutHolders(viewHolder, animationInfo); } } } // we don't process disappearing list because they may re-appear in post layout pass. clearOldPositions(); } else { clearOldPositions(); } onExitLayoutOrScroll(); stopInterceptRequestLayout(false);
// 上面的执行完之后，改变状态 mState.mLayoutStep = State.STEP_LAYOUT; }
其实最上面的方法注释，已经把这个方法所作的事情都总结好了，该方法主要工做以下：
-
处理
Adapter更新; -
决定执行哪种动画
-
保存每一个
ItemView的信息 -
有必要的话，会进行预布局，并把相关信息保存下来。
能够看到整个方法内部调用的方法仍是不少，致使你会以为这个方法的逻辑很复杂。不过既然是源码阅读，我们只关注一些重要的点，在众多被调用的方法中 processAdapterUpdatesAndSetAnimationFlags 是须要点进去看看里面的逻辑的，后续的 if else 逻辑其实都是在该方法里面决定的。
/** * Consumes adapter updates and calculates which type of animations we want to run. * Called in onMeasure and dispatchLayout. * <p> * This method may process only the pre-layout state of updates or all of them. */ private void processAdapterUpdatesAndSetAnimationFlags() { if (mDataSetHasChangedAfterLayout) { // Processing these items have no value since data set changed unexpectedly. // Instead, we just reset it. mAdapterHelper.reset(); if (mDispatchItemsChangedEvent) { mLayout.onItemsChanged(this); } } // simple animations are a subset of advanced animations (which will cause a // pre-layout step) // If layout supports predictive animations, pre-process to decide if we want to run them if (predictiveItemAnimationsEnabled()) { mAdapterHelper.preProcess(); } else { mAdapterHelper.consumeUpdatesInOnePass(); } boolean animationTypeSupported = mItemsAddedOrRemoved || mItemsChanged; mState.mRunSimpleAnimations = mFirstLayoutComplete && mItemAnimator != null && (mDataSetHasChangedAfterLayout || animationTypeSupported || mLayout.mRequestedSimpleAnimations) && (!mDataSetHasChangedAfterLayout || mAdapter.hasStableIds()); mState.mRunPredictiveAnimations = mState.mRunSimpleAnimations && animationTypeSupported && !mDataSetHasChangedAfterLayout && predictiveItemAnimationsEnabled(); }
mFirstLayoutComplete 变量里面，咱们发现
mRunSimpleAnimations 的值与
mFirstLayoutComplete有关，
mRunPredictiveAnimations同时跟
mRunSimpleAnimations有关。因此这里咱们能够得出一个结论，当
RecyclerView第一次加载数据时，是不会执行的动画？那到底会不会呢，这里先卖个关子。
dispatchLayoutStep2
dispatchLayoutStep2 方法，这个方法是真正布局
children。上代码：
/** * The second layout step where we do the actual layout of the views for the final state. * This step might be run multiple times if necessary (e.g. measure). */ private void dispatchLayoutStep2() { startInterceptRequestLayout(); onEnterLayoutOrScroll(); mState.assertLayoutStep(State.STEP_LAYOUT | State.STEP_ANIMATIONS); mAdapterHelper.consumeUpdatesInOnePass(); mState.mItemCount = mAdapter.getItemCount(); mState.mDeletedInvisibleItemCountSincePreviousLayout = 0; // Step 2: Run layout mState.mInPreLayout = false; mLayout.onLayoutChildren(mRecycler, mState); mState.mStructureChanged = false; mPendingSavedState = null; // onLayoutChildren may have caused client code to disable item animations; re-check mState.mRunSimpleAnimations = mState.mRunSimpleAnimations && mItemAnimator != null; mState.mLayoutStep = State.STEP_ANIMATIONS; onExitLayoutOrScroll(); stopInterceptRequestLayout(false); }
能够看到的是，这里的逻辑彷佛简单不少，那是由于这里把对子 view 的绘制逻辑放到 LayoutManager 中去了。到这里，state 的状态已经改变了，变成了 State.STEP_LAYOUT | State.STEP_ANIMATIONS。
系统的 LayoutManager 的 onLayoutChildren 方法是一个空方法，因此须要 LayoutManager 的子类本身来实现。
这里先不作过多介绍，不一样的 LayoutManager 有不一样的实现。
三、没有开启自动测量
仍是先来看看这一块的代码：
{ if (mHasFixedSize) { mLayout.onMeasure(mRecycler, mState, widthSpec, heightSpec); return; } // custom onMeasure if (mAdapterUpdateDuringMeasure) { startInterceptRequestLayout(); onEnterLayoutOrScroll(); processAdapterUpdatesAndSetAnimationFlags(); onExitLayoutOrScroll(); if (mState.mRunPredictiveAnimations) { mState.mInPreLayout = true; } else { // consume remaining updates to provide a consistent state with the layout pass. mAdapterHelper.consumeUpdatesInOnePass(); mState.mInPreLayout = false; } mAdapterUpdateDuringMeasure = false; stopInterceptRequestLayout(false); } else if (mState.mRunPredictiveAnimations) { // If mAdapterUpdateDuringMeasure is false and mRunPredictiveAnimations is true: // this means there is already an onMeasure() call performed to handle the pending // adapter change, two onMeasure() calls can happen if RV is a child of LinearLayout // with layout_width=MATCH_PARENT. RV cannot call LM.onMeasure() second time // because getViewForPosition() will crash when LM uses a child to measure. setMeasuredDimension(getMeasuredWidth(), getMeasuredHeight()); return; } if (mAdapter != null) { mState.mItemCount = mAdapter.getItemCount(); } else { mState.mItemCount = 0; } startInterceptRequestLayout(); mLayout.onMeasure(mRecycler, mState, widthSpec, heightSpec); stopInterceptRequestLayout(false); mState.mInPreLayout = false; // clear }
这里主要作了两件事，其实跟第二个步骤很像，最终都会调用 LayoutManager 的 onMeasure 方法来进行测量。
-
若是
mHasFixedSize为true(也就是调用了setHasFixedSize方法)，将直接调用LayoutManager的onMeasure方法进行测量。 -
若是
mHasFixedSize为false，同时此时若是有数据更新，先处理数据更新的事务，而后调用LayoutManager的onMeasure方法进行测量
onLayout 布局
到这里，关于测量的逻辑就讲完了，接下去开始看 layout 逻辑：
@Override protected void onLayout(boolean changed, int l, int t, int r, int b) { TraceCompat.beginSection(TRACE_ON_LAYOUT_TAG); dispatchLayout(); TraceCompat.endSection(); mFirstLayoutComplete = true; }
首先会调用 dispatchLayout 进行 layout 操做，能够看到前面关注过的一个变量 mFirstLayoutComplete 赋值变为 true 。
下面主要看 dispatchLayout 方法：
void dispatchLayout() { if (mAdapter == null) { Log.e(TAG, "No adapter attached; skipping layout"); // leave the state in START return; } if (mLayout == null) { Log.e(TAG, "No layout manager attached; skipping layout"); // leave the state in START return; } mState.mIsMeasuring = false; if (mState.mLayoutStep == State.STEP_START) { dispatchLayoutStep1(); mLayout.setExactMeasureSpecsFrom(this); dispatchLayoutStep2(); } else if (mAdapterHelper.hasUpdates() || mLayout.getWidth() != getWidth() || mLayout.getHeight() != getHeight()) { // First 2 steps are done in onMeasure but looks like we have to run again due to // changed size. mLayout.setExactMeasureSpecsFrom(this); dispatchLayoutStep2(); } else { // always make sure we sync them (to ensure mode is exact) mLayout.setExactMeasureSpecsFrom(this); } dispatchLayoutStep3(); }
dispatchLayout 方法也是很是的简单，这个方法保证 RecyclerView 必须经历三个过程 —— dispatchLayoutStep1、dispatchLayoutStep2、dispatchLayoutStep3。同时，若是在这时候，发现子 view 宽高参数发生变化后，会再次调用 dispatchLayoutStep2() 方法。
最后，来看下千呼万唤使出来的 dispatchLayoutStep3 方法：
/** * The final step of the layout where we save the information about views for animations, * trigger animations and do any necessary cleanup. */ private void dispatchLayoutStep3() {
// 动画 mState.assertLayoutStep(State.STEP_ANIMATIONS); startInterceptRequestLayout(); onEnterLayoutOrScroll();
// 标记进行复位 mState.mLayoutStep = State.STEP_START; if (mState.mRunSimpleAnimations) { // Step 3: Find out where things are now, and process change animations. // traverse list in reverse because we may call animateChange in the loop which may // remove the target view holder. for (int i = mChildHelper.getChildCount() - 1; i >= 0; i--) { ViewHolder holder = getChildViewHolderInt(mChildHelper.getChildAt(i)); if (holder.shouldIgnore()) { continue; } long key = getChangedHolderKey(holder); final ItemHolderInfo animationInfo = mItemAnimator .recordPostLayoutInformation(mState, holder); ViewHolder oldChangeViewHolder = mViewInfoStore.getFromOldChangeHolders(key); if (oldChangeViewHolder != null && !oldChangeViewHolder.shouldIgnore()) { // run a change animation // If an Item is CHANGED but the updated version is disappearing, it creates // a conflicting case. // Since a view that is marked as disappearing is likely to be going out of // bounds, we run a change animation. Both views will be cleaned automatically // once their animations finish. // On the other hand, if it is the same view holder instance, we run a // disappearing animation instead because we are not going to rebind the updated // VH unless it is enforced by the layout manager. final boolean oldDisappearing = mViewInfoStore.isDisappearing( oldChangeViewHolder); final boolean newDisappearing = mViewInfoStore.isDisappearing(holder); if (oldDisappearing && oldChangeViewHolder == holder) { // run disappear animation instead of change mViewInfoStore.addToPostLayout(holder, animationInfo); } else { final ItemHolderInfo preInfo = mViewInfoStore.popFromPreLayout( oldChangeViewHolder); // we add and remove so that any post info is merged. mViewInfoStore.addToPostLayout(holder, animationInfo); ItemHolderInfo postInfo = mViewInfoStore.popFromPostLayout(holder); if (preInfo == null) { handleMissingPreInfoForChangeError(key, holder, oldChangeViewHolder); } else { animateChange(oldChangeViewHolder, holder, preInfo, postInfo, oldDisappearing, newDisappearing); } } } else { mViewInfoStore.addToPostLayout(holder, animationInfo); } } // Step 4: Process view info lists and trigger animations 作动画 mViewInfoStore.process(mViewInfoProcessCallback); } mLayout.removeAndRecycleScrapInt(mRecycler);
// 记录数据，并把以前用到一些标志位复位 mState.mPreviousLayoutItemCount = mState.mItemCount; mDataSetHasChangedAfterLayout = false; mDispatchItemsChangedEvent = false; mState.mRunSimpleAnimations = false; mState.mRunPredictiveAnimations = false; mLayout.mRequestedSimpleAnimations = false; if (mRecycler.mChangedScrap != null) { mRecycler.mChangedScrap.clear(); } if (mLayout.mPrefetchMaxObservedInInitialPrefetch) { // Initial prefetch has expanded cache, so reset until next prefetch. // This prevents initial prefetches from expanding the cache permanently. mLayout.mPrefetchMaxCountObserved = 0; mLayout.mPrefetchMaxObservedInInitialPrefetch = false; mRecycler.updateViewCacheSize(); } mLayout.onLayoutCompleted(mState); onExitLayoutOrScroll(); stopInterceptRequestLayout(false); mViewInfoStore.clear();
// if (didChildRangeChange(mMinMaxLayoutPositions[0], mMinMaxLayoutPositions[1])) { dispatchOnScrolled(0, 0); } recoverFocusFromState(); resetFocusInfo(); }
从上面的逻辑能够看出 dispatchLayoutStep3 主要是作 Item 的动画，本文不对动画进行展开，因此先省略动画部分。而后就是对一些标志位复位。清除一些状态。
小结
这里对这三个方法作一个小结，方便你们记住这几个方法的做用：
| 方法名 | 做用 |
|---|---|
| dispatchLayoutStep1 | 本方法的做用主要有三点：
|
| dispatchLayoutStep2 | 在这个方法里面，真正进行 children 的测量和布局。 |
| dispatchLayoutStep3 | 这个方法的做用执行在 dispatchLayoutStep1 方法里面保存的动画信息。本方法不是本文的介绍重点 |
三、Draw 绘制
接下来，咱们来分析三大流程的最后一个阶段 —— draw。
下面来看看 RecyclerView 的 draw() 和 onDraw() 方法：
public void draw(Canvas c) { super.draw(c); final int count = mItemDecorations.size(); for (int i = 0; i < count; i++) { mItemDecorations.get(i).onDrawOver(c, this, mState); } // ...... }
真是考虑周到啊。
@Override public void onDraw(Canvas c) { super.onDraw(c); final int count = mItemDecorations.size(); for (int i = 0; i < count; i++) { mItemDecorations.get(i).onDraw(c, this, mState); } }
发现这里并无作太多，只是调用 ItemDecoration 的 onDraw 和 onDrawOver 方法。这样就将分割线添加到其中。
四、 LinearLayoutManager
dispatchLayoutStep2 方法时，只是简单的介绍了，
RecyclerView 经过调用
LayoutManager 的
onLayoutChildren 方法。
LayoutManager 自己对这个方法没有进行实现，因此必须得看看它的子类，这里以 LinearLayoutManager 来举例说明：
onLayoutChildren
@Override public void onLayoutChildren(RecyclerView.Recycler recycler, RecyclerView.State state) { // ...... ensureLayoutState(); mLayoutState.mRecycle = false; // resolve layout direction resolveShouldLayoutReverse();
// ......
// calculate anchor position and coordinate
updateAnchorInfoForLayout(recycler, state, mAnchorInfo);
mAnchorInfo.mValid = true;
// noRecycleSpace not needed: recycling doesn't happen in below's fill // invocations because mScrollingOffset is set to SCROLLING_OFFSET_NaN mLayoutState.mNoRecycleSpace = 0; if (mAnchorInfo.mLayoutFromEnd) { // fill towards start updateLayoutStateToFillStart(mAnchorInfo); mLayoutState.mExtraFillSpace = extraForStart; fill(recycler, mLayoutState, state, false); startOffset = mLayoutState.mOffset; final int firstElement = mLayoutState.mCurrentPosition; if (mLayoutState.mAvailable > 0) { extraForEnd += mLayoutState.mAvailable; } // fill towards end updateLayoutStateToFillEnd(mAnchorInfo); mLayoutState.mExtraFillSpace = extraForEnd; mLayoutState.mCurrentPosition += mLayoutState.mItemDirection; fill(recycler, mLayoutState, state, false); endOffset = mLayoutState.mOffset; if (mLayoutState.mAvailable > 0) { // end could not consume all. add more items towards start extraForStart = mLayoutState.mAvailable; updateLayoutStateToFillStart(firstElement, startOffset); mLayoutState.mExtraFillSpace = extraForStart; fill(recycler, mLayoutState, state, false); startOffset = mLayoutState.mOffset; } } else { // fill towards end updateLayoutStateToFillEnd(mAnchorInfo); mLayoutState.mExtraFillSpace = extraForEnd; fill(recycler, mLayoutState, state, false); endOffset = mLayoutState.mOffset; final int lastElement = mLayoutState.mCurrentPosition; if (mLayoutState.mAvailable > 0) { extraForStart += mLayoutState.mAvailable; } // fill towards start updateLayoutStateToFillStart(mAnchorInfo); mLayoutState.mExtraFillSpace = extraForStart; mLayoutState.mCurrentPosition += mLayoutState.mItemDirection; fill(recycler, mLayoutState, state, false); startOffset = mLayoutState.mOffset; if (mLayoutState.mAvailable > 0) { extraForEnd = mLayoutState.mAvailable; // start could not consume all it should. add more items towards end updateLayoutStateToFillEnd(lastElement, endOffset); mLayoutState.mExtraFillSpace = extraForEnd; fill(recycler, mLayoutState, state, false); endOffset = mLayoutState.mOffset; } } layoutForPredictiveAnimations(recycler, state, startOffset, endOffset); if (!state.isPreLayout()) { mOrientationHelper.onLayoutComplete(); } else { mAnchorInfo.reset(); } mLastStackFromEnd = mStackFromEnd; if (DEBUG) { validateChildOrder(); } }
onLayoutChildren 方法很长，所以省略一些无关的代码。其实主要是作两件事肯定锚点的信息，这里面的信息包括：
-
1
Children的布局方向，有 start 和 end 两个方向； -
mPosition和mCoordinate，分别表示Children开始填充的 position 和坐标。
根据锚点信息，调用 fill 方法进行 Children 的填充。这个过程当中根据锚点信息的不一样，可能会调用两次 fill 方法。
updateAnchorInfoForLayout
要想看锚点信息的计算过程，咱们能够从 updateAnchorInfoForLayout 方法里面来找出答案，咱们来看看 updateAnchorInfoForLayout 方法：
private void updateAnchorInfoForLayout(RecyclerView.Recycler recycler, RecyclerView.State state, AnchorInfo anchorInfo) { if (updateAnchorFromPendingData(state, anchorInfo)) { if (DEBUG) { Log.d(TAG, "updated anchor info from pending information"); } return; } if (updateAnchorFromChildren(recycler, state, anchorInfo)) { if (DEBUG) { Log.d(TAG, "updated anchor info from existing children"); } return; } if (DEBUG) { Log.d(TAG, "deciding anchor info for fresh state"); } anchorInfo.assignCoordinateFromPadding(); anchorInfo.mPosition = mStackFromEnd ? state.getItemCount() - 1 : 0; }
我相信经过上面的代码注释，你们都能明白 updateAnchorInfoForLayout 方法到底干了嘛，这里我简单分析一下这三种肯定所作的含义，具体是怎么作的，这里就不讨论。
-
第一种计算方式，表示含义有两种：1.
RecyclerView被重建，期间回调了onSaveInstanceState方法，因此目的是为了恢复上次的布局；2.RecyclerView调用了scrollToPosition之类的方法，因此目的是让 -
RecyclerView滚到准确的位置上去。因此，锚点的信息根据上面的两种状况来计算。 -
第二种计算方法，从
C hildren上面来计算锚点信息。这种计算方式也有两种状况：1. 若是当前有拥有焦点的Child，那么有当前有焦点的 Child 的位置来计算锚点；2. 若是没有 child 拥有焦点，那么根据布局方向(此时布局方向由mLayoutFromEnd来决定)获取可见的第一个ItemView或者最后一个ItemView。 -
若是前面两种方式都计算失败了，那么采用第三种计算方式，也就是默认的计算方式。
fill 填充布局
而后就是调用 fill 方法来填充 Children。在正式分析填充过程时，咱们先来看一张图片：
上图形象的展示出三种fill的状况。其中，咱们能够看到第三种状况，fill 方法被调用了两次。
咱们看看 fill 方法:
int fill(RecyclerView.Recycler recycler, LayoutState layoutState, RecyclerView.State state, boolean stopOnFocusable) { // ······ while ((layoutState.mInfinite || remainingSpace > 0) && layoutState.hasMore(state)) { // ······ layoutChunk(recycler, state, layoutState, layoutChunkResult); } // ······ }
fill 方法的代码比较长，其实都是来计算可填充的空间，真正填充 Child 的地方是 layoutChunk 方法。咱们来看看 layoutChunk 方法。
void layoutChunk(RecyclerView.Recycler recycler, RecyclerView.State state, LayoutState layoutState, LayoutChunkResult result) { View view = layoutState.next(recycler); ... if (layoutState.mScrapList == null) { if (mShouldReverseLayout == (layoutState.mLayoutDirection == LayoutState.LAYOUT_START)) { addView(view); } else { addView(view, 0); } } ... measureChildWithMargins(view, 0, 0); ... // We calculate everything with View's bounding box (which includes decor and margins) // To calculate correct layout position, we subtract margins. layoutDecorated(view, left + params.leftMargin, top + params.topMargin, right - params.rightMargin, bottom - params.bottomMargin); ... }
提醒下别小看这个 next 方法，RecyclerView 缓存机制的起点就是从这个方法开始，可想而知，这个方法到底为咱们作了多少事情。
这里的 addView() 方法，其实就是 ViewGroup 的 addView() 方法；measureChildWithMargins() 方法看名字就知道是用于测量子控件大小的，这里我先跳过这个方法的解释，放在后面来作，目前就简单地理解为测量子控件大小就行了。下面是 layoutDecoreated() 方法：
public void layoutDecorated(@NonNull View child, int left, int top, int right, int bottom) {
// 将分割线考虑进去 final Rect insets = ((LayoutParams) child.getLayoutParams()).mDecorInsets; child.layout(left + insets.left, top + insets.top, right - insets.right, bottom - insets.bottom); }
总结上面代码，在 RecyclerView 的 measure 及 layout 阶段，填充 ItemView 的算法为：向父容器增长子控件，测量子控件大小，布局子控件，布局锚点向当前布局方向平移子控件大小，重复上诉步骤至 RecyclerView 可绘制空间消耗完毕或子控件已所有填充。
这样全部的子控件的 measure 及 layout 过程就完成了。回到 RecyclerView 的 onMeasure 方法，执行 mLayout.setMeasuredDimensionFromChildren(widthSpec, heightSpec) 这行代码的做用就是根据子控件的大小，设置 RecyclerView 的大小。至此，RecyclerView 的 measure 和 layout 实际上已经完成了。
可是，你有可能已经发现上面过程当中的问题了：如何肯定 RecyclerView 的可绘制空间？不过，若是你熟悉 android 控件的绘制机制的话，这就不是问题。其实，这里的可绘制空间，能够简单地理解为父容器的大小；更准确的描述是，父容器对 RecyclerView 的布局大小的要求，能够经过 MeasureSpec.getSize() 方法得到。
总结
到这里，关于 RecyclerView 的绘制流程就讲完了，因为主打绘制流程，没有分析其余，可能会致使整个逻辑有些跳跃，但不妨碍理解整个绘制过程。
最后回到文章前面的问题上，能够发现 RecyclerView 将绘制过程实际上是委托给 layoutManager 来操做，这和普通自定义 view 是很不同的。这样的灵活操做，可让使用者自定义各类样式，使得 RecyclerView 使用场景变得更加丰富。
其次在于分割线的处理上，它并不把分割线当作是子 view 来处理，而是在布局子 view 的时候，将分割线考虑进去给留下间隙。
参考文章
RecyclerView 源码分析(一) - RecyclerView的三大流程
Android中RecyclerView源码解析
- 1. RecyclerView 源码分析1-绘制流程
- 2. Android RecyclerView 解析之绘制流程篇
- 3. Android Render(四)supportVersion 27.0.0源码RecyclerView绘制流程解析
- 4. View绘制流程源码分析
- 5. 源码分析篇 - Android绘制流程（一）窗口启动流程分析
- 6. SeniorUI01_UI绘制流程分析（源码级分析）
- 7. RecyclerView 源码分析(一) - RecyclerView的三大流程
- 8. RecyclerView 源码深刻解析——绘制流程、缓存机制、动画等
- 9. RecyclerView 源码分析（一）：Recycler
- 10. RecyclerView源码分析(一) Recycler
- 更多相关文章...
- • XML DOM 解析器 - XML DOM 教程
- • Lua 流程控制 - Lua 教程
- • 互联网组织的未来：剖析GitHub员工的任性之源
- • Git五分钟教程
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 「插件」Runner更新Pro版，帮助设计师远离996
- 2. 错误 707 Could not load file or assembly ‘Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKe
- 3. Jenkins 2018 报告速览，Kubernetes使用率跃升235%！
- 4. TVI-Android技术篇之注解Annotation
- 5. android studio启动项目
- 6. Android的ADIL
- 7. Android卡顿的检测及优化方法汇总（线下+线上）
- 8. 登录注册的业务逻辑流程梳理
- 9. NDK(1)创建自己的C/C++文件
- 10. 小菜的系统框架界面设计-你的评估是我的决策
- 1. RecyclerView 源码分析1-绘制流程
- 2. Android RecyclerView 解析之绘制流程篇
- 3. Android Render(四)supportVersion 27.0.0源码RecyclerView绘制流程解析
- 4. View绘制流程源码分析
- 5. 源码分析篇 - Android绘制流程（一）窗口启动流程分析
- 6. SeniorUI01_UI绘制流程分析（源码级分析）
- 7. RecyclerView 源码分析(一) - RecyclerView的三大流程
- 8. RecyclerView 源码深刻解析——绘制流程、缓存机制、动画等
- 9. RecyclerView 源码分析（一）：Recycler
- 10. RecyclerView源码分析(一) Recycler