RecyclerView机制分析: Recycler

1. Recycler虽然命名上看，像是只承担了View回收的职责，其真正的定位是RecyclerView的View提供者(甚至是管理者), 包括生成新View, 复用旧View，回收View，重新绑定View等逻辑都被封装在Recycler中。外部调用者只需要调用Recycler的接口获取合适的View即可，不需要关心View获取和配置等具体细节，Recycler对外提供了View的回收和获取服务。
2. 先列一些概念:
   
   1. View的detach和remove:
      
      1. detach: 在ViewGroup中的实现很简单，只是将ChildView**从ParentView的ChildView数组中移除，ChildView的mParent设置为null, 可以理解为轻量级的临时remove, 因为View此时和View树还是藕断丝连, 这个函数被经常用来改变ChildView在ChildView数组中的次序。**View被detach一般是临时的，在后面会被重新attach。
      2. remove: 真正的移除，不光被从ChildView数组中除名，其他和View树各项联系也会被彻底斩断(不考虑Animation/LayoutTransition这种特殊情况)， 比如焦点被清除，从TouchTarget中被移除等。
   2. RecyclerView的Scrap View:
      
      1. Scrap View指的是在RecyclerView中，处于根据数据刷新界面等行为, ChildView被detach(注意这个detach指的是1中介绍的detach行为，而不是RecyclerView一部分注释中的”detach”，RecyclerView一部分注释中的”detach”其实指得是上面的remove)，并且被存储到了Recycler中，这部分ChildView就是Scrap View。
   3. ViewHolder有一个Flag: FLAG_TMP_DETACHED代表的就是1中介绍的detach， 这也印证了2的推测，RecyclerView将remove视为”detach”, detach视为”tmp_detach”
3. Recycler**一般不会直接作用于View，其操作的对象一般是ViewHolder**。Recycler**分几个地方(代表不同层级)存放可复用的ViewHolder**:
   
   1. [一级缓存]: