寫在前面：

在上篇文章中說過對于像 RecyclerView 或者 ListView 等等此類在有限屏幕中展示大量內(nèi)容的控件，復用的邏輯就是其核心的邏輯，而關于復用導致最常見的 bug 就是復用錯亂。在大上周我就遇到了一個很奇怪的問題，這也是我下決心研究 RecyclerView 的原因。

RecyclerView 源碼分析

而這篇文章的目的首先是討論在 RecyclerView 復用錯亂時，一些通用的解決思路，其次就是探究我遇到的那個奇怪的問題，幫助未來同樣遇到的朋友們。

復用錯亂的解決辦法

本文的前半部分很簡單的，以為關于復用錯亂，RecyclerView 已經(jīng)有他的前輩 ListView 替它踩了很多坑了。雖然他們的復用邏輯是有差異的，例如 ListView 只有兩層緩存，但是 RecyclerView 可以理解為有四層；ListView 緩存的單位是 view，而 RecyclerView 緩存的單位是 ViewHolder。但是不管他們復用邏輯的差異如何，終歸都是把那個緩存起來的 view 拿過來接著用，所以解決復用錯亂的方法是一樣的。

RecyclerView 復用導致錯亂的原因其實就是拿出來之前的 View 來添加到新 item 上，之前 View 的狀態(tài)一直保留著，所以也就錯亂了。不過解決起來很簡單：

首先我們以 adapter 數(shù)據(jù)的來源分為兩大類：

1.當數(shù)據(jù)來源是同步的

這種情況是最簡單的，你就保證當 onBindViewHolder 方法調(diào)用的時候，你的 itemview 中每個 view 的狀態(tài)都有一個默認值。這是什么意思呢？

    if ("<unknown>".equals(artists)) {
      holder.cbMusicState.setChecked(true);
    } else {
      holder.cbMusicState.setChecked(false);
    }

假設我們的 holder 里面有個 Checkbox 控件，當歌手名為 unknown 時，Checkbox 勾選。注意個時候你一定要加上這個 else 條件，才能保證復用這個 ViewHolder 的時候，Checkbox 的狀態(tài)不出錯。任何控件都一樣，總結起來就是你要給每個控件的狀態(tài)賦一個新的值，替換掉之前的，這樣自然不會出現(xiàn)什么復用錯亂的問題。

2.當數(shù)據(jù)的來源是異步的

這種情況也很常見，我們舉個栗子，比如你的 ItemView 里面有個 ImageView，每次 onBindViewHolder 的時候，你傳入一個 url，等待服務器返回的結果，然后展示在 ImageView 上。這種情況會怎樣導致錯亂呢？

是這樣的，假設我進入了頁面，開始為第一個 ImageView 請求圖片，但是此刻我下劃屏幕，劃到了第四個 item，此時第一個 item 已經(jīng)不可見了，第四個 item 復用了第一個 item 的 imageview，恰好此刻第一個 imageview 的圖片結果返回了，就正好展示在了第四個 itemview 上。 這樣就發(fā)生了圖片的錯亂。

出現(xiàn)這個問題的原因就是這個 ImageView 和請求的 url 沒一一綁定，所以按照這個思路來解決吧：

  holder.ivCameraImages.setBackground(R.drawable.place_holder);
  
  holder.ivCameraImages.setTag(imageURL);

    @Override
    public void handleMessage(Message msg) {
      super.handleMessage(msg);
      if (msg.what == MSG_IMAGE) {
        Bitmap bm = (Bitmap) msg.obj;
        if (bm != null) {
          if (TextUtils.equals((String) imageView.getTag(), imageURL)) {
            imageView.setBackground(new BitmapDrawable(bm));
          }
        }
      }
    }

首先在沒加載圖片之前，給 ImageView 設置一個默認圖片，然后通過 setTag 方法，將 ImageView 和 圖片的 url 一一對應起來，設置的時候再判斷一下，這個 imageview 的 tag 和當時請求的 url，是不是一致的，如果是一致的，再保存。

以上就是復用錯亂時兩種比較通用的解法，基本上可以覆蓋大部分情況。

一個奇怪的問題

這個問題的現(xiàn)象是這樣子的：

當 RecyclerView 的條目很少的時候，比如只有六個，將 RecyclerView 從上滑動到下，這個時候是正常的，onBindViewHolder 會調(diào)用，不過此時從底部上劃的時候，上方的 item 從不可見到可見的這個過程中，onBindViewHolder 并沒有調(diào)用，這個時候我也就沒辦法進行一些刷新 item 的操作了。

這個問題的原因是 onBindViewHolder 方法不調(diào)用導致的，我在 StackOverflow 上搜索了很多答案，終于找到了一個可以解決我的問題的：

recyclerview-not-recycling-views-if-the-view-count-is-small

（中文資料壓根就沒有，所以掌握英文搜索是多么的重要）

你可以調(diào)用

recyclerView.setItemViewCacheSize(int);

這個 api，去調(diào)整 RecyclerView 的復用邏輯和方式來解決 onBindViewHolder 沒有調(diào)用的這個問題。

但是原理是怎樣的呢？作為一名好奇心頗重的程序員，一步步 debug RecyclerView 的源代碼，發(fā)現(xiàn)了導致這個問題的原因，一起來看看吧。

在上一篇文章中，我們分析了 RecyclerView 的源碼，其中復用邏輯的模塊，有一個非常重要的核心方法 tryBindViewHolderByDeadline，這個方法目的就是在 RecyclerView 的層層緩存結構中，取出 ViewHolder。

這里就不再次研究它了，想了解的去看之前的文章，我來描述一下對于這個場景，簡化之后的邏輯：

當 RecyclerView 從底部向上滑動的時候，會先后從 mCachedViews 和 mRecyclerPool 中尋找緩存的 ViewHolder。

mCachedViews 和 mRecyclerPool 之間又有什么關系呢？

    public void setViewCacheSize(int viewCount) {
      mRequestedCacheMax = viewCount;
      updateViewCacheSize();
    }

    void updateViewCacheSize() {
      int extraCache = mLayout != null ? mLayout.mPrefetchMaxCountObserved : 0;
      mViewCacheMax = mRequestedCacheMax + extraCache;

      // first, try the views that can be recycled
      for (int i = mCachedViews.size() - 1;
          i >= 0 && mCachedViews.size() > mViewCacheMax; i--) {
        recycleCachedViewAt(i);
      }
    }

當調(diào)用 setViewCacheSize 這個方法時，相當于是給 mViewCacheMax 這個變量賦值了， for 循環(huán)調(diào)用 recycleCachedViewAt 的作用是將 mCachedViews 中緩存的 ViewHolder 放進 RecyclerPool 中?？梢钥吹?for 循環(huán)的周期是從 mCachedViews 的最后一個對象直到 mCachedViews.size == mViewCacheMax 這個值時。

也就是可以這么理解， setViewCacheSize 這個方法其實就是為 mCachedViews 集合設置所能持有 ViewHolder 的最大數(shù)量。

當  setViewCacheSize(0)時，RecyclerView 想去復用 ViewHolder 時，只能去 RecyclerPool 中去取了，這里就有問題來了，從 RecyclerPool 中取和從 mCachedViews 中取 ViewHolder 中又有什么區(qū)別呢？

        if (holder == null) { // fallback to pool
          if (DEBUG) {
            Log.d(TAG, "tryGetViewHolderForPositionByDeadline("
                + position + ") fetching from shared pool");
          }
          holder = getRecycledViewPool().getRecycledView(type);
          if (holder != null) {
            holder.resetInternal();
            if (FORCE_INVALIDATE_DISPLAY_LIST) {
              invalidateDisplayListInt(holder);
            }
          }
        }

當從 RecyclerPool 取出 ViewHolder 時，調(diào)用了 resetInternal 這個函數(shù)的作用是清空一些記錄的參數(shù)，包括之前記錄 ViewHolder 狀態(tài)的 mFlags。

 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);
        bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs);
      }

代碼再往下走的時候，剛剛清空的 flag 參數(shù)這個時候就用到了，holder.isBound() 返回 flase，進入 if 判斷，調(diào)用 tryBindViewHolderByDeadline 進而調(diào)用了 onBindViewHolder。

到這里這個邏輯就描述清楚了，所以設置 setViewCacheSize 來調(diào)整 mCachedViews 保存 ViewHolder 的大小，就能解決問題。

當然有些特殊的情況，某些位置就不能調(diào)用 onBindViewHolder，沒關系，可以監(jiān)聽 RecyclerView 的滑動，當滑動停止的時候，再調(diào)用 notify 刷新下列表也是可以的。

好了本文到這里就結束了~希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論