開始
最近在研究 RecyclerView 的回收復用機制，順便記錄一下。我們知道，RecyclerView 在 layout 子 View 時，都通過回收復用機制來管理。網(wǎng)上關于回收復用機制的分析講解的文章也有一大堆了，分析得也都很詳細，什么四級緩存啊，先去 mChangedScrap 取再去哪里取啊之類的；但其實，我想說的是，RecyclerView 的回收復用機制確實很完善，覆蓋到各種場景中，但并不是每種場景的回收復用時都會將機制的所有流程走一遍的。舉個例子說，在 setLayoutManager、setAdapter、notifyDataSetChanged 或者滑動時等等這些場景都會觸發(fā)回收復用機制的工作。但是如果只是 RecyclerView 滑動的場景觸發(fā)的回收復用機制工作時，其實并不需要四級緩存都參與的。
問題
假設有一個20個item的RecyclerView,每五個占滿一個屏幕，在從頭滑到尾的過程中，onCreatViewHolder會調(diào)用多少次？
正題
RecyclerView 的回收復用機制的內(nèi)部實現(xiàn)都是由 Recycler 內(nèi)部類實現(xiàn)，下面就都以這樣一種頁面的滑動場景來講解 RecyclerView 的回收復用機制。
相應的版本：
RecyclerView: recyclerview-v7-25.1.0.jar
LayoutManager: GridLayoutManager extends LinearLayoutManager (recyclerview-v7-25.1.0.jar)
這個頁面每行可顯示5個卡位，每個卡位的 item 布局 type 一致。開始分析回收復用機制之前，先提幾個問題：
Q1:如果向下滑動，新一行的5個卡位的顯示會去復用緩存的 ViewHolder，第一行的5個卡位會移出屏幕被回收，那么在這個過程中，是先進行復用再回收？還是先回收再復用？還是邊回收邊復用？也就是說，新一行的5個卡位復用的 ViewHolder 有可能是第一行被回收的5個卡位嗎？
回答問題之前，先看幾張圖片：
先向下再向上滑動
黑框表示屏幕，RecyclerView 先向下滑動，第三行卡位顯示出來，再向上滑動，第三行移出屏幕，第一行顯示出來。我們分別在 Adapter 的 onCreateViewHolder() 和 onBindViewHolder() 里打日志，下面是這個過程的日志：
紅框1是 RecyclerView 向下滑動操作的日志，第三行5個卡位的顯示都是重新創(chuàng)建的 ViewHolder ；紅框2是再次向上滑動時的日志，第一行5個卡位的重新顯示用的 ViewHolder 都是復用的，因為沒有 create viewHolder 的日志，然后只有后面3個卡位重新綁定數(shù)據(jù)，調(diào)用了onBindViewHolder()；那么問題來了：
Q2: 在這個過程中，為什么當 RecyclerView 再次向上滑動重新顯示第一行的5個卡位時，只有后面3個卡位觸發(fā)了 onBindViewHolder() 方法，重新綁定數(shù)據(jù)呢？明明5個卡位都是復用的。
在上面的操作基礎上，我們繼續(xù)往下操作：先向下再向下
在第二個問題操作的基礎上，目前已經(jīng)創(chuàng)建了15個 ViewHolder，此時顯示的是第1、2行的卡位，那么繼續(xù)向下滑動兩次，這個過程的日志如下：
紅框1是第二個問題操作的日志，在這里截出來只是為了顯示接下去的日志是在上面的基礎上繼續(xù)操作的；
紅框2就是第一次向下滑時的日志，對比問題2的日志，這次第三行的5個卡位用的 ViewHolder 也都是復用的，而且也只有后面3個卡位觸發(fā)了 onBindViewHolder() 重新綁定數(shù)據(jù)；
紅框3是第二次向下滑動時的日志，這次第四行的5個卡位，前3個的卡位用的 ViewHolder 是復用的，后面2個卡位的 ViewHolder 則是重新創(chuàng)建的，而且5個卡位都調(diào)用了 onBindViewHolder() 重新綁定數(shù)據(jù)；
Q3：接下去不管是向上滑動還是向下滑動，滑動幾次，都不會再有 onCreateViewHolder() 的日志了，也就是說 RecyclerView 總共創(chuàng)建了17個 ViewHolder，但有時一行的5個卡位只有3個卡位需要重新綁定數(shù)據(jù)，有時卻又5個卡位都需要重新綁定數(shù)據(jù)，這是為什么呢？
如果明白 RecyclerView 的回收復用機制，那么這三個問題也就都知道原因了；反過來，如果知道這三個問題的原因，那么理解 RecyclerView 的回收復用機制也就更簡單了；所以，帶著問題，在特定的場景下去分析源碼的話，應該會比較容易。
源碼分析
其實，根據(jù)問題2的日志，我們就可以回答問題1了。在目前顯示1、2行，ViewHolder 的個數(shù)為10個的基礎上，第三行的5個新卡位要顯示出來都需要重新創(chuàng)建 ViewHolder，也就是說，在這個向下滑動的過程，是5個新卡位的復用機制先進行工作，然后第1行的5個被移出屏幕的卡位再進行回收機制工作。那么，就先來看看復用機制的源碼。
復用機制
getViewForPosition()
//入口在這里
public View getViewForPosition(int position) {
return getViewForPosition(position, false);
}
View getViewForPosition(int position, boolean dryRun) {
return tryGetViewHolderForPositionByDeadline(position, dryRun, FOREVER_NS).itemView;
}
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
boolean dryRun, long deadlineNs) {
//復用機制工作原理都在這里
//...
}
這個方法是復用機制的入口，也就是 Recycler 開放給外部使用復用機制的api，外部調(diào)用這個方法就可以返回想要的 View，而至于這個 View 是復用而來的，還是重新創(chuàng)建得來的，就都由 Recycler 內(nèi)部實現(xiàn)，對外隱藏。
tryGetViewHolderForPositionByDeadline()
所以，Recycler 的復用機制內(nèi)部實現(xiàn)就在這個方法里。分析邏輯之前，先看一下 Recycler 的幾個結構體，用來緩存 ViewHolder 的。
public final class Recycler {
final ArrayList<ViewHolder> mAttachedScrap = new ArrayList<>();
ArrayList<ViewHolder> mChangedScrap = null;
//這個是本篇的重點
final ArrayList<ViewHolder> mCachedViews = new ArrayList<ViewHolder>();
private final List<ViewHolder>
mUnmodifiableAttachedScrap = Collections.unmodifiableList(mAttachedScrap);
private int mRequestedCacheMax = DEFAULT_CACHE_SIZE;
int mViewCacheMax = DEFAULT_CACHE_SIZE;
//這個也是本篇的重點
RecycledViewPool mRecyclerPool;
private ViewCacheExtension mViewCacheExtension;
static final int DEFAULT_CACHE_SIZE = 2;
}
mAttachedScrap：用于緩存顯示在屏幕上的 item 的 ViewHolder，場景好像是 RecyclerView 在 onLayout 時會先把 children 都移除掉，再重新添加進去，所以這個 List 應該是用在布局過程中臨時存放 children 的，反正在 RecyclerView 滑動過程中不會在這里面來找復用的 ViewHolder 就是了
mChangedScrap： 這個沒理解是干嘛用的，看名字應該跟 ViewHolder 的數(shù)據(jù)發(fā)生變化時有關吧，在 RecyclerView 滑動的過程中，也沒有發(fā)現(xiàn)到這里找復用的 ViewHolder，所以這個可以先暫時放一邊。
mCachedViews：這個就重要得多了，滑動過程中的回收和復用都是先處理的這個 List，這個集合里存的 ViewHolder 的原本數(shù)據(jù)信息都在，所以可以直接添加到 RecyclerView 中顯示，不需要再次重新 onBindViewHolder()。
mUnmodifiableAttachedScrap： 不清楚干嘛用的，暫時跳過。
mRecyclerPool：這個也很重要，但存在這里的 ViewHolder 的數(shù)據(jù)信息會被重置掉，相當于 ViewHolder 是一個重創(chuàng)新建的一樣，所以需要重新調(diào)用 onBindViewHolder 來綁定數(shù)據(jù)。
mViewCacheExtension：這個是留給我們自己擴展的，好像也沒怎么用，就暫時不分析了。
那么接下去就看看復用的邏輯：
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
boolean dryRun, long deadlineNs) {
if (position < 0 || position >= mState.getItemCount()) {
throw new IndexOutOfBoundsException("Invalid item position " + position
+ "(" + position + "). Item count:" + mState.getItemCount());
}
//...省略代碼
}
第一步很簡單，position 如果在 item 的范圍之外的話，那就拋異常吧。繼續(xù)往下看:
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
boolean dryRun, long deadlineNs) {
//...省略看過的代碼
boolean fromScrapOrHiddenOrCache = false;
ViewHolder holder = null;
// 0) If there is a changed scrap, try to find from there
//上面是Google留的注釋，大意是...(emmm，這里我也沒理解)
if (mState.isPreLayout()) {
holder = getChangedScrapViewForPosition(position);
fromScrapOrHiddenOrCache = holder != null;
}
}
如果是在 isPreLayout() 時，那么就去 mChangedScrap 中找。那么這個 isPreLayout 表示的是什么？共5有個賦值的地方。
//只顯示相關代碼，無關代碼省略
protected void onMeasure(int widthSpec, int heightSpec) {
if (mLayout.mAutoMeasure) {
//...
} else {
// custom onMeasure
if (mAdapterUpdateDuringMeasure) {
if (mState.mRunPredictiveAnimations) {
mState.mInPreLayout = true;
} else {
// consume remaining updates to provide a consistent state with the layout pass.
mAdapterHelper.consumeUpdatesInOnePass();
mState.mInPreLayout = false;
}
}
}
//...
mState.mInPreLayout = false; // clear
}
private void dispatchLayoutStep1() {
//...
mState.mInPreLayout = mState.mRunPredictiveAnimations;
//...
}
private void dispatchLayoutStep2() {
//...
mState.mInPreLayout = mState.mRunPredictiveAnimations;
mLayout.onLayoutChildren(mRecycler, mState);
//...
}
emmm，看樣子，在 LayoutManager 的 onLayoutChildren 前就會置為 false，不過我還是不懂這個過程是干嘛的，滑動過程中好像 mState.mInPreLayou = false，所以并不會來這里，先暫時跳過,繼續(xù)往下。
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
boolean dryRun, long deadlineNs) {
//...省略看過的代碼
// 1) Find by position from scrap/hidden list/cache
if (holder == null) {
//這里是第一次找可復用的ViewHolder了，得跟進去看看
holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun);
//...
}
}
跟進這個方法看看:
ViewHolder getScrapOrHiddenOrCachedHolderForPosition(int position,boolean dryRun) {
final int scrapCount = mAttachedScrap.size();
// Try first for an exact, non-invalid match from scrap.
for (int i = 0; i < scrapCount; i++) {
//首先去mAttachedScrap中遍歷尋找，匹配條件也很多
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 中尋找 position 一致的 viewHolder，需要匹配一些條件，大致是這個 viewHolder 沒有被移除，是有效的之類的條件，滿足就返回這個 viewHolder。所以，這里的關鍵就是要理解這個 mAttachedScrap 到底是什么，存的是哪些 ViewHolder。一次遙控器按鍵的操作，不管有沒有發(fā)生滑動，都會導致 RecyclerView 的重新 onLayout，那要 layout 的話，RecyclerView 會先把所有 children 先 remove 掉，然后再重新 add 上去，完成一次 layout 的過程。那么這暫時性的 remove 掉的 viewHolder 要存放在哪呢，就是放在這個 mAttachedScrap 中了，這就是我的理解了。所以，感覺這個 mAttachedScrap 中存放的 viewHolder 跟回收和復用關系不大。
網(wǎng)上一些分析的文章有說，RecyclerView 在復用時會按順序去 mChangedScrap, mAttachedScrap 等等緩存里找，沒有找到再往下去找，從代碼上來看是這樣沒錯，但我覺得這樣表述有問題。因為就我們這篇文章基于 RecyclerView 的滑動場景來說，新卡位的復用以及舊卡位的回收機制，其實都不會涉及到 mChangedScrap 和 mAttachedScrap，所以我覺得還是基于某種場景來分析相對應的回收復用機制會比較好。就像 mChangedScrap 我雖然沒理解是干嘛用的，但我猜測應該是在當數(shù)據(jù)發(fā)生變化時才會涉及到的復用場景，所以當我分析基于滑動場景時的復用時，即使我對這塊不理解，影響也不會很大。繼續(xù)向下看：
ViewHolder getScrapOrHiddenOrCachedHolderForPosition(int position,boolean dryRun) {
//...省略看過的代碼
if (!dryRun) {//dryRun一直為false
//這段代碼可看可不看
View view = mChildHelper.findHiddenNonRemovedView(position);
if (view != null) {
// This View is good to be used. We just need to unhide, detach and move to the
// scrap list.
final ViewHolder vh = getChildViewHolderInt(view);
mChildHelper.unhide(view);
int layoutIndex = mChildHelper.indexOfChild(view);
if (layoutIndex == RecyclerView.NO_POSITION) {
throw new IllegalStateException("layout index should not be -1 after "
+ "unhiding a view:" + vh);
}
mChildHelper.detachViewFromParent(layoutIndex);
scrapView(view);
vh.addFlags(ViewHolder.FLAG_RETURNED_FROM_SCRAP
| ViewHolder.FLAG_BOUNCED_FROM_HIDDEN_LIST);
return vh;
}
}
}
emmm，這段也還是沒看懂，但估計應該需要一些特定的場景下所使用的復用策略吧，看名字，應該跟 hidden 有關？不懂，跳過這段，應該也沒事，滑動過程中的回收復用跟這個應該也關系不大。
ViewHolder getScrapOrHiddenOrCachedHolderForPosition(int position,boolean dryRun) {
//...省略看過的代碼
// Search in our first-level recycled view cache.
//下面就是重點了，去mCachedViews里遍歷
final int cacheSize = mCachedViews.size();
for (int i = 0; i < cacheSize; i++) {
final ViewHolder holder = mCachedViews.get(i);
// invalid view holders may be in cache if adapter has stable ids as they can be
// retrieved via getScrapOrCachedViewForId
// 上面的大意是即使是失效的holser也有可能可以拿來復用，但需要我們重寫adapter的setHasStadleId并且提供一個id時，在getScrapOrCachedViewForId()里就可以再去mCachedViews里找一遍。
if (!holder.isInvalid() && holder.getLayoutPosition() == position) {
if (!dryRun) { //dryRun一直為false
mCachedViews.remove(i);//所以，如果position匹配，那么就將這個ViewHolder移除mCachedViews
}
if (DEBUG) {
Log.d(TAG, "getScrapOrHiddenOrCachedHolderForPosition(" + position
+ ") found match in cache: " + holder);
}
return holder;
}
return null;
}
這里就要畫重點啦，記筆記記筆記，滑動場景中的復用會用到這里的機制。mCachedViews 的大小默認為2。遍歷 mCachedViews，找到 position 一致的 ViewHolder，之前說過，mCachedViews 里存放的 ViewHolder 的數(shù)據(jù)信息都保存著，所以 mCachedViews 可以理解成，只有原來的卡位可以重新復用這個 ViewHolder，新位置的卡位無法從 mCachedViews 里拿 ViewHolder出來用。 找到 viewholder 后：
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
boolean dryRun, long deadlineNs) {
//...省略看過的代碼
// 1) Find by position from scrap/hidden list/cache
if (holder == null) {
//這里是第一次找可復用的ViewHolder了，得跟進去看看
holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun);
//之前分析跟進了上面那個方法，找到ViewHolder后
if (holder != null) {
//需要再次驗證一下這個ViewHodler是否可以拿來復用
if (!validateViewHolderForOffsetPosition(holder)) {
// recycle holder (and unscrap if relevant) since it can't be used
if (!dryRun) {
// we would like to recycle this but need to make sure it is not used by
// animation logic etc.
//如果不能復用，就把它要么仍到mAttachedScrap或者扔到ViewPool里
holder.addFlags(ViewHolder.FLAG_INVALID);
if (holder.isScrap()) {
removeDetachedView(holder.itemView, false);
holder.unScrap();
} else if (holder.wasReturnedFromScrap()) {
holder.clearReturnedFromScrapFlag();
}
recycleViewHolderInternal(holder);
}
holder = null;
} else {
fromScrapOrHiddenOrCache = true;
}
}
}
}
就算 position 匹配找到了 ViewHolder，還需要判斷一下這個 ViewHolder 是否已經(jīng)被 remove 掉，type 類型一致不一致，如下:
boolean validateViewHolderForOffsetPosition(ViewHolder holder) {
// if it is a removed holder, nothing to verify since we cannot ask adapter anymore
// if it is not removed, verify the type and id.
if (holder.isRemoved()) {
if (DEBUG && !mState.isPreLayout()) {
throw new IllegalStateException("should not receive a removed view unless it"
+ " is pre layout");
}
return mState.isPreLayout();
}
if (holder.mPosition < 0 || holder.mPosition >= mAdapter.getItemCount()) {
throw new IndexOutOfBoundsException("Inconsistency detected. Invalid view holder "
+ "adapter position" + holder);
}
//如果type類型不一樣，那就不能復用
if (!mState.isPreLayout()) {
// don't check type if it is pre-layout.
final int type = mAdapter.getItemViewType(holder.mPosition);
if (type != holder.getItemViewType()) {
return false;
}
}
if (mAdapter.hasStableIds()) {
return holder.getItemId() == mAdapter.getItemId(holder.mPosition);
}
return true;
}
以上是在 mCachedViews 中尋找，沒有找到的話，就繼續(xù)再找一遍，剛才是通過 position 來找，那這次就換成id，然后重復上面的步驟再找一遍，如下:
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
boolean dryRun, long deadlineNs) {
//...省略看過的代碼
if (holder == null) {
final int offsetPosition = mAdapterHelper.findPositionOffset(position);
if (offsetPosition < 0 || offsetPosition >= mAdapter.getItemCount()) {
throw new IndexOutOfBoundsException("http://省略...");
}
final int type = mAdapter.getItemViewType(offsetPosition);
// 2) Find from scrap/cache via stable ids, if exists
if (mAdapter.hasStableIds()) {//如果有設置stableIs，就再從Scrap和cached里根據(jù)id找一次
holder = getScrapOrCachedViewForId(mAdapter.getItemId(offsetPosition),
type, dryRun);
if (holder != null) {
// update position
holder.mPosition = offsetPosition;
fromScrapOrHiddenOrCache = true;
}
}
//省略之后步驟，后續(xù)分析...
}
}
getScrapOrCachedViewForId() 做的事跟 getScrapOrHiddenOrCacheHolderForPosition() 其實差不多，只不過一個是通過 position 來找 ViewHolder，一個是通過 id 來找。而這個 id 并不是我們在 xml 中設置的 android:id， 而是 Adapter 持有的一個屬性，默認是不會使用這個屬性的，所以這里其實是不會執(zhí)行的，除非我們重寫了 Adapter 的 setHasStableIds()，既然不是常用的場景，那就先略過吧，那就繼續(xù)往下。
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
boolean dryRun, long deadlineNs) {
//...省略看過的代碼
if (holder == null) {
final int offsetPosition = mAdapterHelper.findPositionOffset(position);
//省略無關代碼...
final int type = mAdapter.getItemViewType(offsetPosition);
//省略上述步驟跟getScrapOrCachedViewForId()相關的代碼...
//這里開始就又去另一個地方找了，ViewCacheExtension
if (holder == null && mViewCacheExtension != null) {
// We are NOT sending the offsetPosition because LayoutManager does not
// know it.
final View view = mViewCacheExtension
.getViewForPositionAndType(this, position, type);
if (view != null) {
holder = getChildViewHolder(view);
if (holder == null) {
throw new IllegalArgumentException("getViewForPositionAndType returned" + " a view which does not have a ViewHolder");
} else if (holder.shouldIgnore()) {
throw new IllegalArgumentException("getViewForPositionAndType returned" + " a view that is ignored. You must call stopIgnoring before" + " returning this view.");
}
}
}
//省略之后步驟，后續(xù)分析...
}
}
這個就是常說擴展類了，RecyclerView 提供給我們自定義實現(xiàn)的擴展類，我們可以重寫 getViewForPositionAndType() 方法來實現(xiàn)自己的復用策略。不過，也沒用過，那這部分也當作不會執(zhí)行，略過。繼續(xù)往下:
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
boolean dryRun, long deadlineNs) {
//...省略看過的代碼
if (holder == null) {
final int offsetPosition = mAdapterHelper.findPositionOffset(position);
//省略無關代碼...
final int type = mAdapter.getItemViewType(offsetPosition);
//省略看過的的代碼...
//這里開始就又去另一個地方找了，RecycledViewPool
if (holder == null) { // fallback to pool
if (DEBUG) {
Log.d(TAG, "tryGetViewHolderForPositionByDeadline("+ position + ") fetching from shared pool");
}
//跟進這個方法看看
holder = getRecycledViewPool().getRecycledView(type);
if (holder != null) {
//如果在ViewPool里找到可復用的ViewHolder，那就重置ViewHolder的數(shù)據(jù)，這樣ViewHolder就可以當作全新的來使用了
holder.resetInternal();
if (FORCE_INVALIDATE_DISPLAY_LIST) {
invalidateDisplayListInt(holder);
}
}
}
//省略之后步驟，后續(xù)分析...
}
}
這里也是重點了，記筆記記筆記。這里是去 RecyclerViewPool 里取 ViewHolder，ViewPool 會根據(jù)不同的 item type 創(chuàng)建不同的 List，每個 List 默認大小為5個?？匆幌氯?ViewPool 里是怎么找的:
public ViewHolder getRecycledView(int viewType) {
//根據(jù)type，只要不為空，就將最后一個ViewHolder移出來復用
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;
}
之前說過，ViewPool 會根據(jù)不同的 viewType 創(chuàng)建不同的集合來存放 ViewHolder，那么復用的時候，只要 ViewPool 里相同的 type 有 ViewHolder 緩存的話，就將最后一個拿出來復用，不用像 mCachedViews 需要各種匹配條件，只要有就可以復用。拿到 ViewHolder 之后，還會再次調(diào)用 resetInternal() 來重置 ViewHolder，這樣 ViewHolder 就可以當作一個全新的 ViewHolder 來使用了，這也就是為什么從這里拿的 ViewHolder 都需要重新 onBindViewHolder() 了。那如果在 ViewPool 里還是沒有找到呢，繼續(xù)往下看：
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
boolean dryRun, long deadlineNs) {
//...省略看過的代碼
if (holder == null) {
final int offsetPosition = mAdapterHelper.findPositionOffset(position);
//省略無關代碼...
final int type = mAdapter.getItemViewType(offsetPosition);
//省略看過的的代碼...
//都沒找到的話，就調(diào)用Adapter.onCreateAdapter()來新建一個ViewHolder了
if (holder == null) {
//省略無關代碼...
holder = mAdapter.createViewHolder(RecyclerView.this, type);//新建一個ViewHolder
//省略無關代碼...
}
}
//省略之后步驟，后續(xù)分析
}
如果 ViewPool 中都沒有找到 ViewHolder 來使用的話，那就調(diào)用 Adapter 的 onCreateViewHolder 來創(chuàng)建一個新的 ViewHolder 使用。上面一共有很多步驟來找 ViewHolder，不管在哪個步驟，只要找到 ViewHolder 的話，那下面那些步驟就不用管了，然后都要繼續(xù)往下判斷是否需要重新綁定數(shù)據(jù)，還有檢查布局參數(shù)是否合法。如下：
ViewHolder tryGetViewHolderForPositionByDeadline(int position,
boolean dryRun, long deadlineNs) {
//...省略上述分析的找ViewHolder的代碼...
//代碼執(zhí)行到這里，ViewHolder肯定不為Null了，因為就算在各個緩存里沒找到，最后一步也會重新創(chuàng)建一個
boolean bound = false;
if (mState.isPreLayout() && holder.isBound()) {
// do not update unless we absolutely have to.
holder.mPreLayoutPosition = position;
} else if (!holder.isBound() || holder.needsUpdate() || holder.isInvalid()) {
if (DEBUG && holder.isRemoved()) {
throw new IllegalStateException("Removed holder should be bound and it should" + " come here only in pre-layout. Holder: " + holder);
}
final int offsetPosition = mAdapterHelper.findPositionOffset(position);
//調(diào)用Adapter.onBindViewHolder()來重新綁定數(shù)據(jù)
bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs);
}
//下面是驗證itemView的布局參數(shù)是否可用，并設置可用的布局參數(shù)
final ViewGroup.LayoutParams lp = holder.itemView.getLayoutParams();
final LayoutParams rvLayoutParams;
if (lp == null) {
rvLayoutParams = (LayoutParams) generateDefaultLayoutParams();
holder.itemView.setLayoutParams(rvLayoutParams);
} else if (!checkLayoutParams(lp)) {
rvLayoutParams = (LayoutParams) generateLayoutParams(lp);
holder.itemView.setLayoutParams(rvLayoutParams);
} else {
rvLayoutParams = (LayoutParams) lp;
}
rvLayoutParams.mViewHolder = holder;
rvLayoutParams.mPendingInvalidate = fromScrapOrHiddenOrCache && bound;
return holder;
//結束
}
到這里，tryGetViewHolderForPositionByDeadline() 這個方法就結束了。這大概就是 RecyclerView 的復用機制，中間我們跳過很多地方，因為 RecyclerView 有各種場景可以刷新他的 view，比如重新 setLayoutManager()，重新 setAdapter()，或者 notifyDataSetChanged()，或者滑動等等之類的場景，只要重新layout，就會去回收和復用 ViewHolder，所以這個復用機制需要考慮到各種各樣的場景。把代碼一行行的啃透有點吃力，所以我就只借助 RecyclerView 的滑動的這種場景來分析它涉及到的回收和復用機制。下面就分析一下回收機制 。
回收機制
回收機制的入口就有很多了，因為 Recycler 有各種結構體，比如mAttachedScrap，mCachedViews 等等，不同結構體回收的時機都不一樣，入口也就多了。所以，還是基于 RecyclerView 的滑動場景下，移出屏幕的卡位回收時的入口是：
//回收入口之一
public void recycleView(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();
}
//回收的內(nèi)部實現(xiàn)，跟進看看
recycleViewHolderInternal(holder);
}
本篇分析的滑動場景，在 RecyclerView 滑動時，會交由 LinearLayoutManager 的 scrollVerticallyBy() 去處理，然后 LayoutManager 會接著調(diào)用 fill() 方法去處理需要復用和回收的卡位，最終會調(diào)用上述 recyclerView() 這個方法開始進行回收工作。
void recycleViewHolderInternal(ViewHolder holder) {
//省略代碼...
if (forceRecycle || holder.isRecyclable()) {
//mViewCacheMax大小默認為2
if (mViewCacheMax > 0 /*省略其他條件*/) {
// Retire oldest cached view
int cachedViewSize = mCachedViews.size();
//回收時，先將ViewHolder緩存在mCachedViews里，如果滿了，調(diào)用recycleCachedViewAt(0)移除一個，好空出位置來
if (cachedViewSize >= mViewCacheMax && cachedViewSize > 0) {
recycleCachedViewAt(0);
cachedViewSize--;
}
//省略無關代碼...
//將最近剛剛回收的ViewHolder放在mCachedViews里
mCachedViews.add(targetCacheIndex, holder);
cached = true;
}
if (!cached) {
//如果設置不用mCachedViewd緩存的話，那回收時就扔進ViewPool里等待復用
addViewHolderToRecycledViewPool(holder, true);
recycled = true;
}
}
//省略無關代碼...
}
跟進 recycleCachedViewAt(0) 方法看看：
void recycleCachedViewAt(int cachedViewIndex) {
if (DEBUG) {
Log.d(TAG, "Recycling cached view at index " + cachedViewIndex);
}
ViewHolder viewHolder = mCachedViews.get(cachedViewIndex);
if (DEBUG) {
Log.d(TAG, "CachedViewHolder to be recycled: " + viewHolder);
}
//將mCachedViews里緩存的ViewHolder取出來，扔進ViewPool里緩存
addViewHolderToRecycledViewPool(viewHolder, true);
mCachedViews.remove(cachedViewIndex);
}
繼續(xù)跟進 addViewHolderToRecycledViewPool() 里看看，這個方法在上上代碼塊里也出現(xiàn)
void addViewHolderToRecycledViewPool(ViewHolder holder, boolean dispatchRecycled) {
clearNestedRecyclerViewIfNotNested(holder);
ViewCompat.setAccessibilityDelegate(holder.itemView, null);
if (dispatchRecycled) {
//這個方法會去回調(diào)Adapter里的onViewRecycle()，所以Adapter接收到該回調(diào)時是ViewHolder被扔進ViewPool里才會觸發(fā)的
//如果ViewHolder只是被mCachedViews緩存了，那Adapter的onViewRecycle()是不會回調(diào)的，所以不是所有被移出屏幕的item都會觸發(fā)onViewRecycle()方法的
dispatchViewRecycled(holder);
}
holder.mOwnerRecyclerView = null
//在扔進ViewPool前回調(diào)一些方法，并對ViewHolder的一些標志置位，然后繼續(xù)跟進看看
getRecycledViewPool().putRecycledView(holder);
}
在 ViewHolder 扔進 ViewPool 里之前，會先去回調(diào) Adapter 里的 onViewRecycle()，所以 Adapter 接收到該回調(diào)時是 ViewHolder 被扔進 ViewPool 里才會觸發(fā)的。如果 ViewHolder 只是被 mCachedViews 緩存了，那 Adapter 的 onViewRecycle() 是不會回調(diào)的，所以不是所有被移出屏幕的 item 都會觸發(fā) onViewRecycle() 方法的，這點需要注意一下。繼續(xù)跟進看看 ：
public void putRecycledView(ViewHolder scrap) {
final int viewType = scrap.getItemViewType();
final ArrayList scrapHeap = getScrapDataForType(viewType).mScrapHeap;
if (mScrap.get(viewType).mMaxScrap <= scrapHeap.size()) {
//如果ViewPool滿了，就不緩存了，默認大小為5
return;
}
if (DEBUG && scrapHeap.contains(scrap)) {
throw new IllegalArgumentException("this scrap item already exists");
}
//緩存前先將ViewHolder的信息重置，這樣ViewHolder下次被拿出來復用時就可以當作全新的ViewHolder來使用了
scrap.resetInternal();
scrapHeap.add(scrap);
}
所以，ViewHolder 在扔進 ViewPool 前會先 reset，這里的重置指的是 ViewHolder 保存的一些信息，比如 position，跟它綁定的 RecycleView 啊之類的，并不會清空 itemView，所以復用時才會經(jīng)常出現(xiàn) itemView 顯示之前卡位的圖片信息之類的情況，這點需要區(qū)分一下。
回收的邏輯比較簡單，由 LayoutManager 來遍歷移出屏幕的卡位，然后對每個卡位進行回收操作，回收時，都是把 ViewHolder 放在 mCachedViews 里面，如果 mCachedViews 滿了，那就在 mCachedViews 里拿一個 ViewHolder 扔到 ViewPool 緩存里，然后 mCachedViews 就可以空出位置來放新回收的 ViewHolder 了。
總結
RecyclerView 滑動場景下的回收復用涉及到的結構體兩個：mCachedViews 和 RecyclerViewPool。
mCachedViews 優(yōu)先級高于 RecyclerViewPool，回收時，最新的 ViewHolder 都是往 mCachedViews 里放，如果它滿了，那就移出一個扔到 ViewPool 里好空出位置來緩存最新的 ViewHolder。
復用時，也是先到 mCachedViews 里找 ViewHolder，但需要各種匹配條件，概括一下就是只有原來位置的卡位可以復用存在 mCachedViews 里的 ViewHolder，如果 mCachedViews 里沒有，那么才去 ViewPool 里找。
在 ViewPool 里的 ViewHolder 都是跟全新的 ViewHolder 一樣，只要 type 一樣，有找到，就可以拿出來復用，重新綁定下數(shù)據(jù)即可。
整體的流程圖如下：
最后，解釋一下開頭的問題
Q1:如果向下滑動，新一行的5個卡位的顯示會去復用緩存的 ViewHolder，第一行的5個卡位會移出屏幕被回收，那么在這個過程中，是先進行復用再回收？還是先回收再復用？還是邊回收邊復用？也就是說，新一行的5個卡位復用的 ViewHolder 有可能是第一行被回收的5個卡位嗎？
答：先復用再回收，新一行的5個卡位先去目前的 mCachedViews 和 ViewPool 的緩存中尋找復用，沒有就重新創(chuàng)建，然后移出屏幕的那行的5個卡位再回收緩存到 mCachedViews 和 ViewPool 里面，所以新一行5個卡位和復用不可能會用到剛移出屏幕的5個卡位。
Q2: 在這個過程中，為什么當 RecyclerView 再次向上滑動重新顯示第一行的5個卡位時，只有后面3個卡位觸發(fā)了 onBindViewHolder() 方法，重新綁定數(shù)據(jù)呢？明明5個卡位都是復用的。
答：滑動場景下涉及到的回收和復用的結構體是 mCachedViews 和 ViewPool，前者默認大小為2，后者為5。所以，當?shù)谌酗@示出來后，第一行的5個卡位被回收，回收時先緩存在 mCachedViews，滿了再移出舊的到 ViewPool 里，所有5個卡位有2個緩存在 mCachedViews 里，3個緩存在 ViewPool，至于是哪2個緩存在 mCachedViews，這是由 LayoutManager 控制。上面講解的例子使用的是 GridLayoutManager，滑動時的回收邏輯則是在父類 LinearLayoutManager 里實現(xiàn)，回收第一行卡位時是從后往前回收，所以最新的兩個卡位是0、1，會放在 mCachedViews 里，而2、3、4的卡位則放在 ViewPool 里。
所以，當再次向上滑動時，第一行5個卡位會去兩個結構體里找復用，之前說過，mCachedViews 里存放的 ViewHolder 只有原本位置的卡位才能復用，所以0、1兩個卡位都可以直接去 mCachedViews 里拿 ViewHolder 復用，而且這里的 ViewHolder 是不用重新綁定數(shù)據(jù)的，至于2、3、4卡位則去 ViewPool 里找，剛好 ViewPool 里緩存著3個 ViewHolder，所以第一行的5個卡位都是用的復用的，而從 ViewPool 里拿的復用需要重新綁定數(shù)據(jù)，才會這樣只有三個卡位需要重新綁定數(shù)據(jù)。
Q3：接下去不管是向上滑動還是向下滑動，滑動幾次，都不會再有 onCreateViewHolder() 的日志了，也就是說 RecyclerView 總共創(chuàng)建了17個 ViewHolder，但有時一行的5個卡位只有3個卡位需要重新綁定數(shù)據(jù)，有時卻又5個卡位都需要重新綁定數(shù)據(jù)，這是為什么呢？
答：有時一行只有3個卡位需要重新綁定的原因跟Q2一樣，因為 mCachedView 里正好緩存著當前位置的 ViewHolder，本來就是它的 ViewHolder 當然可以直接拿來用。而至于為什么會創(chuàng)建了17個 ViewHolder，那是因為再第四行的卡位要顯示出來時，ViewPool 里只有3個緩存，而第四行的卡位又用不了 mCachedViews 里的2個緩存，因為這兩個緩存的是6、7卡位的 ViewHolder，所以就需要再重新創(chuàng)建2個 ViewHodler 來給第四行最后的兩個卡位使用。
