mCachedViews重要用于存放已被移出屏幕、但有大概很快重新进入屏幕的列表项。其同样是以ArrayList的情势持有着每个列表项的ViewHolder对象，默认巨细限定为2。
final ArrayList<ViewHolder> mCachedViews = new ArrayList<ViewHolder>(); int mViewCacheMax = DEFAULT_CACHE_SIZE; static final int DEFAULT_CACHE_SIZE = 2;比如像朋侪圈这种按更新时间的先后序次展示的Feed流，我们常常会在快速滑动中确定是否有自己感爱好的内容，当意识到刚才滑走的内容大概比较风趣时，我们通常就会将上一条内容重新滑返来检察。
这种场景下我们寻求的自然是上一条内容展示的及时性与完备性，而不应让用户产生“才滑走那么一会儿又要重新加载”的抱怨，也即同样不应发生视图的重新创建或数据的重新绑定。
我们用几张流程表示图来演示这种环境：
同样为了简化问题、方便形貌，我们的范例将会居于以下限定：
mRecyclerPool重要用于按差别的itemType分别存放超出mCachedViews限定的、被移出屏幕的列表项，其会先以SparseArray区分差别的itemType，然后每种itemType对应的值又以ArrayList的情势持有着每个列表项的ViewHolder对象，每种itemType的ArrayList巨细限定默以为5。
public static class RecycledViewPool { private static final int DEFAULT_MAX_SCRAP = 5; static class ScrapData { final ArrayList<ViewHolder> mScrapHeap = new ArrayList<>(); int mMaxScrap = DEFAULT_MAX_SCRAP; long mCreateRunningAverageNs = 0; long mBindRunningAverageNs = 0; } SparseArray<ScrapData> mScrap = new SparseArray<>(); ... }由于mCachedViews默认的巨细限定仅为2，因此，当滑出屏幕的列表项高出2个后，就会按照先辈先出的序次，依次将ViewHolder对象从mCachedViews移出，并按itemType放入RecycledViewPool中的差别ArrayList<ViewHolder>。
这种缓存布局重要思量的是随着被滑出屏幕列表项的增多，以及被滑出距离的越来越远，重新进入屏幕内的大概性也随之降低。于是Recycler就在时间与空间上做了一个权衡，允许雷同itemType的ViewHolder被提取复用，只必要重新绑定命据即可。
如许一来，既可以克制无穷增长的ViewHolder对象缓存挤占了本来就告急的内存空间，又可以淘汰回调相比较之下执行代价更加昂贵的onCreateViewHolder方法。
同样我们用几张流程表示图来演示这种环境，这些表示图将在前面的mCachedViews表示图根本上继续利用：
