Android中Listview的优化

说起Listview的优化，老生常谈啊，面试必问的一个点。我在筛选面试简历的时候，发现一个童鞋简历上写着ListView优化使用三级缓存？什么鬼？我孤陋寡闻了，哈哈，之前还真不知道，网上看了下零零散散，这方面的讲解并不是很详细，搜罗了几篇文章，我在这里做一下整合，回头好好研究一下，大家共同学习。

首先Listview是需要和适配器配合使用的，常用的适配器有ArrayAdapter，SimplerAdapter，SimpleCursorAdapter，BaseAdapter，一般情况下我使用最多的是继承BaseAdapter，实现它的四个方法，其中最重要的两个方法，getCount和getView。在不做任何处理的情况下getview每次都重新生成一个view，这样的结果就是很消耗内存，谷歌官网提供了优化listview内存的方法，通过ConvertView的复用和使用ViewHolder来减少findbyid的次数，从而达到控件的复用和减少cpu的消耗，但是因为控件的复用，在加载图片的时候,复用的控件里面有残留的图片，从而造成图片的错位，所以我们必须在初始化的时候设置默认图片来清除缓存的图片，同时在加载的时候图片的时候,如果不进行listview的性能优化,就会造成OOM，所以一般情况下我们会加载二次采样过后的url，同时我们会进行三级缓存的处理。

一、三级缓存

首先从强引用中获取(Lrucache)，如果强引用中没有再去软引用中获取(SoftReference)，如果软引用中没有再去SD卡获取(SD卡被DisLrucache替代掉)，如果这三级缓存中都没有就开启网络去请求图片，请求回来的图片在加入到强引用中(Lrucache)，如果强引用已经满了，这时候强引用通过Lrucache算法删除掉一些最近不常用的图片，并把这些图片放到软引用里面，当内存不足到时候软引用就会被被垃圾回收机制回收，如果垃圾回收机制没有，软引用也满了，将不常用的图片移除掉，同时加入到SD卡(现在被DisLrucache替代)，key 一般使用的是网络请求图片的url，来保证唯一性，一般情况下我会做一下MD5加密，这样做的目的是为了保证不会出现非法字符。

现在SoftReference已经被替代掉，现在我们只使用两级缓存，再加网络，Lrucache，DisLrucache，LRC算法：最近最少使用的(内部如何实现的)
强引用:Lrucache
软引用:SoftReference
弱引用:weak(随时被垃圾回收机制回收)
虚引用:phantomreference
可定义图片异步加载工具类，核心方式实现思路如下：

1. 先从内存缓存（Map< String,SoftReference< Bitmap>>中获取图片显示
2. 获取不到的话从本地SD卡里获取并显示
3. 都获取不到的话通过子线程从网络加载图片并保存到内存及SD卡中并通过handler显示

二、二次采样

Bitmap二次采样，听着好像是一个高大上的事，其实也就那么回事，今天我们就来看看Bitmap的二次采样问题。

1、为什么要二次采样

OK，那么首先我要 解决的一个问题就是为什么我们要二次采样？
不知道大家在开发App的过程中有没有遇到过类似于图片墙这样的功能？在做图片墙的时候你有没有遇到过OOM异常呢？遇到了又是怎么解决的？再比如我现在有一张100M大的图片，我想把这张图片用一个ImageView显示出来，那么你的ImageView能够显示出来这张图片吗？上面我们说的这两种情况其实都涉及到图片加载时内存溢出的问题，内存溢出可能发生在加载一张大图的时候，也有可能发生在加载多张普通小图的时候，如果我们不对图片做二次采样，那么OOM就是一把悬在头上的剑，随时可能会掉下。所以一定要对图片进行二次采样。事实上，我在手机上显示一张分辨率特别大的图片和显示一张分辨率小的图片（不要小的太离谱即可），对用户的视觉体验来说，并不会有多大变化，但是对我们手机的内存来说，影响却是非常巨大的。总而言之，二次采样就是为了避免图片加载时的OOM异常。

2、Bitmap概述

Android系统支持几种图片(.png (preferred)， .jpg (acceptable)，.gif (discouraged))，其中Bitmap位图#ffffffff，包括图片透明度Alpha和RGB，图片质量很好，每一个像素位占4个字节，如果图片很大将会占据很大的内存空间。存储在SDCard的image很小，加载进内存可能就会很大。因此，对bitmap图像进行操作，应该特别小心，可能出现内存溢出问题。为此对于大图片，应该引入该图片的二次采样生成缩略图。

3、Bitmap缩略图

首先尝试通过字节数组或者流，只去加载图片的外边缘，此时必须指定BitmapFactory.Options 的inJustDecodeBounds成员名，将其只为true，一旦设置为true，BitmapFactory解码后返回值为null，通过Options的outHeight和outWidth可以获得图片的宽高。然后根据大小制定合适的缩放比例，通过options.inSampleSize，大大降低加载图片导致内存溢出的风险！

/**  * 根据图片字节数组，对图片可能进行二次采样，不致于加载过大图片出现内存溢出  * @param bytes  * @return  */  public static Bitmap getBitmapByBytes(byte[] bytes){      //对于图片的二次采样,主要得到图片的宽与高      int width = 0;      int height = 0;      int sampleSize = 1; //默认缩放为1      BitmapFactory.Options options = new BitmapFactory.Options();      options.inJustDecodeBounds = true;  //仅仅解码边缘区域      //如果指定了inJustDecodeBounds，decodeByteArray将返回为空      BitmapFactory.decodeByteArray(bytes, 0, bytes.length, options);      //得到宽与高      height = options.outHeight;      width = options.outWidth;      //图片实际的宽与高，根据默认最大大小值，得到图片实际的缩放比例      while ((height / sampleSize > Cache.IMAGE_MAX_HEIGHT)              || (width / sampleSize > Cache.IMAGE_MAX_WIDTH)) {          sampleSize *= 2;      }      //不再只加载图片实际边缘      options.inJustDecodeBounds = false;      //并且制定缩放比例      options.inSampleSize = sampleSize;      return BitmapFactory.decodeByteArray(bytes, 0, bytes.length, options);  }  

4、二次采样分别是哪两次？每次采样的目的是什么

既然是二次采样，那当然要分为两步了，下面我们来说说每次采样的主要工作：

4.1 第一次采样

第一次采样我主要是想要获得图片的压缩比例，假如说我有一张图片是200*200，那么我想把这张图片的缩略图显示在一个50*50的ImageView上，那我的压缩比例应该为4，那么这个4应该怎么样来获得呢？这就是我们第一步的操作了，我先加载图片的边界到内存中，这个加载操作并不会耗费多少内存，加载到内存之后，我就可以获得这张图片的宽高参数，然后根据图片的宽高，再结合控件的宽高计算出缩放比例。

4.2 第二次采样

在第一次采样的基础上，我来进行二次采样。二次采样的时候，我把第一次采样后算出来的结果作为一个参数传递给第BitmapFactory，这样在加载图片的时候系统就不会将整张图片加载进来了，而是只会加载该图片的一张缩略图进来，这样不仅提高了加载速率，而且也极大的节省了内存，而且对于用户来说，他也不会有视觉上的差异。

4.3 代码实现

说了这么多，我们来看看在Java代码中该怎么实现二次采样：

public class BitmapUtils {      /**      * @param filePath   要加载的图片路径      * @param destWidth  显示图片的控件宽度      * @param destHeight 显示图片的控件的高度      * @return      */      public static Bitmap getBitmap(String filePath, int destWidth, int destHeight) {          //第一次采样          BitmapFactory.Options options = new BitmapFactory.Options();          //该属性设置为true只会加载图片的边框进来，并不会加载图片具体的像素点          options.inJustDecodeBounds = true;          //第一次加载图片，这时只会加载图片的边框进来，并不会加载图片中的像素点          BitmapFactory.decodeFile(filePath, options);          //获得原图的宽和高          int outWidth = options.outWidth;          int outHeight = options.outHeight;          //定义缩放比例          int sampleSize = 1;          while (outHeight / sampleSize > destHeight || outWidth / sampleSize > destWidth) {              //如果宽高的任意一方的缩放比例没有达到要求，都继续增大缩放比例              //sampleSize应该为2的n次幂，如果给sampleSize设置的数字不是2的n次幂，那么系统会就近取值              sampleSize *= 2;          }  /********************************************************************************************/          //至此，第一次采样已经结束，我们已经成功的计算出了sampleSize的大小  /********************************************************************************************/        //二次采样开始          //二次采样时我需要将图片加载出来显示，不能只加载图片的框架，因此inJustDecodeBounds属性要设置为false          options.inJustDecodeBounds = false;          //设置缩放比例          options.inSampleSize = sampleSize;          options.inPreferredConfig = Bitmap.Config.ARGB_8888;          //加载图片并返回          return BitmapFactory.decodeFile(filePath, options);      }  }  

——————————接下来罗列一下平常对Android中Listview的优化——————————

优化一：复用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)获取引用（需要强转）

优化三、ListView中数据的分批及分页加载

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

解决办法：

• 优化查询的数据：先获取几条数据显示到界面上
• 进行分批处理—à优化了用户体验
• 进行分页处理—à优化了内存空间

说明：
一般数据都是从数据库中获取的，实现分批（分页）加载数据，就需要在对应的DAO中有相应的分批（分页）获取数据的方法，如findPartDatas ()

1、准备数据：
在dao中添加分批加载数据的方法：findPartDatas ()
在适配数据的时候，先加载第一批的数据，需要加载第二批的时候，设置监听检测何时加载第二批

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

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

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

• 手指按下移动的状态：SCROLL_STATE_TOUCH_SCROLL: // 触摸滑动
• 惯性滚动（滑翔（flgin）状态）：SCROLL_STATE_FLING: // 滑翔
• 静止状态：SCROLL_STATE_IDLE: // 静止

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

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

1、处理图片的方式：

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

1. 不要直接拿路径就去循环decodeFile();使用Option保存图片大小、不要加载图片到内存去
2. 拿到的图片一定要经过边界压缩
3. 在ListView中取图片时也不要直接拿个路径去取图片，而是以WeakReference（使用WeakReference代替强引用。比如可以使用WeakReference mContextRef）、SoftReference、WeakHashMap等的来存储图片信息，是图片信息不是图片哦！
4. 在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集，在显示前判断处理一下即可。

3、内存缓冲机制：

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

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

本例采用的是LRU算法，先看看MemoryCache的实现

public class MemoryCache {        private static final String TAG = "MemoryCache";// 放入缓存时是个同步操作        // LinkedHashMap构造方法的最后一个参数true代表这个map里的元素将按照最近使用次数由少到多排列，即LRU        // 这样的好处是如果要将缓存中的元素替换，则先遍历出最近最少使用的元素来替换以提高效率        private Map<String, Bitmap> cache = Collections                        .synchronizedMap(new LinkedHashMap<String, Bitmap>(10, 1.5f, true));        // 缓存中图片所占用的字节，初始0，将通过此变量严格控制缓存所占用的堆内存        private long size = 0;// current allocated size        // 缓存只能占用的最大堆内存        private long limit = 1000000;// max memory in bytes         public MemoryCache() {                // use 25% of available heap size                setLimit(Runtime.getRuntime().maxMemory() / 10);        }        public void setLimit(long new_limit) {                limit = new_limit;                Log.i(TAG, "MemoryCache will use up to " + limit / 1024. / 1024. + "MB");        }        public Bitmap get(String id) {                try {                        if (!cache.containsKey(id))                                return null;                        return cache.get(id);                } catch (NullPointerException ex) {                        return null;                }        }        public void put(String id, Bitmap bitmap) {                try {                        if (cache.containsKey(id))                                size -= getSizeInBytes(cache.get(id));                        cache.put(id, bitmap);                        size += getSizeInBytes(bitmap);                        checkSize();                } catch (Throwable th) {                        th.printStackTrace();                }        }         /**         * 严格控制堆内存，如果超过将首先替换最近最少使用的那个图片缓存         */        private void checkSize() {                Log.i(TAG, "cache size=" + size + " length=" + cache.size());                if (size > limit) {                        // 先遍历最近最少使用的元素                        Iterator<Entry<String, Bitmap>> iter = cache.entrySet().iterator();                        while (iter.hasNext()) {                                Entry<String, Bitmap> entry = iter.next();                                size -= getSizeInBytes(entry.getValue());                                iter.remove();                                if (size <= limit)                                        break;                        }                        Log.i(TAG, "Clean cache. New size " + cache.size());                }        }        public void clear() {          cache.clear();        }        /**         * 图片占用的内存         * @Param bitmap         * @return         */        long getSizeInBytes(Bitmap bitmap) {                if (bitmap == null)                        return 0;                return bitmap.getRowBytes() * bitmap.getHeight();        }}

优化五、ListView的其他优化：

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

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

2、尽量使用getApplicationContext：

如果为了满足需求下必须使用Context的话：Context尽量使用Application Context，因为Application的Context的生命周期比较长，引用它不会出现内存泄露的问题

3、尽量避免在ListView适配器中使用线程：

因为线程产生内存泄露的主要原因在于线程生命周期的不可控制。之前使用的自定义ListView中适配数据时使用AsyncTask自行开启线程的，这个比用Thread更危险，因为Thread只有在run函数不结束时才出现这种内存泄露问题，然而AsyncTask内部的实现机制是运用了线程执行池（ThreadPoolExcutor）,这个类产生的Thread对象的生命周期是不确定的，是应用程序无法控制的，因此如果AsyncTask作为Activity的内部类，就更容易出现内存泄露的问题。

解决办法如下：
①、将线程的内部类，改为静态内部类。
②、在线程内部采用弱引用保存Context引用

---

这么多回答，加在一起已经非常详细了，我来总结一下：

• 复用convertView对象，减小内存压力
• 使用ViewHolder，减少findViewById次数
• 使用图片缓存、压缩图片、异步加载图片
• listview滑动的时候，不加载图片，让滑动更加流畅
• 只加载可见item的图片

作者：王小狼
链接：https://www.zhihu.com/question/19703384/answer/57172899
来源：知乎
著作权归作者所有，转载请联系作者获得授权。

---

文章来源：
1、Listview:性能优化，三级缓存，二次采样
2、Android_Bitmap_图片的二次采样并生成缩略图
3、Android开发之Bitmap二次采样
4、Android性能优化–Listview优化