名字有点唬人，其实就是组合了几个封装类能够方便实现RecyclerView的多视图，毕竟“框架”这个词在我看来还是指具有一定规模量级及重点技术的代码体系，但仅就解决特定问题而言也不妨被冠以这个名号。同时它真的是“超轻量”总共不过4个类，不超过130行代码~
视图抽象
我们已经有了一个无需类型强转的通用ViewHolder(ItemViewHolder)，一个ViewHolder对象可以找到所有视图实例。而且它是完全独立的， 没有引入任何自定义类或者任何第三方依赖；即使没有这个“框架”，也完全可以拆出来用在其他地方。
控件适配器
适配器(Adapter)是与控件关联的, 是控件对其子视图列表的一种抽象。抽象了什么？由具体定义决定。比如列表控件的适配器（无论是以前的ListView, 现在RecyclerView, 以及其它的如ViewPager）一般抽象了三个属性：
- 数量 getItemCount()
- 操作 onBindView(ViewHolder holder, int position)，onCreateView
- 类型 getViewType(int position)
控件适配是SDK关联的，框架的ItemAdapter也是基于RecyclerView.Adapter
元素抽象
适配器(Adapter) 是容器控件对子控件的整体抽象，相应位置的元素没有作出任何限制，position对应的元素可以是接口返回的一个具体数据，也可以是从本地获取的应用数据。框架要做的一个工作就是对元素数据类型进行抽象, 但是数据类型千差万别，无法对数据元素本身的属性做统一操作，结果就是变成像MultiType库那样，用范型抽象所有的数据元素，然后通过注册数据类型(.class)到数据绑定器类型(ItemViewBinder.class)的映射，反射得到绑定器实例，其中有大量的对象类型强转。
框架不对数据元素做抽象，而是针对操作作抽象，即adapter对每个position元素的操作作抽象；用一个简单的List数据结构持有抽象实例；因为同样有绑定操作，所以姑且也叫做绑定器ItemBinder。ViewHolder就用我们之前的通用ViewHolder(ItemViewHolder)，结合前面说到adapter有三个重要属性，于是有:
public interface ItemBinder {
void onBindViewHolder(ItemViewHolder holder, int position);
int getViewType();
}
public class ItemAdapter extends RecyclerView.Adapter {
private final List mBinders = new ArrayList<>(10);
@Override
public void onBindViewHolder(@NonNull ItemViewHolder holder, int position) {
ItemBinder binder = mBinders.get(position);
binder.onBindViewHolder(holder, position);
}
@Override
public int getItemCount() {
return mBinders.size();
}
@Override
public int getItemViewType(int position) {
return mBinders.get(position).getViewType();
}
public void setBinders(List binders) {
mBinders.clear();
mBinders.addAll(binders);
}
} 对于Adapter而言，元素仅仅是ItemBinder，它不关心ItemBinder是用哪种数据类型，又是怎样把数据填充到ViewHolder中。
视图类型
RecyclerView通过RecyclerView.Adapter的getItemViewType接口返回的数值来标识一个视图类型。与ListView不同的是这个viewType可以不是连续的，RecyclerView可以自己感知设置了多少种viewType（内部其实就是用了SparseArray）。通过viewType的标识, RecyclerView.Adapter的onCreateViewHolder来创建相应的视图类型。通常我们不得不自己建立viewType和RecyclerView.ViewHolder的映射关系，除了稍有点烦琐之外并没有多大的问题。
注意：我们走到了到框架的一个关键点，就是建立viewType和视图实例创建之间的关系。
已经找不到是在哪个库里，当看到把视图资源id(layoutId)直接作为viewType返回的时候，被这种天才想法折服了。首先就是用资源id本身就可以创建视图；其次是充分利用了viewType可以不连续的性质；再次是不同的资源id天然的对应不同的视图类型，也就是说，本身就是多视图类型的；最后的最后就是这种实现提供了巨大的灵活性，包括代码复用和资源的复用，这点后面专门说一下。于是有：
public interface ItemBinder {
void onBindViewHolder(ItemViewHolder holder, int position);
@LayoutRes
int getLayoutId();
}
public class ItemAdapter extends RecyclerView.Adapter {
private final List mBinders = new ArrayList<>(10);
@NonNull
@Override
public ItemViewHolder onCreateViewHolder(@NonNull ViewGroup container, int viewType) {
return new ItemViewHolder(LayoutInflater.from(container.getContext()).inflate(
viewType, container, false));
}
@Override
public void onBindViewHolder(@NonNull ItemViewHolder holder, int position) {
ItemBinder binder = mBinders.get(position);
binder.onBindViewHolder(holder, position);
}
@Override
public int getItemCount() {
return mBinders.size();
}
@Override
public int getItemViewType(int position) {
return mBinders.get(position).getLayoutId();
}
public void setBinders(List binders) {
mBinders.clear();
mBinders.addAll(binders);
}
} 我们之前被getItemViewType的默认值0给误导了，思维惯性让我们认为viewType可以和ViewHolder是割裂的，但其实它们可以是统一的！
剩下的工作简单明了，实现具体的ItemBinder类型，将具体的数据填充到视图，比如:
public HomeBannerBinder implements ItemBinder {
private final HomeBanner mItem;
HomeBannerBinder(HomeBanner banner) {
mItem = banner;
}
void onBinderViewHolder(ItemViewHolder holder, int position) {
ImageView bg = holder.findViewById(R.id.background);
if (bg != null) {
ImageManager.load(bg, mItem.bg_url);
}
}
}灵活复用
这里的复用不是recyclerView 对视图内存对象的复用，而是代码层面的复用，包括声明资源的xml代码。
把layoutId作为viewType到底带来怎样的灵活复用呢？
可以先举例常见的微信朋友圈列表：显然，很多朋友圈内容都是不同的，有视频有图片有文本，或者它们的结合，处理2张图片的布局和处理9张图片的布局显示也是不同的；但是每一条朋友圈布局有很多相同的地方：都有顶部的用户头像与用户名称，都有底部点赞和评论布局。那么问题来了：怎样声明不同的视图类型，但不必重复书写这些一样的地方？
这当然不是难事，比如一个视频朋友圈布局可写成这样circle_item_video.xml
音频朋友圈布局circle_item_audio.xml就把@layout/circle_item_layer_video换成@layout/circle_item_layer_audio，依次类推。
这么做完全可以实现，随着类型的增多，布局文件相应增加即可；然而一旦发生变更呢？只要涉及相同布局的部分都必须改一遍！(比如把RelativeLayout变成android.support.constraint.ConstraintLayout)而且实际的情况不一定这么简单，可能因为各种原因视图的层次比较深，并且都没办法放在include中，一旦视图对象变多，视图层次变深， 这种冗余就让人难以忍受了，对一个有追求的码畜来说，肯定希望只更改一处地方即可。
视图复用
如果layoutId作为viewType要如何实现刚才的复用呢？显然他们必须是不同的viewType（如果一样会发生什么？），那么他们当然是不同的layoutId，但不同的layoutId就无法避免上面那样的问题，这时候就用到android的匿名资源(anonymous)，就是对一个资源声明一个引用，而这个引用本身作为一个资源，即circle_item.xml:
中间的部分可通过延迟加载的方式设置成不同的View，甚至所有不同的部分都可以以ViewStub的形式嵌在布局当中。refs.xml:
- @layout/circle_item
- @layout/circle_item
- @layout/circle_item
- @layout/circle_item
也就是说都引用同一份的布局资源！可他们因为不同的layoutId进而可以被recyclerView当作不同的viewType！
代码复用
按照之前的思路也必然希望只在一处更改点赞和评论功能。所以有一个基类：
public class CircleItemBinder implements ItemBinder {
@Override
public getLayoutId() {
return R.layout.circle_item;
}
@Override
void onBindViewHolder(ItemViewHolder holder, int position) {
bindComment(holder);
bindLike(holder);
}
private void bindComment(ItemViewHolder holder) {
}
private void bindLike(ItemViewHolder holder) {
}
}各类型的binder类似:
public class CircleVideoBinder extends CircleItemBinder {
@Override
public getLayoutId() {
return R.layout.circle_item_video;
}
@Override
void onBindViewHolder(ItemViewHolder holder, int position) {
super.onBindViewHolder(holder, position);
...
}
}
public class CircleAudioBinder extends CircleItemBinder {
@Override
public getLayoutId() {
return R.layout.circle_item_audio;
}
@Override
void onBindViewHolder(ItemViewHolder holder, int position) {
super.onBindViewHolder(holder, position);
...
}
}点赞和评论功能的代码就可完全复用！这一切只是用了layoutId作为了viewType!
至此，框架的全貌已呈现：
public interface ItemBinder {
@LayoutRes
int getLayoutId();
void onBindViewHolder(ItemViewHolder holder, int position);
}
public class ItemAdapter extends RecyclerView.Adapter {
private final List mBinders = new ArrayList<>(10);
@NonNull
@Override
public ItemViewHolder onCreateViewHolder(@NonNull ViewGroup container, int viewType) {
return new ItemViewHolder(LayoutInflater.from(container.getContext()).inflate(
viewType, container, false));
}
@Override
public void onBindViewHolder(@NonNull ItemViewHolder holder, int position) {
ItemBinder binder = mBinders.get(position);
binder.onBindViewHolder(holder, position);
}
@Override
public int getItemCount() {
return mBinders.size();
}
@Override
public int getItemViewType(int position) {
return mBinders.get(position).getLayoutId();
}
public void setBinders(List binders) {
mBinders.clear();
appendBinders(binders);
}
} 我们之前的通用ViewHolder也罗列在这里:
public class ItemViewHolder extends RecyclerView.ViewHolder {
private final SparseArrayCompat mCached = new SparseArrayCompat<>(10);
public ItemViewHolder(View itemView) {
super(itemView);
}
public T findViewById(@IdRes int resId) {
int pos = mCached.indexOfKey(resId);
View v;
if (pos < 0) {
v = itemView.findViewById(resId);
mCached.put(resId, v);
} else {
v = mCached.valueAt(pos);
}
@SuppressWarnings("unchecked")
T t = (T) v;
return t;
}
} 一般都还要定义一个基础类ItemBaseBinder，所有派生类的可能会共享某个操作, 这个基础类接收资源id作为构造函数参数:
public class ItemBaseBinder implements ItemBinder {
private final int mLayoutId;
public ItemBaseBinder(@layoutRes int layoutId) {
mLayoutId = layoutId;
}
@Override
public void onBindViewHolder(ItemViewHolder holder, int position) {
}
@Override
public int getLayoutId() {
return mLayoutId;
}
}其余的工作就只是派生具体的业务类了，就像之前举例那样！这一切不过130行代码！
与MutiType的差异
实例一对一
MutiType库同样有绑定器ItemViewBinder但注意他的绑定是只有一个实例，而我们的ItemAdapter是把绑定器作为元素对象，一个数据对应一个绑定器所以他有多个实例，实际上这个绑定器是对数据的抽象。
无类型转换无反射操作
真的，MutiType把这一切搞的太复杂了！可悲的是还有很多人在用……
结语
有了这个框架，灵活性不仅一点没有损失，而且更加简洁，MutiType那坨类型强转和反射操作可以进博物馆了。
一大篇说下来有点累赘，直接上代码就能看明白的，关键是思考的过程与解决问题的思路。所有的框架到底解决了什么问题，这才是最需要了解和学习的，否则框架是学不完的。而一旦我们有了思路与目标，实现一个框架也并不是难事。这套小框架实践已经很长时间了，可以覆盖绝大多数情况，效果出奇的好，比MutiType那坨“不知道高到哪里去了”。
需要注意的有2点
-
onBindViewHolder方法只做数据填充不应该做数据处理
这点其实和框架没有关系，照样还是有许多人在Adapter的onBindViewHolder做着数据处理
- 动态的更换视图类型
因为方法getLayoutId是接口，意味着在运行时可以返回不同的layoutId，从而动态的更改视图类型，不过需要与Adatper的notifyItemChanged配合使用
- 外部通知更新
ItemAdapter.setBinders的方法实现体在更新了实例后没有调用notifyDataSetChanged， 这个操作应该由外部决定，虽然此处是必要的，但很容易造成冗余的更新。
扩展
框架也非常容易根据具体的需要和场景进行扩展。
嵌套
列表嵌套列表的情况下，要如何抽象呢，其实只要对应视图就行。最外层的列表（一级列表）有一个特殊ItemBinder类型，这个类型本身也可以持有多个ItemBinder提供给内层列表(二级列表)：
public class ItemContainerBinder extends ItemBaseBinder {
private final ItemAdapter mAdapter = new ItemAdapter();
@Override
public void onBinderViewHolder(ItemViewHolder holder, int position) {
RecyclerView secondary = holder.findViewById(R.id.secondary);
if (secondary != null) {
if (secondary.getAdapter() != mAdapter) {
secondary.setAdapter(mAdapter);
}
if (secondary.getLayoutManager() == null) {
secondary.setLayoutManager(new LinearLayoutManager(secondary.getContext());
}
}
}
public void setBinders(List binders) {
mAdapter.setBinders(binders);
}
...
} 在这里还可以利用以前提过的重用LayoutManager！
局部更新
在运行过程中只需要更新列表某一项的情况其实非常常见，很多时候不能只更新视图，还要调用Adapter.notifyItemChanged（像前文所提的动态更新列表视图类型）。也就是Adapter持有ItemBinder，而ItemBinder需要再调用Adapter的方法，如果再让ItemBinder去引用Adapter，这种强耦合必然不是一个好的设计。
针对这个框架的实现，这时候首先需要将ItemBinder内部的变化通知出来，但是通知的时机应该由ItemBinder实现体来决定，外部去被动响应。这当然是最简单的观察者模式了，于是有：
public interface ItemBinder {
...
void setOnChangeListener(OnChangeListener listener);
interface OnChangeListener {
void onItemChanged(ItemBinder item, int payload);
}
}
public class ItemBaseBinder implements ItemBinder {
...
private OnChangeListener mChangeListener;
@Override
publi final void setChangeListener(OnChangeListener listener) {
mChangeListener = listener;
}
public final void notifyItemChange(int payload) {
if (mChangeListener != null) {
mChangeListener.onItemChanged(this, payload);
}
}
}这里的payload借鉴了RecyclerView.Adapter，只不过类型由Object变成了int，代表了局部更新需要携带的信息。在ItemBinder实现体内部，因为某项数据变更需要通知到外部就只需调用notifyItemChange方法，将变更传递出去，由外部作出具体响应:
List binders = new ArrayList<>();
...
ItemBinder special = new XXXYYYBinder(...);
specail.setChangeListener(new ItemBinder.OnChangeListener() {
@Override
public void onItemChanged(ItemBinder item, int payload) {
int pos = mAdapter.indexOf(item);
if (pos >= 0) {
mAdapter.notifyItemChanged(pos,...);
}
}
});
binders.add(special);
...
mAdapter.setBinders(binders);