一个ListView布局的不断演化

刚出来工作，就负责一个APP的某块功能的编写，该功能就是类似微博那样的界面。微博界面的编写实际上是非常复杂的，虽然它只是一个ListView，但要想让这个ListView滑得动，是的，在一些配置低的手机，随便一个负载内容多的Item，都有可能导致OOM。。。如果只是简单的为了实现了效果，可以选择将所有内容都写在xml文件，如果布局不好的话，就会出现嵌套过多的情况，同样也会出现OOM的情况。。。就算不会出现OOM的情况，也能滑得动，也会面临是否能够滑得快。。。

要想能滑得动，也能滑得快，就要动点脑筋了。

一开始非常简单的代码就是这样：

@Override
public View getView(int position, View convertView, ViewGroup parent) {
    ViewHolder holder;
    if (convertView == null) {
        convertView = inflater.inflate(R.layout.list_item, null);
        holder = new ViewHolder();
        ……
        convertView.setTag(holder);
    } else {
        holder = (ViewHolder)convertView.getTag();
    }
}
/**
 * ViewHolder
 */
private static class ViewHolder {
    ImageView appIcon;
    TextView  appName;
    TextView  appInfo;
}

这是谷歌推荐的方式，实际上也解决了很多性能上的问题。

Android原生的ListView原本就做了相应的缓存机制，Recycler。

Recycler的工作原理大致如下：

假设屏幕最多能看到11个item，那么当第1个item滚出屏幕，这个item的View进入RecycleBin中，第12个要出现前，通过 getView从回收站（RecycleBin）中重用这个View，然后设置数据，而不必重新创建一个View。

这样即使有上万个Item，inflate的次数最多就是n，也就是一个屏幕能够容纳的个数。

大部分的情况都可以用这样的代码解决，但我觉得对于每个Adapter都要写一个ViewHolder实在是太麻烦了，于是进一步将代码改写为这样：

@Override
public View getView(int position, View convertView, ViewGroup parent) {
     if (convertView == null) {
        convertView = inflater.inflate(R.layout.list_item, null);
        }

        ImageView icon = (ImageView)CommonViewHolder.get(convertView, R.id.image_view);
}

其中CommonViewHolder的代码如下：

public class CommonViewHolder {

    /**
     * 用于获取ItemView中的控件
     *
     * @param view ItemView
     * @param id   要获取的控件的id
     * @param <T>  返回的控件的类型
     * @return 返回的控件
     */
    public static <T extends View> T get(View view, int id) {
        SparseArrayCompat<View> viewHolder = (SparseArrayCompat<View>) view.getTag();
        if (viewHolder == null) {
            viewHolder = new SparseArrayCompat<>();
            view.setTag(viewHolder);
        }
        View childView = viewHolder.get(id);
        if (childView == null) {
            childView = view.findViewById(id);
            viewHolder.put(id, childView);
        }
        return (T) childView;
    }
}

实际上，ViewHolder就是通过setTag方法将相应的控件作为View的属性保存起来，然后下次使用的时候就可以直接复用。

既然明白了它的原理，就可以对它进行改造，CommonViewHolder是利用SparseArrayCompact存储控件。SparseArrayCompact是SparseArrayCompact是SparseArray的兼容类，本质上就是类似Map的键值对容器，谷歌宣称它的性能比Map要好，因为内在的算法已经优化了。

这里的工作很简单，同样是利用setTag方法保存View中的控件，但是却把findViewById这样的工作放在了CommonViewHolder中，这样就不用每次都要调用findViewById方法了。

为了考虑通用，还使用泛型。

代码量瞬间就减少了很多，但这时就面临了一个问题：Item项错乱了。。。

在快速滑动的时候，图片加载错了，仔细调试，就发现是Recycler机制出现了问题。当快速滑动的时候，原本应该开始加载图片的控件已经滑出屏幕，然后我的图片加载是异步的，所以图片就会加载在后面的Item上。

解决这个问题的方法同样得利用setTag方法：

icon.setTag(imageUrl)

....
if(imageUrl.equals(icon.getTag()){
      ....
}

通过setTag保存ImageView要加载的url信息，然后在下次加载的时候判断是否相同。

问题解决了，但看到getView方法中为了实现微博这样承载大量信息的界面，不得不编写大量的业务代码，而且这样复用性很差，因为微博详情的界面和列表项的界面基本一样，只是有一些不同而已。如果再写一个，就有点傻逼了，但如果不写，getView方法中肯定又要写更多的判断。

为了解决复用的问题，就开始组件化。

将微博界面拆成两个部分：HeaderView和BodyView。HeaderView负责微博作者的基本信息，而BodyView就是微博内容。

这样，我只要在getView方法中这样写：

add(new HeaderView());
...
add(new BodyView());
...

也就是说，我从一个静态布局改成动态布局，这样我在详情那里也可以复用。

到了这里原本也应该结束了，但我又想要为微博业务编写测试，但Android中View和业务的代码是各种纠缠，很难完全脱离View来测试业务。

经过思考和查找资料，我找到了一种方式：ViewModel。

编写相应的ViewModel作为Controller，就可以将View和业务的代码解绑：

public class ViewModel{
     private String text;
     ...
     public void setText(TextView view){
            view.setText(text);
     }
}

这样组件里面的代码就更少了，它只要声明好控件然后传进来就行了，数据的获取和绑定都在ViewModel这里。

然后我们来写一个简单的测试：

ViewModel model = new ViewModel();
Button button = new Button(context);
button.setText("你好");
model.changeButtonText(button);
assertEquals("我好",  button.getText());

public void changeButtonText(Button button){
       button.setOnClickListener(new OnClickListener(){
               button.setText("我好");
       });
}

利用ViewModel，我们可以方便的测试Android种的业务。

这是到目前为止的思考和尝试，实际上，我认为代码还会不断演化下去，现在已经开始出现MVVM的一些思想的应用，到了最后，没准就会完全演化成MVVM模式。

简单的代码，只要不断思考，慢慢的，所能学到的东西就会变得越来越多，最后甚至超出我们的想象。