优化使用ListView、RecyclerView：应对低交互、特别多的不同类型布局的业务场景

出发点矛盾

1.业务稍微复杂，变动大

近产品大开脑洞，APP首页列表，身兼多种业务，每种业务，又分数据视图和没数据的占位视图，整体就跟淘宝首页类似，还要插入不同类型的广告业务视图（差不多广告有2-4种不同UI类型），加上需求变来变去，UI变化很大，搞的我很头疼。

2.偷懒，不想多次处理老代码

以RecyclerView的Adapter举例，如果我们要多类型，每次要定义type=0,1,2....，再到CreateHolder，处理type=0,1,2....如果有新增的类型，又要修改这部分逻辑，只想偷懒，每次新业务，都是即插即用，不再考虑下面这些重复判定逻辑:

@Override  
    public int getItemViewType(int position) {  
        // TODO Auto-generated method stub  
        Object obj = mDataList.get(position);  
        if (obj instanceof XXXX) { 
            return 0;  
        } else if (obj instanceof YYYYY) {  
            return 1;  
        } 
        return super.getItemViewType(position);  
    }  

 @Override  
    public Object createViewHolder(int type, ....) {  
        if (TYPE_ONE == type) {  
            return XXXViewHolder;  
        } else if (TYPE_TWO == type) {  
            return YYYYViewHolder;  
        } 
        return null;  
    }  

3.尽可能复用

再者老代码是listview，新代码部分使用的是recycleView，面对两者不同的adapter适配，我想同一套业务逻辑统一逻辑调用，而不要出现针对不同视图列表，定义新的业务逻辑绑定

解决目标、场景

1.每个业务视图，逻辑独立，可替换，可删除，有效适应业务变换，新增业务，不影响老业务
2.针对Listview、RecycleView，不同列表视图无差别化
3.目前我们APP的业务视图，是弱交互场景，基本都是点击后跳独立页面

思路方向

每个业务，有个我们可以确定的事情：
1.针对一个adapter，它的每个数据，就知道自己是怎样的业务视图
2.每个业务item，要做的事情很明确，拿到数据，初始化布局，将业务数据绑定
所以，抽象2个地方：
1.业务绑定逻辑，定义为 XXXXBinder，称之为 Bricks(积木)
2.业务UI视图，定义为XXXXHolder，视图集合体
3.adapter 内部统一数据管理
4.adapter 内部统一Bricks管理

通过数据去找Bricks，来绑定业务逻辑

1.抽象出原始Bricks，视图逻辑

提高抽象逻辑，对bricks屏蔽具体底层是listView类型的adapter、还是RecycleView的adapter
我不希望，同样的业务bricks，在不同的列表视图还需要分别定义

抽象出通用视图逻辑：

public interface QUIAdapterHolder {

    /**
     * 获取到ItemView
     *
     * @return
     */
    View getItemView();

    /**
     * 获取ItemView 下的具体子view
     *
     * @param id
     * @param 
     * @return
     */
     T findView(int id);
}

item视图，最基本只需要提供查找view的功能即可。

抽象出业务逻辑（Bricks）：

public interface QUIAdapterBinder {

    /**
     * 因为我们是通过数据反查业务逻辑，所以每个业务定义，需要告诉外部adapter自己接受什么样的数据
     *
     * @param position
     * @param data
     * @return false不处理，true将触发bindDataToView
     */
    boolean accept(int position, Object data);

    /**
     * 获取当前业务对应的布局
     *
     * @return
     */
    int getBinderContentView();

    /**
     * 绑定当前业务数据
     *
     * @param context
     * @param holder  视图逻辑
     * @param position
     * @param data
     */
    void bindDataToView(Context context, QUIAdapterHolder holder, int position, Object data);
}

这里做了一个处理，所有数据对象统一处理为Object引用，使得adapter内部逻辑简单，数据只能进入对应业务accept（）、bindDataToView（）方法的时候，再强转为业务类进行处理

2.实现Adapter内部逻辑

管理数据逻辑:

public abstract class QUIAdapterData {

    public enum Change {
        SET,
        ADD
    }

    private List