RecyclerView再封装

RecyclerView做为ListView的替代品，已经出了很久了，既然是替代品，那自然有些ListView没有的优点。比如说：可以随意切换list,grid,stagger。可以指定一个或多个item刷新，而不再是全部刷新。另外可以为每个item添加动画，在体验上更进一步。

但是也有不少“缺点”

1. divider没以前好画了，其实是因为divider支持多种样式，方便自己定义了。以前divider就是一根线，现在可以加margin，加多条线，某行不加divider等需求。ItemDecoration=>Item装饰器，名副其实。
2. 没有OnItemClickListener，RecyclerView的解耦方式太漂亮了，LayoutManager负责计算布局，Adapter负责适配，Holder负责渲染Item，ItemDecoration负责items间隔，ItemAnimator负责item动画，Recycler负责回收复用。RecyclerView就是个中控啊，只负责调度。所以它为了不破坏自己的解耦，就让每个item自己去实现点击事件，万一要Drag，Move，Swipe呢，对吧。
3. 阿西巴，没有header footer，上述2中已经说过了。RecyclerView不爱干实事儿，就负责调度，UI的事都是Adapter负责干的啊。你给RecyclerView了它也不知道给你加到哪里去。想实现，就去找Adapter吧。

关于API，以及RecyclerView的用法Stay就不多说了，网上都有。我们来讨论讨论，如何将RecyclerView真正投入到项目中去。

我们不愿意使用新东西，一是怕有bug，二是怕不满足需求，三是怕没有现成的成熟的封装类可以用，不想自己写。

github上有很多基于RecyclerView的封装，Stay觉得还不够彻底。使用起来还是不够方便。特别是UltimateRecyclerView，根本不叫封装，简直就是堆代码，看起来功能强大，实际上能用到10%的样式就不错了。请勿使用这种代码，功能越多，改起来就更复杂啊。

Stay理想的封装模式是这样的：

1. 大家还记得ListActivity嘛，就是那个将ListView和Adapter定义在父类，让子类去继承的。现在RecyclerView支持List，Grid，Stagger，不做个BaseListActivity多可惜，好多默认配置都可以放父类，最简单的子类Activity只需要load数据以及bindHolder就完了。连Adapter都不用写了。
2. 以SwipeRefreshLayout为例，想要RecyclerView支持下拉刷新，加载更多，必然要将两者封装到一起，再建一个Controller类，这个Controller还是负责调度，将SwipeRefreshLayout与RecyclerView的调度方法再写一遍，外层只需要跟Controller沟通。
3. 想要实现加载更多，需要让Adapter去负责，原生的Adapter不支持，那就需要再抽一个BaseListAdapter来扩展，itemType，itemCount，onCreateFooterViewHolder都由这个抽象类来filter，这样子类就不需要管footer这事，只需要继承BaseListAdapter，就自动支持加载更多。
4. 加载更多的footer有两个坑，在stagger模式下，findLastVisiblePositions这返回的是数组,在list，grid模式下返回的是int，在未来可能会自定义LayoutManager，那可能又会发生变化，那么就需要定义一个算法，然后不同的模式都实现它，这样在Controller中只需要调这个算法，拿到值就搞定了。你可以用策略模式来解决它。用策略模式，是不想在Controller中instanceOf与强转，并且如果有自定义的LayoutManager，那以后就需要去改动Controller。
5. 加载更多另一个坑就是，在grid和stagger模式下，footer要占满一行而不是一个span。所以grid需要SpanSizeLookup来动态改footer所占的spanCount。而stagger呢，需要将viewholder中的itemView的LayoutParams中isFullSpan设置为true。确实很麻烦，但你依然可以用策略模式来解决它。
6. 假如要实现Section分组，那就再定义一个BaseSectionListActivity去继承BaseListActivity，再做一次封装与隔离。这样子类只要继承BaseSectionListActivity就拥有了一个支持分组，下拉刷新，加载更多的这样一个控件。并且支持list，grid。

以上是Stay所想的封装方式，没有什么高深的算法，只是简单的通过控件的组合，API的灵活运用。当然如果你要支持drag，move，sticky-section-header，那就需要额外做工作了。但那些毕竟是少数，将业务需求中常用的UI形式进行封装才是必要的。

没错，接下来，Stay要安利了。年前一直在筹备重录快速搭建项目MaterialDesign版课程(第三遍)，现在终于有心得有感悟的来录制了。目前课程还在更新中，之前购买过课程的同学可以提前学习了。学封装架构的思维方式，比看3个开源项目还有用。

虽说是收费课程，但绝对物有所值，比起那些API教学，Stay的课程有营养的多。我们不讲某个具体API的调用，不讲某个功能实现或者复杂的UI特效（这些可以google，可以找开源lib）我们讲，如何去思考，站在用户的角度去理解需求，站在PM的角度去把控项目，站在架构师的角度去设计整体结构。至于剩下的，相信我，都很简单。