RecyclerView自定义添加Header和Footer
前段时间写了一个自定义添加Header和Footer的Demo，在运行的时候发现了一个问题，当foot数量或是head的数量超过5个的时候复用就会失败，于是看了一下RecyclerView的源码
RecyclerView大致可以为分为这么几个部分
当然， RecyclerView怎么可能只有这么点东西呢，它里面也包括了处理动画的ItemAnimator，滑动监听的OnScrollListener等等，但是这次我的目的是为了查看复用的问题，所以重点放在了Recycler和RecyclerPool身上
RecyclerView中ViewHolder的创建和绑定数据都在一个方法里面进行，那就是tryGetViewHolderForPositionByDeadline方法，而这个方法位于Recycler类中，
先看看Recycler里面一些重要的属性
Recycler
mAttachedScrap和mChangedScrap:这两个我决定放在一起说， 因为我在查找他们添加的时候都只找到一处，在#scrapView方法中，那么scrapView方法什么时候会被调用呢，第一个会在scrapOrRecycleView的时候会调用，scrapOrRecycleView又只有在detachAnd***方法的时候
而且由此可见，mAttachedScrap和mChangedScrap这两个状态还处于一个相对的关系，我的理解是当有一个View不可见的时候但是有没有被Remove掉，就会被添加到mAttachedScrap（但是不可见之后不是应该拉去复用了吗。。。所以不是很懂这个）。
而mChangedScrap添加的条件是:（!holder.hasAnyOfTheFlags(12) && holder.isUpdated() && !RecyclerView.this.canReuseUpdatedViewHolder(holder)）第一个我不知道，但是第二个是。。。需要更新？第三个里面判断的是ItemAnimator==null，所以这个保存的是需要更新但是不可见的ViewHolder？？？ （我猜的我猜的我猜的，猜错别打我）
第二个调用时机在后面说
mCacheViews:这个就比较重要了，滑动的时候回收和复用都会先从这里去查找，且保存在这里的ViewHolder数据没有被清空，也就是说不需要重新执行onBind方法
mUnmodifiableAttachedScrap：不知道干嘛的，在创建Recycler实例的时候调用Collections.unmodifiableList（mAttachedScrap）给他赋了值
mRecyclerPool：也是很重要的, 保存ViewHolder，但是个mCacheViews里的不同，保存到Pool里的ViewHolder将被完全重置，也就是说从Pool拿出来服用的话，需要重新执行onBind方法
mViewCacheExtension:给开发者自定义缓存策略的
再来看一下核心方法，onCreate#onBind以及复用和回收都会走这里
tryGetViewHolderForPositionByDeadline方法
首先看第12行的getScrapOrHiddenOrCachedHolderForPosition方法，
跟进代码内
红框上的for循环不用管。。我测了好久好像也没测出来mAttachedScrap的size不为0
红框内第一个横线就是寻找被隐藏了并且没有被Remove掉的View，如果view!=null的时候，那么必定会走到scrapView中。
这里有个疑问，ViewHolder的不可见也分两份，一种是当ViewHolder被移出屏幕外的时候，一种是手动setVisibility的时候，所以这里的mAttachedScrap里面存储的会不会就是看不见的但是没有被移除的View呢？？
再看这个方法后剩余的代码
如果你的RecyclerView还没有经历过回收的话那么这个mChcheViews的size肯定是为0的。
如果有holder之后，下面一系列关于holder==null的判定方法肯定是不走了，但是就算找到了holder，还会在执行下方的validateViewHolderForOffsetPosition方法，跟进一下
还会在判断当前holder有没有被remove啊，type会不会不一致啊
那么如果在查找缓存的时候也没找到呢，那么在看下一个方法
你懂我意思吧，这个方法就是根据id和type去寻找viewholder
上面一部分代码和之前获取缓存holder的代码差不多，毕竟前戏都是获取holder，找不到才去创建
再看这个方法，这个方法99%的概率不会走， 因为99%的开发者都不会重写缓存策略的！但是如果你有重写的话，那么。。。你懂的
这就是复用的最后一步了，如果在Pool里面还没有找到的话，那么就只能去创建了，如果找到了就会执行这个方法做一些初始化
接下去没有缓存的地方了只能去创建了
这个方法就是创建viewholder的方法了，里面实际调用的就是this.onCreateViewHolder, 也就是我们写Adapter要重写的哪个onCreateViewHolder
现在直接去看onBind的代码，也是这个方法最后的一点代码了
会执行tryBindViewHolderByDeadline方法，在跟进一下这个方法，点进bindViewHolder后终于看到了onBindViewHolder这个熟悉的名字，只要能够走到这一步，不出意外，那么最终都会返回true回去，最后在红框内会给当前的holder的itemView设置默认的LayoutParams, 在将他赋值给rvLayoutParams.mViewHolder，这个LayoutParams也是RecyclerView内的。到这一步，一个viewholder终于被构建出来了。。。 历经坎坷啊
在看一看Pool的代码
RecyclerPool
RecyclerPool的代码并不多，就一百多行，只有三个属性，第一个是默认缓存大小，第一个mScrap是一个ArrayList，里面存放了一个ScrapData，第三个就不知道了。。。可能和刚开始的mAttachedScrap有关？
看看ScrapData代码
mScrapHeap是什么呢？实际上mScrapHeap里面存储的才是待复用的VoiwHolder，我们再回到外部类RecyclerPool，看看get方法是怎么找到holder的
根据Type去mScrap里寻找合适的ScrapData，如果scrapData==null, 就构建一个新的并且put到mScrap中。
再看看put方法是怎么样的
根据Type先去获取对应的mScrapHeap，如果默认缓存两>mScrapHeap.size的话，那么这个holder就会被初始化，在put进去，这个holder就是个空壳，需要重新oBind的
总结一下：
创建or复用：当RecyclerView滑动的时候，首先会去mCacheViews根据position里面查找是否有可以复用的holder，有的话就直接用， 没的话会再去mCacheViews寻找一边，只不过上次是根据position，这次是根据id和type，再找不到的话就到Pool里面去寻找了。如果都没有，那就会去onCreateViewHolder，最后执行onBindViewHolder，这就是一个ViewHolder的产生过程。
回收：当ViewHolder被一处屏幕后会先进入mCacheViews中，如果mCacheViews中满了，就会把他丢到Pool中。如果Pool也满了，就不缓存了。当然这个Pool默认缓存的大小是可以设置的
另外值得一提：RecyclerPool中的默认缓存如果手动设置后，那么会根据传入的Type将这个缓存集合取出放到一个新集合中，缓存大小就是自己设置的大小，并且会清除原有的holder。
就不分析回收复用的具体实现了，大致流程是RecyclerView在滑动的时候会执行LayoutManager的 scrollVerticallyBy() 去处理，调用fill方法，在fill里面最终会调用recycleViewHolderInternal(holder)方法对holder进行回收和复用卡位
说了这么多。。。我最后解决复用的问题还是设置了默认缓存大小，让他直接缓存了我所有的foot
总觉得这样设置并不好，还在慢慢摸索新的方案