刚出来工作，就负责一个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模式。
简单的代码，只要不断思考，慢慢的，所能学到的东西就会变得越来越多，最后甚至超出我们的想象。