在我的上一篇博客《Android ListView基础篇》中陈列了ListView和adapter的多种结合方式的基本使用，在本篇文章中将具体讲述如何通过多种方式处理好ListView的优化问题。

在上篇文章的例子中，我们使用了一张图片和一个文本作为每一行的数据，发现效果已经完全达到了，而且没出现什么问题。但如果我们将Item的数量调大，比如调到1000、10000、100000条数据，这个时候当你打开ListView的时候，肯定会不禁感慨“什么鬼，卡机了？!”等了好几秒钟，ListView才显示出来，用户体验非常不好，特别是如果是要上市的项目，后果很严重！所以针对ListView的优化至关重要。

ListView内存调用机制的原理

ListView消耗内存的主要地方就在于每一个ListItem的绘制，之前说过了，ListView的每一项的绘制的地方就在于Adapter的getView()方法中，getView()方法的返回值是一个View,这个View就是每一行的视图，然后ListView再将其展示出来，那如果我们像之前那种写法，不做任何修改，结果会是怎样？

我们通过上一篇的例子做个测试，将行数调到100，在getView中打印一句Log看看：

Log打印结果：

可以看到，初始化ListView时getView运行了9次，而界面上刚好也仅显示到第9条数据，也就是只有屏幕范围内显示的才会调用getView()，另外，可以看到它们的convertView都会null，然后我们再将界面稍微往下拖动，如图：

再看Logcat：

注意到，第九项数据从底部开始进入界面，它的getView也调用了一遍，convertView依然为null，这是因为顶部的第一项数据还未完全脱离屏幕范围外，也就是第一项的视图还未进入Android的Recycler中，还不能被重用，我们再继续往下滑：

Logcat:

发现第10项的convertView不为空了！这是因为顶部的第一项数据已经完全离开了屏幕，所以Android会将它的convertView“推”进RecycleView中，然后第10行出现的时候，getView方法的convertView参数正是第一项存放在Recycler中的视图。如下图：

ConvertView的重用

了解了ListView的getView原理，我们就可以开始对它进行优化，上面提到了已经离开屏幕的convertView会被压入Recycler中,那我们可以在每次getView的一开始先判断convertView是否为空，不是为空的话就直接用那个已经存在的convertView来直接进行操作，代码如下：

@Override
public View getView(int position, View convertView, ViewGroup parent) {
	// TODO Auto-generated method stub
	Log.d("getView--->", convertView+"--position:"+position);
				
	if(convertView==null){
		convertView = inflater.inflate(R.layout.list_item, null);
	}

	TextView text = (TextView)convertView.findViewById(R.id.list_item_text);
	ImageView image = (ImageView)convertView.findViewById(R.id.list_item_image);
	text.setText(data.get(position).get("text").toString());
	image.setImageResource(Integer.parseInt(data.get(position).get("image").toString()));
		
	return convertView;
}

运行滑动到如下图：

打印结果:

注意我圈起来的两个地方，两个地址一模一样！所以我们成功重用了Recycle中缓存的视图，这样可以有效优化ListView的内存消耗（试想一下，100000个视图我来来回回只用那10个convertView,能不减少内存开销吗？）

ViewHolder的使用

以上只是利用convertView的重用来做到优化效果，但是注意到还是有存在问题，每个视图里面有一个text和一个image，每次都要通过findViewByID来找到它们，这也是一件庞大的工程...那既然我们可以重用convertView,那可不可以将这两个子控件也缓存起来呢？
我们可以通过自定义一个ViewHolder来，来进行子控件视图的缓存，以达到更佳的优化效果：

@Override
public View getView(int position, View convertView, ViewGroup parent) {
	// TODO Auto-generated method stub
	Log.d("getView--->", convertView+"--position:"+position);
				
	ViewHolder holder = null;
	if(convertView==null){
		convertView = inflater.inflate(R.layout.list_item, null);
		holder = new ViewHolder();
		holder.text = (TextView)convertView.findViewById(R.id.list_item_text);
		holder.image = (ImageView)convertView.findViewById(R.id.list_item_image);
		convertView.setTag(holder);
	}
	else{
		holder = (ViewHolder)convertView.getTag();
	}
		
	holder.text.setText(data.get(position).get("text").toString());
	holder.image.setImageResource(Integer.parseInt(data.get(position).get("image").toString()));
		
	return convertView;
}
	
public static class ViewHolder{
	public TextView text;
	public ImageView image;
}

代码分析：首先自定义了一个ViewHolder类，这里设置为static，这样ViewHolder无论new多少次都是指向同一个内存空间，在ViewHolder类中添加了两个成员变量，分别对应我们的子控件。每次getView的时候，同样先判断ViewHolder对象是否为空，如果为空，就实例化一个ViewHolder对象，并将convertView通过findViewById找到的子控件赋给holder,再将holder通过setTag()方法设置在convertView上，之后重用的时候可以通过convertView的getTag()来获得。其实ViewHolder相当于我们子控件的一个封装类而已，通过这样实现不用每次都去findViewById查找子控件，每次做的事情只是重用之前的视图和控件设置一下数据，达到优化的目的。

ListView多种子布局的重用方式

上面的操作虽然已经对ListView进行了一些优化，但是依然存在问题，如果所有的ListItem的布局并不是都一样（例如类似微信朋友圈，一些是图片，一些是文字，一些是小视频等等），就不能全部都用一样的ViewHolder或者convertView来处理了，因为重用的布局不一定适合新出现的ListItem，ListView中提供了另外两个方法：
getItemViewType(int position) 【根据下标返回当前视图的类型】
getViewTypeCount() 【返回类型的种类数】

代码如下：

public class ListViewAdapter extends SimpleAdapter{
	
	private Context context;
	
	private List<Map<String,Object>> data;
	
	private LayoutInflater inflater;
	
	//注意，这里定义的这些整型数要小于getViewTypeCount()所返回的那个数字，否则会报错越界
	private final int TYPE_1 = 0;
	private final int TYPE_2 = 1;
	
	public ListViewAdapter(Context context,
			List<Map<String, Object>> data, int resource, String[] from,
			int[] to) {
		super(context, data, resource, from, to);
		// TODO Auto-generated constructor stub
		this.context = context;
		this.data = data;
		inflater = LayoutInflater.from(context);
	}
	//返回数据的大小，即listview的行数
	@Override
	public int getCount() {
		// TODO Auto-generated method stub
		return data.size();
	}
	//根据下标获得某一行的数据
	@Override
	public Object getItem(int position) {
		// TODO Auto-generated method stub
		return data.get(position);
	}
	//获得指定的Item的下标
	@Override
	public long getItemId(int position) {
		// TODO Auto-generated method stub
		return position;
	}
	
	@Override
	public int getItemViewType(int position) {
		// TODO Auto-generated method stub
		//如果当前行是偶数行，返回类型1
		if(position%2==0){
			return TYPE_1;
		}
		//如果当前行是奇数行，返回类型2
		else{
			return TYPE_2;
		}
	}
	
	@Override
	public int getViewTypeCount() {
		// TODO Auto-generated method stub
		return 2;
	}
	
	@Override
	public View getView(int position, View convertView, ViewGroup parent) {
		// TODO Auto-generated method stub
		Log.d("getView--->", convertView+"--position:"+position);
				
		ViewHolder1 holder1 = null;
		ViewHolder2 holder2 = null;
		int type = getItemViewType(position);
		if(convertView==null){
			switch (type) {
			case TYPE_1:
				convertView = inflater.inflate(R.layout.list_item, null);
				holder1 = new ViewHolder1();
				holder1.text = (TextView)convertView.findViewById(R.id.list_item_text);
				holder1.image = (ImageView)convertView.findViewById(R.id.list_item_image);
				convertView.setTag(holder1);
				break;

			case TYPE_2:
				convertView = inflater.inflate(R.layout.list_item2, null);
				holder2 = new ViewHolder2();
				holder2.text = (TextView)convertView.findViewById(R.id.list_item_text2);
				holder2.detail = (TextView)convertView.findViewById(R.id.list_item_detail2);
				convertView.setTag(holder2);
				break;
			}
			
		}
		else{
			switch (type) {
			case TYPE_1:
				holder1 = (ViewHolder1)convertView.getTag();
				break;

			case TYPE_2:
				holder2 = (ViewHolder2)convertView.getTag();
				break;
			}
			
		}
		
		switch (type) {
			case TYPE_1:
				holder1.text.setText(data.get(position).get("text").toString());
				holder1.image.setImageResource(Integer.parseInt(data.get(position).get("image").toString()));
				break;
	
			case TYPE_2:
				holder2.text.setText(data.get(position).get("text").toString());
				holder2.detail.setText(data.get(position).get("text").toString());
				break;
		}
		
		
		
		return convertView;
	}
	
	public static class ViewHolder1{
		public TextView text;
		public ImageView image;
	}
	
	public static class ViewHolder2{
		public TextView text;
		public TextView detail;
	}

}

代码分析：创建另外一个ViewHolder，用于加载和重用另外一种布局，其实就是在原来的基础上，为每个操作都套上一层switch判断，然后根据type的类型来分别设置两种布局。

ListView异步加载乱序问题

出现乱序的原因

上面的操作都是属于同步加载每一行，所以不会出现什么问题。但如果当我们是网络异步加载每一行的图片时，就会出现数据紊乱，前文已经说了，Android为ListView进行的Reycler的处理，减少内存开销，那么，每当有新的元素进入界面时就会回调getView()方法，而在getView()方法中会开启异步请求从网络上获取图片，注意网络操作都是比较耗时的，也就是说当我们快速滑动ListView的时候就很有可能出现这样一种情况，某一个位置上的元素进入屏幕后开始从网络上请求图片，但是还没等图片下载完成，它就又被移出了屏幕。这种情况下会产生什么样的现象呢？根据ListView的工作原理，被移出屏幕的控件将会很快被新进入屏幕的元素重新利用起来，而如果在这个时候刚好前面发起的图片请求有了响应，就会将刚才位置上的图片显示到当前位置上，因为虽然它们位置不同，但都是共用的同一个ImageView实例，这样就出现了图片乱序的情况。但是还没完，新进入屏幕的元素它也会发起一条网络请求来获取当前位置的图片，等到图片下载完的时候会设置到同样的ImageView上面，因此就会出现先显示一张图片，然后又变成了另外一张图片的情况。

如何解决乱序问题？

由于篇幅问题这里附上郭神的一篇博文http://blog.csdn.net/guolin_blog/article/details/45586553很详细地讲解了三种方式来解决异步加载乱序。

总之，以上讲述了ListView的多种优化方式，但是并不是万能，也仅仅只是起到了一部分效果，真实开发中还要视情况而定，比如如果是多图片，首先需要将图片压缩，并且不要再getView中做过多的耗时操作！希望本文对大家理解ListView的优化有所帮助。

Android ListView优化篇