RecyclerView 源码分析（五）Adapter的源码分析

转载自琼珶和予

Adapter的源码分析

熟悉RecyclerView的同学应该都知道，Adapter作为RecyclerView四大组成部分(Adapter，LayoutManager，ItemAnimator，ItemDecoration)之一，其重要性自然是不言而喻。今天，我们来分析一下Adapter的源码。我打算将Adapter的源码分析分为两个部分，一是，从普通的角度上来看Adapter，从源码的角度上来分析我们日常使用的一些操作；二是，分析DiffUtil，可能会涉及到Adapter的部分源码。所以Adapter源码分析分为两篇，本文是第一篇。

1. 概述

在分析Adapter源码之前，我们先来回顾一下，我们经常使用的几个方法。

方法名	作用
onCreateViewHolder	创建一个ViewHolder对象，主要作用是将数据保存在ViewHolder，以供后面bind操作使用
onBindViewHolder	数据绑定方法
getItemCount	当前Adapter拥有数据的数量，该方法必须被重写，否则RecyclerView展示不了任何数据
getItemViewType	该方法带一个Position，主要是返回当前位置的ViewType。这个方法通常用于一个RecyclerView需要加载不同的布局。
getItemId	该方法表示的意思是返回当前位置Item的id，此方法只在setHasStableIds设置为true才会生效
setHasStableIds	设置当前RecyclerView的ItemView是否拥有固定id,跟getItemId方法一起使用。如果设置为true，会提高RecyclerView的缓存效率。

上表中所列的方法应该就是我们使用Adapter经常使用的方法，接下来，我将正式分析Adapter的相关代码。我打算从如下角度来分析：

1. 重新从RecyclerView缓存角度来分析onCreateViewHolder和onBindViewHolder。
2. onBindViewHolder的一个重载方法–主要是用于局部刷新。
3. 结合Adapter，分析ViewHolder的position。

1. onCreateViewHolder和onBindViewHolder

onCreateViewHolder方法和onBindViewHolder方法算是我们使用次数最多的方法，很多自定义Adapter的框架也都是从这两个方法入手的。我们来看看这两个方法到底有什么作用。

(1) onCreateViewHolder

首先，我们来看一下onCreateViewHolder方法，从它的调用时机入手。

在本文之前，我分析过RecyclerView的缓存机制，当时我将RecyclerView的缓存分为4级缓存，其中分别是：

• 一级缓存：scrap数组
• 二级缓存：CachedView
• 三级缓存：ViewCacheExtension
• 四级缓存：RecyclerViewPool

LayoutManager获取ViewHolder时，如果4级缓存都没有命中，就会调用Adapter的onCreateViewHolder方法来创建一个新的ViewHolder。我们来看看相关的代码：

if (holder == null) {
   
    long start = getNanoTime();
    if (deadlineNs != FOREVER_NS
            && !mRecyclerPool.willCreateInTime(type, start, deadlineNs)) {
   
        // abort - we have a deadline we can't meet
        return null;
    }
    holder = mAdapter.createViewHolder(RecyclerView.this, type);
    if (ALLOW_THREAD_GAP_WORK) {
   
        // only bother finding nested RV if prefetching
        RecyclerView innerView = findNestedRecyclerView(holder.itemView);
        if (innerView != null) {
   
            holder.mNestedRecyclerView = new WeakReference<>(innerView);
        }
    }

    long end = getNanoTime();
    mRecyclerPool.factorInCreateTime(type, end - start);
    if (DEBUG) {
   
        Log.d(TAG, "tryGetViewHolderForPositionByDeadline created new ViewHolder");
    }
}

上面的代码是RecyclerView的tryGetViewHolderForPositionByDeadline方法代码片段。之前，我们在分析缓存机制时，就已经仔细分析这个方法，这里我就不再赘述，有兴趣的同学可以之前的文章：RecyclerView 源码分析(三) - RecyclerView的缓存机制。

我们回到上面的代码片段中来，从上面的代码上，我们看到这里是调用的是Adapter的createViewHolder方法来创建ViewHolder。我们来看看Adapter的createViewHolder方法：

public final VH createViewHolder(@NonNull ViewGroup parent, int viewType) {
   
   try {
   
        TraceCompat.beginSection(TRACE_CREATE_VIEW_TAG);
        final VH holder = onCreateViewHolder(parent, viewType);
        if (holder.itemView.getParent() != null) {
   
            throw new IllegalStateException("ViewHolder views must not be attached when"
                    + " created. Ensure that you are not passing 'true' to the attachToRoot"
                    + " parameter of LayoutInflater.inflate(..., boolean attachToRoot)");
        }
        holder.mItemViewType = viewType;
        return holder;
    } finally {
   
        TraceCompat.endSection();
    }
}

其实createViewHolder方法里面也没有做什么的操作，差不多就是调用onCreateViewHolder方法。简而言之，onCreateViewHolder有点带兜底的韵味，缓存都没有命中，只能乖乖的创建ViewHolder。
  
我们来看看第二方法，也就是onBindViewHolder方法。

(2) onBindViewHolder

我们都知道，onBindViewHolder方法的作用是进行数据绑定，所以执行这个方法的条件相对于onCreateViewHolder有点苛刻。为什么呢？我们这