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);
           }  
        }  
 };