起因
RV在几乎在所有的有界面的Android应用都会使用到，可以说日常开发中RV是老熟人天天见，可是仔细想想熟悉它的什么呢？熟悉的是怎么去使用，对于它的内部原理太过陌生。曾经多次点看它的源码，但都迷失在成千上万的代码与注释中。幸好网上还有很多关于RV优秀的文章，让我能抓住RV的一些重点，其中一个重点就是它对viewHolder的回收与复用机制，关于这一块网上很多文章已经分析过了，Recycler、四级缓存等等，但我还是有一个疑问，在什么操作下会将什么viewHolder放到哪一个缓存？由于RV源码太复杂了😭，下面就带着这个疑问片面地分析下它的缓存设计。
Recycler与RecyclerPool类
Recycler类是RV的一个内部类，正如它的名字一样它是负责回收的，在它的内部定义了好几种关于回收的成员变量,先熟悉一下
public final class Recycler {
final ArrayList<ViewHolder> mAttachedScrap = new ArrayList<>();
ArrayList<ViewHolder> mChangedScrap = null;
final ArrayList<ViewHolder> mCachedViews = new ArrayList<ViewHolder>();
RecycledViewPool mRecyclerPool;
private ViewCacheExtension mViewCacheExtension;
static final int DEFAULT_CACHE_SIZE = 2;
}
有三种类型为ViewHolder的ArrayList，显然它们是都是用来缓存不同时机的ViewHolder的，接下来是一个类成员RecycledViewPool，它的代码如下
public static class RecycledViewPool {
private static final int DEFAULT_MAX_SCRAP = 5;
static class ScrapData {
//回收list
final ArrayList<ViewHolder> mScrapHeap = new ArrayList<>();
int mMaxScrap = DEFAULT_MAX_SCRAP;
long mCreateRunningAverageNs = 0;
long mBindRunningAverageNs = 0;
}
SparseArray<ScrapData> mScrap = new SparseArray<>();
private ScrapData getScrapDataForType(int viewType) {
ScrapData scrapData = mScrap.get(viewType);
if (scrapData == null) {
scrapData = new ScrapData();
mScrap.put(viewType, scrapData);
}
return scrapData;
}
/**
* Acquire a ViewHolder of the specified type from the pool, or {@code null} if none are
* present.
*
* @param viewType ViewHolder type.
* @return ViewHolder of the specified type acquired from the pool, or {@code null} if none
* are present.
*/
@Nullable
public ViewHolder getRecycledView(int viewType) {
final ScrapData scrapData = mScrap.get(viewType);
if (scrapData != null && !scrapData.mScrapHeap.isEmpty()) {
final ArrayList<ViewHolder> scrapHeap = scrapData.mScrapHeap;
return scrapHeap.remove(scrapHeap.size() - 1);
}
return null;
}
/**
* Add a scrap ViewHolder to the pool.
* <p>
* If the pool is already full for that ViewHolder's type, it will be immediately discarded.
*
* @param scrap ViewHolder to be added to the pool.
*/
public void putRecycledView(ViewHolder scrap) {
final int viewType = scrap.getItemViewType();
final ArrayList<ViewHolder> scrapHeap = getScrapDataForType(viewType).mScrapHeap;
if (mScrap.get(viewType).mMaxScrap <= scrapHeap.size()) {
return;
}
if (DEBUG && scrapHeap.contains(scrap)) {
throw new IllegalArgumentException("this scrap item already exists");
}
scrap.resetInternal();
scrapHeap.add(scrap);
}
}
在它内部还有一个静态内部类ScrapData，ScrapData类中出现了ArrayList<ViewHolder>，显然又是用来保存ViewHolder的，但为什么要单独设计一个类中呢，再看看下面一行，定义了一个SparseArray<ScrapData>，SparseArray是一个Android特有的类，类似于HashMap，但它的key只能是int，结合RecycledViewPool的put和get方法可以知道，SparseArray中的key就是RV中的itemType，并且每个itemType最多保存5个，所以，在RecycledViewPool中viewHolder是按照它们的类型来分别保存的，这一点也提醒了我：之前那三个缓存是不分类型的！
ViewHolder类
这是一个在开发中经常使用的类，日常使用中也就是在继承ViewHolder，在其中保存itemView的子View，但今天关注的点不一样，在ViewHolder中定义了很多关于ViewHolder状态的常量，主要的几个如下
/**
* This ViewHolder has been bound to a position; mPosition, mItemId and mItemViewType
* are all valid.
*/
static final int FLAG_BOUND = 1 << 0;
/**
* The data this ViewHolder's view reflects is stale and needs to be rebound
* by the adapter. mPosition and mItemId are consistent.
*/
static final int FLAG_UPDATE = 1 << 1;
/**
* This ViewHolder's data is invalid. The identity implied by mPosition and mItemId
* are not to be trusted and may no longer match the item view type.
* This ViewHolder must be fully rebound to different data.
*/
static final int FLAG_INVALID = 1 << 2;
/**
* This ViewHolder points at data that represents an item previously removed from the
* data set. Its view may still be used for things like outgoing animations.
*/
static final int FLAG_REMOVED = 1 << 3;
/**
* This ViewHolder should not be recycled. This flag is set via setIsRecyclable()
* and is intended to keep views around during animations.
*/
static final int FLAG_NOT_RECYCLABLE = 1 << 4;
int mFlags;
void addFlags(int flags) {
mFlags |= flags;
}
- FLAG_BOUND：viewHolder与RV中POSITION绑定了，就是调用了onBindViewHolder方法吧
- FLAG_INVALID：onBindViewHolder的数据失效了，需要重新绑定
- FLAG_UPDATE：viewHolder的view需要重新更新数据
关于缓存的一些关键的类介绍完了，接下来开始分析具体的使用场景中这几个缓存是怎么发挥作用的
调用setAdapter方法
setAdapter这个方法可以多次调用，第一次调用显然没有任何缓存可言，这里只考虑第一次调用后再次调用的情况，如下
//=====RecyclerView中
public void setAdapter(@Nullable Adapter adapter) {
// bail out if layout is frozen
setLayoutFrozen(false);
setAdapterInternal(adapter, false, true);
processDataSetCompletelyChanged(false);
requestLayout();
}
private void setAdapterInternal(@Nullable Adapter adapter, boolean compatibleWithPrevious,
boolean removeAndRecycleViews) {
if (mAdapter != null) {
mAdapter.unregisterAdapterDataObserver(mObserver);
mAdapter.onDetachedFromRecyclerView(this);
}
if (!compatibleWithPrevious || removeAndRecycleViews) {
removeAndRecycleViews();
}
mAdapterHelper.reset();
final Adapter oldAdapter = mAdapter;
mAdapter = adapter;
if (adapter != null) {
adapter.registerAdapterDataObserver(mObserver);
adapter.onAttachedToRecyclerView(this);
}
if (mLayout != null) {
mLayout.onAdapterChanged(oldAdapter, mAdapter);
}
mRecycler.onAdapterChanged(oldAdapter, mAdapter, compatibleWithPrevious);
mState.mStructureChanged = true;
}
/**
* Removes and recycles all views - both those currently attached, and those in the Recycler.
*/
void removeAndRecycleViews() {
......
mRecycler.clear();
}
setAdapter会调用setAdapterInternal(adapter, false, true)方法，从中可以看到RV和Adapter之间是观察者模式，每一次的setAdapter都是RV反过来订阅了Adapter，Adapter通过各种notify**通知RV数据更新。这个方法后面传入的两个参数是字面意思都很好理解，第一个是否和上一个Adapter的类型兼容，第二个是否移除回收views，compatibleWithPrevious为false，所以会调用removeAndRecycleViews方法，在这个方法中又会调用Rcycler的clear方法，好了这就进入正题了，下面看看这个方法
//=====Recycler中
public void clear() {
//清空mAttachedScrap
mAttachedScrap.clear();
recycleAndClearCachedViews();
}
void recycleAndClearCachedViews() {
final int count = mCachedViews.size();
for (int i = count - 1; i >= 0; i--) {
recycleCachedViewAt(i);
}
mCachedViews.clear();
......
}
void recycleCachedViewAt(int cachedViewIndex) {
ViewHolder viewHolder = mCachedViews.get(cachedViewIndex);
addViewHolderToRecycledViewPool(viewHolder, true);
mCachedViews.remove(cachedViewIndex);
}
void addViewHolderToRecycledViewPool(@NonNull ViewHolder holder, boolean dispatchRecycled) {
......
getRecycledViewPool().putRecycledView(holder);
}
一系列的调用可以发现，首先会移除RV中所有的view（代码不贴了，这里只关注回收相关的），然后清空了mAttachedScrap，然后将mCachedViews中的viewholder移动到了RecycledViewPool，之后清空mCachedViews中的viewholder，此时只有RecyclerViewPool中有缓存，但感觉不对，已经换Adapter了所有数据都会变，万一旧的Adapter和新的Adapter的itemType有一样的但viewHolder不一样，那还是会从Pool中去取viewHolder，岂不是会崩？多虑了～回到setAdapterInternal方法中会发现这里最后还调用了mRecycler.onAdapterChanged方法，如下
void onAdapterChanged(Adapter oldAdapter, Adapter newAdapter,
boolean compatibleWithPrevious) {
if (oldAdapter != null) {
detach(); //mAttachCount--
}
if (!compatibleWithPrevious && mAttachCount == 0) {
clear();
}
if (newAdapter != null) {
attach();//mAttachCount++
}
}
public void clear() {
for (int i = 0; i < mScrap.size(); i++) {
ScrapData data = mScrap.valueAt(i);
data.mScrapHeap.clear();
}
}
由于一个RecyclerViewPool可以设置给多个RV，mAttachCount表示这个Pool关联的RV的数量，当mAttachCount为0时就清空Pool中的所有的viewHolder，所以最后三种缓存都给清空了，如图所示：
调用setAdapter方法缓存的更新就分析完了，可以总结为：
- 不给RV设置RecyclerViewPool的情况下，如果重新setAdapter会清空所有的三级缓存
- 如果单独设置RecyclerViewPool，并且多个RV同时在使用，会将viewHolder移动最多5个到RecyclerViewPool
调用notifyDataChanged方法
在日常使用中一旦给RV设置了Adapter，一般都不会去再次设置adapter，更多时候是调用Adapter的notify***方法更新数据，现在就来分析一下调用notifyDataChanged时缓存的情况。刚才提到过RV与Adapter之间是观察者模式，Adapter是被观察者、RV是观察者,当我们调用adapter的notifyDataChanged时最后会调用到RV内部的RecyclerViewDataObserver的onChanged方法，如下
//==RecyclerView中
private class RecyclerViewDataObserver extends AdapterDataObserver {
RecyclerViewDataObserver() {
}
@Override
public void onChanged() {
assertNotInLayoutOrScroll(null);
mState.mStructureChanged = true;
processDataSetCompletelyChanged(true);
if (!mAdapterHelper.hasPendingUpdates()) {
requestLayout();
}
}
}
void processDataSetCompletelyChanged(boolean dispatchItemsChanged) {
mDispatchItemsChangedEvent |= dispatchItemsChanged;
mDataSetHasChangedAfterLayout = true;
markKnownViewsInvalid();
}
void markKnownViewsInvalid() {
//getUnfilteredChildCount（）： Returns the total number of children.
final int childCount = mChildHelper.getUnfilteredChildCount();
for (int i = 0; i < childCount; i++) {
final ViewHolder holder = getChildViewHolderInt(mChildHelper.getUnfilteredChildAt(i));
if (holder != null && !holder.shouldIgnore()) {
holder.addFlags(ViewHolder.FLAG_UPDATE | ViewHolder.FLAG_INVALID);
}
}
markItemDecorInsetsDirty();
mRecycler.markKnownViewsInvalid();
}
//==Recycler中
void markKnownViewsInvalid() {
final int cachedCount = mCachedViews.size();
for (int i = 0; i < cachedCount; i++) {
final ViewHolder holder = mCachedViews.get(i);
if (holder != null) {
holder.addFlags(ViewHolder.FLAG_UPDATE | ViewHolder.FLAG_INVALID);
holder.addChangePayload(null);
}
}
if (mAdapter == null || !mAdapter.hasStableIds()) {
// we cannot re-use cached views in this case. Recycle them all
recycleAndClearCachedViews();
}
}
最后会调用到RV的markKnownViewsInvalid方法，在这里会取出所有被添加到RV中viewHoder，然后给它们添加上ViewHolder.FLAG_UPDATE和ViewHolder.FLAG_INVALID的FLAG，这两个标记上面介绍了，标记这个viewHolder的数据、位置失效，接着又调用Recycler的同名方法将mCachedViews中的viewHolder标记为失效，然后再调用recycleAndClearCachedViews方法，这个方法上面也提到过，就是将mCachedViews中的viewHolder移动到了RecyclerViewPool中去。
此刻可以总结为：RV中添加的viewHoder仍然在，但被打了标记，mAttachedScrap为空，mCachedViews为空，RecyclerViewPool中可能有缓存。
回到onChanged方法中，最后会调用requestLayout重新布局，requestLayout会触发RV重新measure、layout、draw，在layout的时候将所有的布局都交给了LayoutManager，调用它的onLayoutChildren方法，以LinearLayoutManager为例，在真正进行布局之前会调用detachAndScrapAttachedViews方法，顾名思义就是要detach掉RV中所有的viewHolder
//==LinearLayoutManager中
public void detachAndScrapAttachedViews(@NonNull Recycler recycler) {
final int childCount = getChildCount();
for (int i = childCount - 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);
.......
//成立
if (viewHolder.isInvalid() && !viewHolder.isRemoved()
&& !mRecyclerView.mAdapter.hasStableIds()) {
removeViewAt(index);
recycler.recycleViewHolderInternal(viewHolder);
} else {
detachViewAt(index);
recycler.scrapView(view);
mRecyclerView.mViewInfoStore.onViewDetached(viewHolder);
}
}
//==Recycler中
void recycleViewHolderInternal(ViewHolder holder) {
.......
boolean cached = false;
boolean recycled = false;
.......
if (forceRecycle || holder.isRecyclable()) {
//不成立
if (mViewCacheMax > 0
&& !holder.hasAnyOfTheFlags(ViewHolder.FLAG_INVALID
| ViewHolder.FLAG_REMOVED
| ViewHolder.FLAG_UPDATE
| ViewHolder.FLAG_ADAPTER_POSITION_UNKNOWN)) {
// Retire oldest cached view
int cachedViewSize = mCachedViews.size();
if (cachedViewSize >= mViewCacheMax && cachedViewSize > 0) {
recycleCachedViewAt(0);
cachedViewSize--;
}
int targetCacheIndex = cachedViewSize;
......
mCachedViews.add(targetCacheIndex, holder);
cached = true;
}
if (!cached) {//成立
addViewHolderToRecycledViewPool(holder, true);
recycled = true;
}
} else {
.....
}
....
}
这一系列的调用中会根据viewHolder的flag将它放到不同的缓存中去，这时这些被标记的viewHolder的flags会导致它被RV移除并被移动到RecyclerViewPool中去，如图所示：
到这里就明确了在调用notifyDataChanged的时候，RV中所有的viewHolder都会标记失效并被移除到RecyclerPool中去，mCachedView、mAttchedView都为空。
调用notifyItemChanged方法
和notifyDataChanged调用一样，调用链如下
//==RV中
@Override
public void onItemRangeChanged(int positionStart, int itemCount, Object payload) {
assertNotInLayoutOrScroll(null);
if (mAdapterHelper.onItemRangeChanged(positionStart, itemCount, payload)) {
triggerUpdateProcessor();
}
}
//==AdapterHelper中
boolean onItemRangeChanged(int positionStart, int itemCount, Object payload) {
if (itemCount < 1) {
return false;
}
mPendingUpdates.add(obtainUpdateOp(UpdateOp.UPDATE, positionStart, itemCount, payload));
mExistingUpdateTypes |= UpdateOp.UPDATE;
return mPendingUpdates.size() == 1;
}
//AdapterHelper中，mCallback是RV
private void postponeAndUpdateViewHolders(UpdateOp op) {
if (DEBUG) {
Log.d(TAG, "postponing " + op);
}
mPostponedList.add(op);
switch (op.cmd) {
case UpdateOp.ADD:
mCallback.offsetPositionsForAdd(op.positionStart, op.itemCount);
break;
case UpdateOp.MOVE:
mCallback.offsetPositionsForMove(op.positionStart, op.itemCount);
break;
case UpdateOp.REMOVE:
mCallback.offsetPositionsForRemovingLaidOutOrNewView(op.positionStart, op.itemCount);
break;
case UpdateOp.UPDATE:
mCallback.markViewHoldersUpdated(op.positionStart, op.itemCount, op.payload);
break;
default:
throw new IllegalArgumentException("Unknown update op type for " + op);
}
}
//==RV中
@Override
public void markViewHoldersUpdated(int positionStart, int itemCount, Object payload) {
viewRangeUpdate(positionStart, itemCount, payload);
mItemsChanged = true;
}
void viewRangeUpdate(int positionStart, int itemCount, Object payload) {
final int childCount = mChildHelper.getUnfilteredChildCount();
final int positionEnd = positionStart + itemCount;
for (int i = 0; i < childCount; i++) {
final View child = mChildHelper.getUnfilteredChildAt(i);
final ViewHolder holder = getChildViewHolderInt(child);
if (holder == null || holder.shouldIgnore()) {
continue;
}
if (holder.mPosition >= positionStart && holder.mPosition < positionEnd) {
// We re-bind these view holders after pre-processing is complete so that
// ViewHolders have their final positions assigned.
holder.addFlags(ViewHolder.FLAG_UPDATE);
holder.addChangePayload(payload);
// lp cannot be null since we get ViewHolder from it.
((LayoutParams) child.getLayoutParams()).mInsetsDirty = true;
}
}
mRecycler.viewRangeUpdate(positionStart, itemCount);
}
AdapterHelper的onItemRangeChanged将这个更新事件添加到一个排队执行的List中，triggerUpdateProcessor或者其他事件会触发List的中的事件被执行，不管怎么调用最后都会调用到AdapterHelper的postponeAndUpdateViewHolders，在这里会将需要更新的viewHolder标记为ViewHolder.FLAG_UPDATE，这些都是在RV真正开始布局之前调用的，之后会走正常的layout流程，又以LienarLayoutManager为例，还是会调用detachAndScrapAttachedViews，但这次只有需要更新的viewHolder被标记为FLAG_UPDATE了，其他都没有格外标记，回收的逻辑如下
//==RV中
private void scrapOrRecycleView(Recycler recycler, int index, View view) {
final ViewHolder viewHolder = getChildViewHolderInt(view);
.......
if (viewHolder.isInvalid() && !viewHolder.isRemoved()
&& !mRecyclerView.mAdapter.hasStableIds()) {
removeViewAt(index);
recycler.recycleViewHolderInternal(viewHolder);
} else {//成立
detachViewAt(index);
recycler.scrapView(view);
mRecyclerView.mViewInfoStore.onViewDetached(viewHolder);
}
}
//==Recycler中
void scrapView(View view) {
final ViewHolder holder = getChildViewHolderInt(view);
//对不需要更新的viewHolder成立
if (holder.hasAnyOfTheFlags(ViewHolder.FLAG_REMOVED | ViewHolder.FLAG_INVALID)
|| !holder.isUpdated() || canReuseUpdatedViewHolder(holder)) {
//不成立
if (holder.isInvalid() && !holder.isRemoved() && !mAdapter.hasStableIds()) {
throw new IllegalArgumentException("Called scrap view with an invalid view."
+ " Invalid views cannot be reused from scrap, they should rebound from"
+ " recycler pool." + exceptionLabel());
}
holder.setScrapContainer(this, false);
mAttachedScrap.add(holder);
} else { //对需要更新的viewHolder成立
if (mChangedScrap == null) {
mChangedScrap = new ArrayList<ViewHolder>();
}
holder.setScrapContainer(this, true);
mChangedScrap.add(holder);
}
}
RV中所有的viewHolder都会被detach，对不需要更新的viewHolder放到了mAttachedScrap中，对需要更新的viewHolder是放到了mChangedScrap中，其他的缓存没有变，如图所示：
调用notifyItemInserted方法
和notifyItemChanged一样，在layout之前会执行AdapterHelper中的postponeAndUpdateViewHolders，这次是UpdateOp.ADD了，所以会调用RV的offsetPositionsForAdd，如下：
@Override
public void offsetPositionsForAdd(int positionStart, int itemCount) {
offsetPositionRecordsForInsert(positionStart, itemCount);
mItemsAddedOrRemoved = true;
}
void offsetPositionRecordsForInsert(int positionStart, int itemCount) {
final int childCount = mChildHelper.getUnfilteredChildCount();
for (int i = 0; i < childCount; i++) {
final ViewHolder holder = getChildViewHolderInt(mChildHelper.getUnfilteredChildAt(i));
if (holder != null && !holder.shouldIgnore() && holder.mPosition >= positionStart) {
if (DEBUG) {
Log.d(TAG, "offsetPositionRecordsForInsert attached child " + i + " holder "
+ holder + " now at position " + (holder.mPosition + itemCount));
}
//改变ViewHolder的位置
holder.offsetPosition(itemCount, false);
mState.mStructureChanged = true;
}
}
mRecycler.offsetPositionRecordsForInsert(positionStart, itemCount);
requestLayout();
}
//==ViewHolder中
void offsetPosition(int offset, boolean applyToPreLayout) {
if (mOldPosition == NO_POSITION) {
mOldPosition = mPosition;
}
if (mPreLayoutPosition == NO_POSITION) {
mPreLayoutPosition = mPosition;
}
if (applyToPreLayout) {
mPreLayoutPosition += offset;
}
mPosition += offset;
if (itemView.getLayoutParams() != null) {
((LayoutParams) itemView.getLayoutParams()).mInsetsDirty = true;
}
}
这个过程只是改变了ViewHolder的位置，没有改变它的状态，参考刚才对notifyItemChanged的分析，RV重新layout时也只是将所有的viewHolder detach了，然后放进mAttachedScrap中，只是这一次viewHolder中代表位置的mPosition值发生了变化。
滑动
具体的分析参见RecyclerView缓存机制（回收些啥？)
可以概括为：在滑动的时候 ，触发RV的onTouchEvent，在它的ACTION_MOVE中，如果这个滑动被认为是一次SCROLL_STATE_DRAGGING就会将这个滑动事件转发给LayoutMamager，以LinearLayoutManager为例，会调用其中的fill方法去添加新的viewHolder到RV中，同时也会detach和回收掉滑出屏幕的viewHolder，fill方法中会依次调用新的item的measure和layout方法，最后在scrollBy方法中会移动所有的item，导致item的invalidate被调用，绘制view。
对滑出屏幕的viewHoler会调用recycleChildren回收，如下：
//==RV中
private void recycleChildren(RecyclerView.Recycler recycler, int startIndex, int endIndex) {
if (startIndex == endIndex) {
return;
}
if (DEBUG) {
Log.d(TAG, "Recycling " + Math.abs(startIndex - endIndex) + " items");
}
if (endIndex > startIndex) {
for (int i = endIndex - 1; i >= startIndex; i--) {
removeAndRecycleViewAt(i, recycler);
}
} else {
for (int i = startIndex; i > endIndex; i--) {
removeAndRecycleViewAt(i, recycler);
}
}
}
public void removeAndRecycleViewAt(int index, @NonNull Recycler recycler) {
final View view = getChildAt(index);
//detach
removeViewAt(index);
recycler.recycleView(view);
}
//==Recycler中
public void recycleView(@NonNull View view) {
// This public recycle method tries to make view recycle-able since layout manager
// intended to recycle this view (e.g. even if it is in scrap or change cache)
ViewHolder holder = getChildViewHolderInt(view);
if (holder.isTmpDetached()) {
removeDetachedView(view, false);
}
if (holder.isScrap()) {
holder.unScrap();
} else if (holder.wasReturnedFromScrap()) {
holder.clearReturnedFromScrapFlag();
}
recycleViewHolderInternal(holder);
}
移出屏幕的viewHolder会被detach，然后调用Recycler的recycleView方法回收，这里又调用到了
recycleViewHolderInternal方法，这次会被放到mCachedView中去，如果mCachedView满了就把以前的发到Pool中去，再把这个viewHolder放进mCachedView中。
复用
前面提到过在LinearLayoutManager的fill方法会去添加新的viewHolder到RV中，那这个viewHolder从哪里来呢？显然是要从缓存中获取的，Recycler提供了一个叫tryGetViewHolderForPositionByDeadline的方法获取缓存的viewHolder，具体分析请看
RecyclerView缓存机制（咋复用？）
可以概括为： RV在每一次需要为某个位置添加viewHolder的时候都会通过这个方法去获取viewHolder，首先是根据position在mAttchScrap中去寻找，没有再根据position去mCachedViews中寻找，如果找到了直接返回使用，没有再去RecyclerViewPool中根据itemType寻找。
参考：
Android ListView与RecyclerView对比浅析--缓存机制
RecyclerView缓存机制
