RecycleView：再见前任（Listview）
一. 缓存机制
说到RecycleView，我们第一反应就是崇拜强大的谷歌，然后就是我那些年钟爱的Listview，Grideview是不是要说再见了。也许吧，如果这个时候还不舍得再见，看完这篇文章，自己玩一个项目后，估计就会勇敢的说再见了。
有关如何下笔本人还是喜欢拿“前任”说事，把ListView拉出来，我们再对比下，进行一次客观公正的选择吧。
先说说listview的缓存：
说明：上图是个简单的应用场景形象，对应用而言在列表当中我们只会看到可见的view和不可见的View两种，那么对于这两种view的切换，不应该是每一次都重新绘制，这样就太不可取了。于是就出现了缓存机制，所谓缓存我就不多说了，大家只需要记住目的就是为了更快的展现就可以了。因此在Listview当中便出现了两级缓存：
mActivieViews:
顾名思义，当前活跃的View。用于屏幕内的item快速重用，不需要重新回调oncreate和bindView，生命周期都在onlayout里面。
mScrapViews:
与其相反，这是是处理离屏的item，离开屏幕的view会被缓存到这里，可见的时候从里来取，不需要回调oncreate，但是需要重新bingview就是重新绑定view，但是一旦adapter发生改变，这里的view将被彻底清除，也就是这级缓存将被清空。
Lisiview的缓存就这么简单，具体如何做到的有兴趣的可以看下源码，因为这次的主角是RecycleView，有关前任的知识点我就一概而过了，毕竟说多了现任是不会喜欢的。
谷歌大神一般推出的‘现任’之所以很快让大家跟前任提出分手，确实是因为他把前任整的太强大了，例如RecycleView针对于Listview的两级缓存，他则是有四级缓存。
懒得再画图了，先盗一张图：
前两级缓存和listview的mActiveviews缓存猛一看差别不大，唯一的差别就在于Recycleview多了一个么Recyclepool来进行保护性的管理。很有兴趣想看看源码，那就来吧：
先看他们在源码中的定义：
final ArrayList mAttachedScrap = new ArrayList<>();
final ArrayList mCachedViews = new ArrayList();
RecycledViewPool mRecyclerPool;
private ViewCacheExtension mViewCacheExtension;
以上几种缓存为了贴切主题，我称之为：可塑性备胎，备胎中的备胎， 备胎池，贵族备胎。
屏幕当中的View：
官方解释的太绕口，我的解释就是这类view属于还没脱离RecycleView的绑定，只是暂时被RecycleView给标识为无效的，你全当理解成一串不被关注的葡萄还在葡萄架上挂着，一旦被需要根据他的position又被拎起来了，正所谓是可塑性备胎。
说到备胎，来直接看看爆胎吧：
挂在葡萄架上都显得多余，直接给抛弃！如果说这个比较残忍，那就找点安慰，因为备胎不止你一个，当找到真爱的时候，所有备胎全爆，不信你看：
看到上面几个方法后，你是不是大概明白了一级缓存的原理？如果还不明白，我给你一张备胎全家福：
如果还觉的眩晕，我简单解释就是需要你的时候，从备胎一级级找，不要觉得主子盲目，每个备胎都是有标识的（position），找不到就重新培养了。另外提到贵族备胎，是因为他是用户可指定的，虽然不常用，但是指定了，那其他只能靠边。行了，关于缓存机制暂且说这么多吧，再啰嗦下去，担心看过文章的人都着急找备胎去了。
二.局部刷新
很不想提前任（Listview），但是没有对比就不知道现任的好，所以前任对不起了。
想必每个玩过Listview 的人都痛哭一声：局部刷新太恶心了！删除或者增加一个view如果自己不去做处理，adapter直接notifiydatachanged，Listview会全部重新绘制，试想成千上万的话，那还得了。当然，我们实际应用的话，如果数据量小的话估计就睁一只眼闭一只眼了，但是数据量大的时候，只能自己写了。
盗一张图吧，的确，有关前任我就爱应付：
其实很简单，和正常人的逻辑一样，我们局部刷新的时候，就是想刷新自己想要的部位，比如你只想洗个手没必要去泡个全身澡吧。以上代码解释的很到位，业界基本都这么用，就不要再造轮子了。
或者你已经看出我迫不及待的想说前任了，确实，一起来瞅瞅RecycleView的局部刷新。
天哪！不可思议，我还准备洋洋洒洒呢，竟然就这么简单？
确实，就是这么简单。api确实给的太简单了，可是作为高逼格的你总是想知道原理，那就满足你抽一个方法来具体深究下。以notifyItemRangeInserted为例：
mObservable.notifyItemRangeInserted(position, 1);
看到这一句貌似已经明白差不多了，android真是到处都是观察者模式。继续进去看看我们猜的对不对。
@Override
public void onItemRangeInserted(int positionStart, int itemCount) {
assertNotInLayoutOrScroll(null);
if (mAdapterHelper.onItemRangeInserted(positionStart, itemCount)) {
triggerUpdateProcessor();
}
}
void triggerUpdateProcessor() {
if (mPostUpdatesOnAnimation && mHasFixedSize && mIsAttached) {
ViewCompat.postOnAnimation(RecyclerView.this, mUpdateChildViewsRunnable);
} else {
mAdapterUpdateDuringMeasure = true;
requestLayout();
}
}
代码一看大家都明白，我主要简单点一下观察者怎么搞进去的，setadapter的时候会把观察者注册进去，触发更新的时候会去通知observe执行响应的事情
三.四大组件
1. Adapter
我称之为所有列表的灵魂组件，为什么这么说呢？因为离开他，你的数据就不不知道何去何从，因此可以看出来他的作用就是binddata即：数据绑定。
既然是数据绑定，至少要衍生出来两个对象，数据和绑定者。
因此就剥离出来data和viewholder。viewhold我在这里不再多做解释，有时间可以单独拎出来研究，你大可以理解就是为了提高性能，避免重复的findviewbyid就行。
大致先看下源码的结构：
不得不说recycleview的好处就是给你剥离的很清楚，看着这些函数，你是不是都欢喜了？
直接看我在项目中的运用吧，以小视频首页的瀑布流为例：（为了整个架构考虑，Recycleview我都是封装的，我们只看重点）
先上一张效果图：
数据怎样来？毫无疑问服务的获取解析成自己的对象塞到自己的adapter中：
bind数据：
说明：针对于adpater其实真没啥，主要是看怎么灵活应用，使其简单，性能更好，实现多样化的数据类型形式。
2. Layout Manger
一看就知道这家伙很强啊，掌控着整个布局形式，线性布局，网格布局，瀑布流等，让你大开眼见。因为我的项目用到时瀑布流所以我只拿瀑布流说事，不过值得一提的是我封装的layoutmanager可以支持各种形式，只是参数不同而已。
以StaggeredGridLayoutManager为例：
暂时先贴上以上三个方法吧，不过是什么流终归都是继承layoutmanager实现的，在这里layoutmanager像是一个中转站的指挥官，不干实事只发命令，其实你可以想一下所谓瀑布流，网格布局等等，无外乎就是view的一个排版，这个怎么排无外乎就是怎么定义每个view的一亩三分地，所以简单来说layoutmanager就是负责告诉你view怎么占位。
如果深入研究的大神其实最后会发现这个最终回去调用requestLayout方法，这个方法大家不陌生，就是重新布局，重新计算mesaure，重新layout，但是不会重新draw。这个原因我没深入看，但是我觉得应该是因为view的绘制另有其人，应该是在adpater的getview里面，因为我们会发现adpate的初始化是在我们的layoutmanager指定后，一般是这样使用的，那么这种猜测也就合情合理。另外多说一点，layoutmanager其实是负责recycleview的回收的源头，从下面代码就可以看出：
是在onlayoutchildren方法层层调用的，这样看来你就会恍然大悟，一切都明白了，这家伙管的还真宽，没办法，虽然recycleview依赖他呢。
3. Item Animator
RecyclerView能够通过mRecyclerView.setItemAnimator(ItemAnimator animator)设置添加、删除、移动、改变的动画效果。RecyclerView提供了默认的ItemAnimator实现类：DefaultItemAnimator。这里我们通过分析DefaultItemAnimator的源码来介绍如何自定义Item Animator。
DefaultItemAnimator继承自SimpleItemAnimator，SimpleItemAnimator继承自ItemAnimator。
多的我就不说了，这些东西我觉得没啥意义，大家看看就知道了。有一点想说的是，默认的是有动画的。
4.Item Decoration
这个运用也比较常见，可以改变你view之间的间隔，甚至根据指定view来展现你与别人的与众不同。
使用也很简单，例如：
实在不好意思，每当到最后我都不想再继续讲了，我只能说这个知识点也没啥好讲的，源码也没什么东西，不过值得一提的是：ItemDecoration的onDraw()在绘制Item之前调用，ItemDecoration的onDrawOver()在绘制Item之后调用。
原因是：根据View的绘制流程，首先调用RecyclerView重写的draw()方法，随后super.draw()即调用View的draw()，该方法会先调用onDraw()（这个方法在RecyclerView重写了），再调用dispatchDraw()绘制children。
四.总结
RecycleView 的知识点远远不止这些，比如他的header，footer，根据type同一个LayoutManager可以显示不同的数据类型等等，总之知道他的原理，熟练的运用，你可以很轻松的分分钟玩转你的app各种列表布局，懂得了原理，玩转了RecycleView你也懂得在什么场景怎么使用可以性能达到最高，扩展性达到更高。每一个技术点个人觉得都博大精深，不管前任还是现任，吃透了，终究有好处！祝君好运，不喜勿喷！
