listview优化的问题总结

ListView的工做原理

 

ListView 针对每一个item，要求 adapter “返回一个视图” (getView)，也就是说ListView在开始绘制的时候，系统首先调用getCount（）函数，根据他的返回值获得ListView的长度，而后根据这个长度，调用getView（）一行一行的绘制ListView的每一项。若是你的getCount（）返回值是0的话，列表一行都不会显示，若是返回1，就只显示一行。返回几则显示几行。若是咱们有几千几万甚至更多的item要显示怎么办？为每一个Item建立一个新的View？不可能！！！实际上Android早已经缓存了这些视图，来理解下，这个图是解释ListView工做原理的最经典的图了你们能够收藏下，不懂的时候拿来看看，加深理解，其实Android中有个叫作Recycler的构件，顺带列举下与Recycler相关的已经由Google作过N多优化过的东东好比：AbsListView.RecyclerListener、ViewDebug.RecyclerTraceType等等，

 

一、若是你有几千几万甚至更多的选项(item)时，其中只有可见的项目存在内存（内存内存哦，说的优化就是说在内存中的优化！！！）中，其余的在Recycler中

二、ListView先请求一个type1视图(getView)而后请求其余可见的项目。convertView在getView中是空(null)的

三、当item1滚出屏幕，而且一个新的项目从屏幕低端上来时，ListView再请求一个type1视图。convertView此时不是空值了，它的值是item1。你只需设定新的数据而后返回convertView，没必要从新建立一个视图

1、复用convertView，减小findViewById的次数

一、优化一：复用convertView

Android系统自己为咱们考虑了ListView的优化问题，在复写的Adapter的类中，比较重要的两个方法是getCount()和getView()。界面上有多少个条显示，就会调用多少次的getView()方法；所以若是在每次调用的时候，若是不进行优化，每次都会使用View.inflate(….)的方法，都要将xml文件解析，并显示到界面上，这是很是消耗资源的：由于有新的内容产生就会有旧的内容销毁，因此，能够复用旧的内容。

优化：

在getView()方法中，系统就为咱们提供了一个复用view的历史缓存对象convertView，当显示第一屏的时候，每个item都会新建立一个view对象，这些view都是能够被复用的；若是每次显示一个view都要建立一个，是很是耗费内存的；因此为了节约内存，能够在convertView不为null的时候，对其进行复用

二、优化二：缓存item条目的引用——ViewHolder

    findViewById()这个方法是比较耗性能的操做，由于这个方法要找到指定的布局文件，进行不断地解析每一个节点：从最顶端的节点进行一层一层的解析查询，找到后在一层一层的返回，若是在左边没找到，就会接着解析右边，并进行相应的查询，直到找到位置（如图）。所以能够对findViewById进行优化处理，须要注意的是：

》》》》特色：xml文件被解析的时候，只要被建立出来了，其孩子的id就不会改变了。根据这个特色，能够将孩子id存入到指定的集合中，每次就能够直接取出集合中对应的元素就能够了。

优化：

在建立view对象的时候，减小布局文件转化成view对象的次数；即在建立view对象的时候，把全部孩子所有找到，并把孩子的引用给存起来

①定义存储控件引用的类ViewHolder

这里的ViewHolder类须要不须要定义成static，根据实际状况而定，若是item不是不少的话，可使用，这样在初始化的时候，只加载一次，能够稍微获得一些优化

不过，若是item过多的话，建议不要使用。由于static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。因此用static修饰的变量，它的生命周期是很长的，若是用它来引用一些资源耗费过多的实例（好比Context的状况最多），这时就要尽可能避免使用了。

    class ViewHolder{

                      //定义item中相应的控件

             }

②建立自定义的类：ViewHolder holder = null;

③将子view添加到holder中：

在建立新的listView的时候，建立新的ViewHolder，把全部孩子所有找到，并把孩子的引用给存起来

经过view.setTag(holder)将引用设置到view中

经过holder，将孩子view设置到此holder中，从而减小之后查询的次数

④在复用listView中的条目的时候，经过view.getTag()，将view对象转化为holder，即转化成相应的引用，方便在下次使用的时候存入集合。

  经过view.getTag(holder)获取引用（须要强转）

 

2、ListView中数据的分批及分页加载：

需求：ListView有一万条数据，如何显示；若是将十万条数据加载到内存，很消耗内存

解决办法：

优化查询的数据：先获取几条数据显示到界面上

进行分批处理---à优化了用户体验

进行分页处理---à优化了内存空间

说明：

通常数据都是从数据库中获取的，实现分批（分页）加载数据，就须要在对应的DAO中有相应的分批（分页）获取数据的方法，如findPartDatas ()

一、准备数据：

    在dao中添加分批加载数据的方法：findPartDatas ()

    在适配数据的时候，先加载第一批的数据，须要加载第二批的时候，设置监听检测什么时候加载第二批

二、设置ListView的滚动监听器：setOnScrollListener(new OnScrollListener{….})

①、在监听器中有两个方法：滚动状态发生变化的方法(onScrollStateChanged)和listView被滚动时调用的方法(onScroll)

②、在滚动状态发生改变的方法中，有三种状态：

手指按下移动的状态：                          SCROLL_STATE_TOUCH_SCROLL: // 触摸滑动

惯性滚动（滑翔（flgin）状态）：   SCROLL_STATE_FLING: // 滑翔

静止状态：                                          SCROLL_STATE_IDLE: // 静止

三、对不一样的状态进行处理：

分批加载数据，只关心静止状态：关心最后一个可见的条目，若是最后一个可见条目就是数据适配器（集合）里的最后一个，此时可加载更多的数据。在每次加载的时候，计算出滚动的数量，当滚动的数量大于等于总数量的时候，能够提示用户无更多数据了。

3、复杂ListView的处理：（待进一步总结）

说明：

    listView的界面显示是经过getCount和getView这两个方法来控制的

    getCount：返回有多少个条目

    getView：返回每一个位置条目显示的内容

提供思路：

    对于含有多个类型的item的优化处理：因为ListView只有一个Adapter的入口，能够定义一个总的Adapter入口，存放各类类型的Adapter

以安全卫士中的进程管理的功能为例。效果如图：

一、定义两个（或多个）集合

    每一个集合中存入的是对应不一样类型的内容（这里为：用户程序（userAppinfos）和系统程序的集合（systemAppinfos））

二、在初始化数据（填充数据）中初始化两个集合

    如，此处是在fillData方法中初始化

三、在数据适配器中，复写对应的方法

    getCount()：计算全部须要显示的条目个数，这里包括listView和textView

    getView()：对显示在不一样位置的条目进行if处理

四、数据类型的判断

    须要注意的是，在复用view的时候，须要对convertView进行类型判断，是由于这里含有各类不一样类型的view，在view滚动显示的时候，对于不一样类型的view不能复用，全部须要判断

4、ListView中图片的优化：详看OOM异常中图片的优化

一、处理图片的方式：

若是自定义Item中有涉及到图片等等的，必定要狠狠的处理图片，图片占的内存是ListView项中最恶心的，处理图片的方法大体有如下几种：

①、不要直接拿路径就去循环decodeFile();使用Option保存图片大小、不要加载图片到内存去

②、拿到的图片必定要通过边界压缩

③、在ListView中取图片时也不要直接拿个路径去取图片，而是以WeakReference（使用WeakReference代替强引用。

好比可使用WeakReference mContextRef）、SoftReference、WeakHashMap等的来存储图片信息，是图片信息不是图片哦！

④、在getView中作图片转换时，产生的中间变量必定及时释放

2、异步加载图片基本思想：

1）、 先从内存缓存中获取图片显示（内存缓冲）

2）、获取不到的话从SD卡里获取（SD卡缓冲）

3）、都获取不到的话从网络下载图片并保存到SD卡同时加入内存并显示（视状况看是否要显示）

原理：

优化一：先从内存中加载，没有则开启线程从SD卡或网络中获取，这里注意从SD卡获取图片是放在子线程里执行的，不然快速滑屏的话会不够流畅。

优化二：与此同时，在adapter里有个busy变量，表示listview是否处于滑动状态，若是是滑动状态则仅从内存中获取图片，没有的话无需再开启线程去外存或网络获取图片。

优化三：ImageLoader里的线程使用了线程池，从而避免了过多线程频繁建立和销毁，有的童鞋每次老是new一个线程去执行这是很是不可取的，好一点的用的AsyncTask类，其实内部也是用到了线程池。在从网络获取图片时，先是将其保存到sd卡，而后再加载到内存，这么作的好处是在加载到内存时能够作个压缩处理，以减小图片所占内存。

Tips：这里可能出现图片乱跳（错位）的问题：

图片错位问题的本质源于咱们的listview使用了缓存convertView，假设一种场景，一个listview一屏显示九个item，那么在拉出第十个item的时候，事实上该item是重复使用了第一个item，也就是说在第一个item从网络中下载图片并最终要显示的时候，其实该item已经不在当前显示区域内了，此时显示的后果将可能在第十个item上输出图像，这就致使了图片错位的问题。因此解决之道在于可见则显示，不可见则不显示。在ImageLoader里有个imageViews的map对象，就是用于保存当前显示区域图像对应的url集，在显示前判断处理一下便可。

 

三、内存缓冲机制：

首先限制内存图片缓冲的堆内存大小，每次有图片往缓存里加时判断是否超过限制大小，超过的话就从中取出最少使用的图片并将其移除。

固然这里若是不采用这种方式，换作软引用也是可行的，两者目的皆是最大程度的利用已存在于内存中的图片缓存，避免重复制造垃圾增长GC负担；OOM溢出每每皆因内存瞬时大量增长而垃圾回收不及时形成的。只不过两者区别在于LinkedHashMap里的图片缓存在没有移除出去以前是不会被GC回收的，而SoftReference里的图片缓存在没有其余引用保存时随时都会被GC回收。因此在使用LinkedHashMap这种LRU算法缓存更有利于图片的有效命中，固然两者配合使用的话效果更佳，即从LinkedHashMap里移除出的缓存放到SoftReference里，这就是内存的二级缓存。

 

5、ListView的其余优化：

一、尽可能避免在BaseAdapter中使用static 来定义全局静态变量：

static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。因此用static修饰的变量，它的生命周期是很长的，若是用它来引用一些资源耗费过多的实例（好比Context的状况最多），这时就要尽可能避免使用了。

二、尽可能使用getApplicationContext：

若是为了知足需求下必须使用Context的话：Context尽可能使用Application Context，由于Application的Context的生命周期比较长，引用它不会出现内存泄露的问题

三、尽可能避免在ListView适配器中使用线程：

由于线程产生内存泄露的主要缘由在于线程生命周期的不可控制。以前使用的自定义ListView中适配数据时使用AsyncTask自行开启线程的，这个比用Thread更危险，由于Thread只有在run函数不结束时才出现这种内存泄露问题，然而AsyncTask内部的实现机制是运用了线程执行池（ThreadPoolExcutor）,这个类产生的Thread对象的生命周期是不肯定的，是应用程序没法控制的，所以若是AsyncTask做为Activity的内部类，就更容易出现内存泄露的问题。解决办法以下：

①、将线程的内部类，改成静态内部类。

②、在线程内部采用弱引用保存Context引用