ListView的工作原理如下：
ListView 针对每个item，要求 adapter “返回一个视图” (getView)，也就是说ListView在开始绘制的时候，系统首先调用getCount()，根据他的返回值得到ListView的长度，然后根据这个长度，调用getView()一行一行的绘制ListView的每一项。如果你的getCount()返回值是0的话，列表一行都不会显示，返回几则显示几行。
RecycleBin机制：
这个机制也是ListView能够实现成百上千条数据都不会OOM最重要的一个原因。它是写在AbsListView中的一个内部类，所以所有继承自AbsListView的子类，也就是ListView和GridView，都可以使用这个机制。
下面简单说下图的原理：
1) 如果你有很多的选项(item)时，只有可见的项目存在内存中，其他的在Recycler中
2) ListView先请求一个type1视图(getView)然后请求其他可见的项目。convertView在getView中是空的
3) 当item1滚出屏幕，并且一个新的项目从屏幕低端上来时，ListView再请求一个type1视图。convertView此时不是空值了，它的值是item1。你只需设定新的数据然后返回convertView，不必重新创建一个视图
优化：
1) ViewHolder，Tag 必不可少
2) 如果自定义Item中有涉及到图片等等的，一定要狠狠的处理图片，图片占的内存是ListView项中最恶心的，处理图片的方法大致有以下几种：
A：不要直接拿个路径就去循环decodeFile();。用Option保存图片大小、不要加载图片到内存去；
B：拿到的图片一定要经过边界压缩
C： 在ListView中取图片时也不要直接拿个路径去取图片，而是以WeakReference、SoftReference、WeakHashMap等的来存储图片信息，是图片信息不是图片哦！
D：在getView中做图片转换时，产生的中间变量一定及时释放，用以下形式：
- 尽量避免在BaseAdapter中使用static 来定义全局静态变量；
- Context尽量使用Application Context，它的生命周期比较长，不会出现内存泄露的问题
- 尽量避免在ListView适配器中使用线程，因为线程产生内存泄露的主要原因在于线程生命周期的不可控制
问题注意：之前使用的自定义ListView中适配数据时使用AsyncTask自行开启线程的，这个比用Thread更危险，因为Thread只有在run函数不结束时才出现这种内存泄露问题，然而AsyncTask内部的实现机制是运用了线程执行池（ThreadPoolExcutor），这个类产生的Thread对象的生命周期是不确定的，是应用程序无法控制的，因此如果AsyncTask作为Activity的内部类，就更容易出现内存泄露的问题。
解决方法：1）将线程的内部类，改为静态内部类。2）在线程内部采用弱引用保存Context引用
滑动不加载：给listview添加OnScrollListener监听事件，只加载滑动停止后可见区域的内容。
OnScrollListener loadListener=new OnScrollListener() {
@Override
public void onScroll(AbsListView view, int firstVisibleItem, int visibleItemCount, int totalItemCount) {
lastItem = firstVisibleItem + visibleItemCount;
}
@Override
public void onScrollStateChanged(AbsListView view, int scrollState) {
if (scrollState == OnScrollListener.SCROLL_STATE_IDLE) {
pageImgLoad(_start_index, _end_index);
}
}
};