RecyclerView 源码分析(五) - 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级缓存，其中分别是：

1. 一级缓存：scrap数组
2. 二级缓存：CachedView
3. 三级缓存：ViewCacheExtension
4. 四级缓存：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有点苛刻。为什么呢？我们这么想一下吧，假设我们change了其中一个ItemView的数据，然后通过notifyItemChanged来通知数据源已经改变。在这种情况下，正常来说，都是只刷新对应位置的ItemView就行了，没必要刷新其他数据没有改变的ItemView(这里的刷新就是指执行onBindViewHolder方法)。现在，我们来看看对应的执行代码：

            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
                            + exceptionLabel());
                }
                final int offsetPosition = mAdapterHelper.findPositionOffset(position);
                bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs);
            }

  从上面的代码，我们可以看出来，最后调用了tryBindViewHolderByDeadline方法。而调用tryBindViewHolderByDeadline方法条件比较苛刻，不过不管怎么苛刻，只要记住一点，如果对应位置的数据被更新了，该位置会执行一次onBindViewHolder方法。我们继续看一下tryBindViewHolderByDeadline方法的代码：

        private boolean tryBindViewHolderByDeadline(ViewHolder holder, int offsetPosition,
                int position, long deadlineNs) {
            // ······
            mAdapter.bindViewHolder(holder, offsetPosition);
            // ······
        }

  执行过程跟onCreateViewHolder方法差不多，都是在依靠Adapter内部一个对应的final方法来回调。这样所做的好处，可以在onBindViewHolder方法执行前后做一些其他的操作，比如初始化操作和清理操作，这种模式有点类似于Java中静态代理模式中的继承代理。然后，我们来看看Adapter的bindViewHolder方法:

        public final void bindViewHolder(@NonNull VH holder, int position) {
            holder.mPosition = position;
            if (hasStableIds()) {
                holder.mItemId = getItemId(position);
            }
            holder.setFlags(ViewHolder.FLAG_BOUND,
                    ViewHolder.FLAG_BOUND | ViewHolder.FLAG_UPDATE | ViewHolder.FLAG_INVALID
                            | ViewHolder.FLAG_ADAPTER_POSITION_UNKNOWN);
            TraceCompat.beginSection(TRACE_BIND_VIEW_TAG);
            onBindViewHolder(holder, position, holder.getUnmodifiedPayloads());
            holder.clearPayload();
            final ViewGroup.LayoutParams layoutParams = holder.itemView.getLayoutParams();
            if (layoutParams instanceof RecyclerView.LayoutParams) {
                ((LayoutParams) layoutParams).mInsetsDirty = true;
            }
            TraceCompat.endSection();
        }

  从这里，我们可以简单发现，在执行onBindViewHolder方法前后，各自做了一些不同的操作。比如，在执行onBindViewHolder方法之前，更新了ViewHolder的mPosition属性和给ViewHolder设置了一些flag；在执行onBindViewHolder方法之后，清理了ViewHolder的payload，并且还是给ItemView的LayoutParams的mInsetsDirty属性设置为true。
  这里额外的提出两个点:

1. payload主要是用于局部刷新的，待会我会详细解释怎么进行局部刷新。
2. 关于LayoutParams的mInsetsDirty属性，这个属性尤为重要的，主要用于ItemView的绘制，后续我在分析ItemDecoration时会详细的解释这个属性。

3. 局部刷新的基本使用和实现原理

(1). 局部刷新的基本使用

  在分析局部刷新之前，我们先来讨论一下怎么进行布局刷新，也就是说怎么通过RecyclerView实现ItemView的局部刷新。
  假设下面的一个Demo：

  点击一下下面灰色的Button，position为0的ItemView会改变显示的文字。如果我们不做局部刷新，出现什么问题呢？我们先来试试：

        mDataList.get(0).setString("change data");
        mAdapter.notifyItemChanged(0);

  正常的实现应该就是上面的代码，非常的简单，也是我们经常书写的代码。这样书写有什么问题吗？有很大的问题！就是整个ItemView会闪烁一下，效果如下：

  网上给了一堆的原因分析，我个人觉得，原因非常的简单，就是第一个ItemView执行的change动画。所以介于这两个原因，我们可以找到两种解决方案：

1. 设置RecyclerView的change动画时间为0，也就是调用ItemAnimator的setChangeDuration方法。
2. 直接将RecyclerView的ItemAnimator设置为null。

  对于第二种方案，我不置可否。这样来想，我们直接将动画设置为null，那么RecyclerView就没有任何动画，是不是感觉有点得不偿失？
  第一种方案比起第二种方案稍微要好一些，我们将change动画时间设置为0，只影响了change动画(相当于取消了change动画)，不会影响其他其他操作的动画。不过，还是感觉美中不足，相当于后面所有的change操作都没有了动画，如果我想有些change操作有动画呢？
  此时就需要局部刷新出手了。我们先来看看怎么实现局部刷新：
  首先，调用带两个参数的notifyItemChanged方法，如下：

        mAdapter.notifyItemChanged(0, "");

  第二参数是一个payload，Object类型，所以我们可以传递任意对象，这里就传递一个空字符串。
  然后我们得重写Adapter的onBindViewHolder方法(这里重写的是带三个参数的onBindViewHolder方法，带两个参数的onBindViewHolder该怎么写就怎么写)。

    @Override
    public void onBindViewHolder(@NonNull RecyclerViewHolder holder, int position, @NonNull List