ListView是Android应用中的最常用控件之一，能够实现列表显示数据功能。在本节的内容中，将通过具体的演示代码来测试ListView控件的性能。

（1）首先看如下测试代码：

通过上述代码模拟了1000条数据，设置了TestAdapter继承于BaseAdapter。

（2）手动滑动ListView，当位置变量position到50时往回滑动，充分利用convertView不等于null的代码段。为了实现具体测试功能，我们用如下三种方案进行测试。

方案1：把item子元素分别改为4个和10个，这样做的目的是使效果更加明显。

上述方案的测试结果如表6-1所示。

表6-1 测试结果（单位是：纳秒）

方案2：把item子元素分别改为4个和10个。

(www.daowen.com)

上述方案的测试结果如表6-2所示。

表6-2 测试结果（单位是：纳秒）

方案3：原理是减少findViewById次数，并顺便测试不使用静态内部类情况下性能。

上述方案的测试结果如下（单位：纳秒）

执行上述三种方案，经过测试后发现，只有第一屏（可视范围）调用getView所消耗的时间远远多于后面的，通过对“convertView==null”内代码监控后发现也是同样的结果。也就是说，ListView仅仅缓存了可视范围内的View，随后的滚动都是对这些View进行数据更新。无论有多少数据，ListView都只用ArrayList缓存可视范围内的View，这样保证了性能，也造成了ListView只缓存View结构不缓存数据的假相。这也是上述优化方案1比2要好很多的原因，那么剩下的工作也就只有findViewById比较耗时了。

根据上述原理可以推到出，如下代码运行后会发现滚动时会重复显示第一屏的数据。

在上述代码中，因为子控件里的事件是同一个控件，所以也可以直接放到“convertView==null”代码块内部，如果需要交互数据比如position，可以通过tag方式来设置并获取当前数据。

在上述三种方案中，推荐如果只是一般的应用（一般指子控件不多）无需都是用静态内部类来优化，使用第2种方案即可；反之，如果是对性能要求较高时可采用。此外需要提醒的是，这里也是用空间换时间的做法，View本身因为setTag而会占用更多的内存，还会增加代码量；而findViewById会临时消耗更多的内存，所以不可盲目使用，需要依实际情况而定。至于方案3，原理是减少findViewById次数，但是从测试结果来看效果并不理想，所以在此不再做进一步的测试和讨论。