原文链接 http://blog.csdn.net/fyfcauc/article/details/54140777
AdapterHelper: Update行为记录/整合/分发系统(时序魔法师，扮演了RecylerView和LayoutManager之间的Position调停者)，让RecyclerView可以支持真正的局部更新，不必像ListView一样牵一发动全身，Update行为整合/分发功能是Prelayout机制实现的基础，进而推动了Predictive动画模式的实现。Update行为这次也被模型对象化了，带来的好处就是对Update的处理粒度从整体细化到了某个item。
LayoutManager: 布局系统分化了View管理和布局职责，RecyclerView不再负责具体的布局细节，只需要作为功能性平台为LayoutMananger提供各项服务。LayoutManager使用RecyclerView提供服务，经过测量计算等内部细节逻辑，将自己的布局方案应用到RecyclerView来实现最终的布局效果。更灵活的是，RecyclerView甚至可以动态切换LayoutManager来实现整体布局的动态切换。相比以前的ListView/GridView继承AbsListView来实现不同布局效果，是基于继承实现扩展的思路，而LayoutManager机制则是基于组合来实现扩展, 更符合组合优于继承的设计思想。
ItemDecoration: View展示装饰器，提升View在展示层面的扩展性，可定制化程度比ListView的divider高的多，在View测量和View绘制给了使用者完全的自由。
动画系统提供了独立的动画管理和计算框架，借助于底层的ViewinfoStore模块和PreLayout机制，使用者不需要像实现常规动画那样关注整个动画的边边角角, 只需要在动画机制提供的几个回调点配置动画即可，动画的起点终点信息，View可以执行何种类型的动画，甚至View执行完动画后的释放，全部由动画系统代劳。Simple和Predictive两种动画模式基本可以涵盖绝大多数的动画场景。
Recycler系统相较AbsListView的RecycleBin更进一步，提供了多级缓存,第二级缓存(ViewCacheExtension)是可选的，由使用者来自行定制，在缓存控制方面提供了扩展性。第三级缓存(RecyclerViewPool)则实现RecyclerView之间的缓存分享。整体上来说，对缓存的使用更加自由，效率也更高。
ViewHolder机制被正式集成，和View的关联不必再借助于Tag，直接作为LayoutParam的扩展属性进行保存，实现了和相关View的关联。ViewHolder除了被使用者进行扩展外，还保存了对应的Item的元信息(如位置，状态等)，这些元信息配合AdapterHelper实现了局部更新功能。很多时候，RecyclerView面对的是ViewHolder而不是View，在抽象层次上的到了提升。
RecyclerView在实现中将信息保存职责也进行了细化和独立, State被引入来保存布局中的暂态信息，进一步, State也是LayoutManager和RecyclerView之间的通信手段，LayoutManager通过State了解当前布局阶段的信息。除此之外，State还提供一个可以保存Object的SparseArray(以及对其的读写)来作为扩展性的体现
-
RecyclerView的layout被细化为三个阶段:
- 预处理Update行为，ViewInfoStore记录layout后的View的分布，如果支持Predictive动画模式, LayoutManager基于当前的item状态进行一次layout(PreLayout)
- 处理所有的Update行为，LayoutManager基于当前的item状态进行一次layout(PostLayout)
- ViewInfoStore记录layout后的View的分布，和layout前进行对比分析得出每个View在这一轮变化中对应的动画类型(消失/出现/移动等)，调用ItemAnimator配置动画，最后将动画调度到下一帧开始执行
ChildHelper是一个精巧的设计, 为LayoutManager模拟了一个理想状态的ViewGroup环境,作为一个中间层存在与LayoutManager和RecyclerView之间。ChildHelper消抹了RecyclerView(现实世界)和Adapter/Data(理想世界)之间的差异。
RecyclerView的核心是优雅高效的解决一个差异: 数据改变后，界面呈现的旧数据和幕后新数据的差异
