RecyclerView 实测小结

RecyclerView 是真TMD的复杂，怎么那么多细节。本来想按照源码写一个出来，写着写着就觉得坏了，写不下去了，全部弄懂它，要耗死我了，哪有那么多时间，就好像流沙，沼泽。蛮力感觉出不来，还是要怀着敬畏之心
为了弄清楚它的缓存机制，经过demo测试得出的结论，或者观察到的现象。在这之前，我一直在思考一个问题，为什么要弄清楚它的缓存机制，我觉得是为了更好的使用它，而你真正说会用到这种3层的缓存结构去应用到其他地方去，不说碰不到吧，极难，达到这种程度的价值从这个实际意义上来说，就不大了，所以达到目的为止，别上头。
1.初始化 可见的item 会调用 onCreateViewHolder onBindViewHolder 。
2.滑动会提前加载最后看到的下一个。
3.notifyDataSetChanged 只调用 可见的item 的onBindViewHolder。即使要变换的数据在不可见的区域，还是只调用可见的item 的onBindViewHolder。notifyDataSetChanged 的源码是通过观察者模式通知每个item 做onChange，里面实质上是View.requestLayout，刷新，所以才有网上说的notifyDataSetChanged 方法，耗性能，傻瓜式的（要变的item都看不见，不在可视区内，它还傻子一样地刷新可见区域），可见这并不是局部刷新的最优解。由此引出DiffUtil
首先先说一下RecyclerView 的三级缓存：
1.mChangedScrap （针对位置发生移动的item）和 mAttachedScrap 都是针对的是 屏幕内的view ，不需要重新bind 数据

2.mCacheView 针对的是屏幕外（从屏幕内将要移出屏幕外的）的View ，不需要重新bind数据 默认缓存大小是2 可以通过setItemViewCacheSize 设置
3.recyclerviewPool 相同类型都能复用，需要重新bind数据 , 每个类型的默认大小是5，可以通过RecyclerView.getRecycledViewPool().setMaxRecycledViews(int viewType, int max); 设置，还有就是这里面缓存的可是需要重新onbindViewHolder的，虽然不用view inflate去创建了。
需要画一下缓存流程图：

缓存的目的就是更快的显示，减少资源的调配，用存储空间来换时间的，那么整个机制都在避免频繁地调用onCreateViewHolder和onBindViewHolder 所以我们得出结论，使用recyclerView的时候，尽量避免在这两个方法之中new 对象，造成内存抖动的问题。同时，cacheView和RecyclerviewPool的大小可以根据自己的使用情景设置。还有就是明白为什么要使用DiffUtils来优化。我想就能满足日常对RecyclerView的使用了。
如果想更深的了解它，那这个水就深了。。。。深到吓到你，哈哈！
待更吧