Listview异步加载图片之优化篇(有图有码有解释)
2014-03-22 22:18
239 查看
在APP应用中,listview的异步加载图片方式能够带来很好的用户体验,同时也是考量程序性能的一个重要指标。关于listview的异步加载,网上其实很多示例了,中心思想都差不多,不过很多版本或是有bug,或是有性能问题有待优化。有鉴于此,本人在网上找了个相对理想的版本并在此基础上进行改造,下面就让在下阐述其原理以探索个中奥秘,与诸君共赏…
贴张效果图先:
异步加载图片基本思想:
1. 先从内存缓存中获取图片显示(内存缓冲)
2. 获取不到的话从SD卡里获取(SD卡缓冲)
3. 都获取不到的话从网络下载图片并保存到SD卡同时加入内存并显示(视情况看是否要显示)
OK,先上adapter的代码:
关键代码是ImageLoader的DisplayImage方法,再看ImageLoader的实现
先从内存中加载,没有则开启线程从SD卡或网络中获取,这里注意从SD卡获取图片是放在子线程里执行的,否则快速滑屏的话会不够流畅,这是优化一。于此同时,在adapter里有个busy变量,表示listview是否处于滑动状态,如果是滑动状态则仅从内存中获取图片,没有的话无需再开启线程去外存或网络获取图片,这是优化二。ImageLoader里的线程使用了线程池,从而避免了过多线程频繁创建和销毁,有的童鞋每次总是new一个线程去执行这是非常不可取的,好一点的用的AsyncTask类,其实内部也是用到了线程池。在从网络获取图片时,先是将其保存到sd卡,然后再加载到内存,这么做的好处是在加载到内存时可以做个压缩处理,以减少图片所占内存,这是优化三。
而图片错位问题的本质源于我们的listview使用了缓存convertView,假设一种场景,一个listview一屏显示九个item,那么在拉出第十个item的时候,事实上该item是重复使用了第一个item,也就是说在第一个item从网络中下载图片并最终要显示的时候其实该item已经不在当前显示区域内了,此时显示的后果将是在可能在第十个item上输出图像,这就导致了图片错位的问题。所以解决之道在于可见则显示,不可见则不显示。在ImageLoader里有个imageViews的map对象,就是用于保存当前显示区域图像对应的url集,在显示前判断处理一下即可。
下面再说下内存缓冲机制,本例采用的是LRU算法,先看看MemoryCache的实现
首先限制内存图片缓冲的堆内存大小,每次有图片往缓存里加时判断是否超过限制大小,超过的话就从中取出最少使用的图片并将其移除,当然这里如果不采用这种方式,换做软引用也是可行的,二者目的皆是最大程度的利用已存在于内存中的图片缓存,避免重复制造垃圾增加GC负担,OOM溢出往往皆因内存瞬时大量增加而垃圾回收不及时造成的。只不过二者区别在于LinkedHashMap里的图片缓存在没有移除出去之前是不会被GC回收的,而SoftReference里的图片缓存在没有其他引用保存时随时都会被GC回收。所以在使用LinkedHashMap这种LRU算法缓存更有利于图片的有效命中,当然二者配合使用的话效果更佳,即从LinkedHashMap里移除出的缓存放到SoftReference里,这就是内存的二级缓存,有兴趣的童鞋不凡一试。
可上github下载
github下载地址:https://github.com/geniusgithub/SyncLoaderBitmapDemo
转载自:http://www.eoeandroid.com/thread-254866-1-1.html
贴张效果图先:
异步加载图片基本思想:
1. 先从内存缓存中获取图片显示(内存缓冲)
2. 获取不到的话从SD卡里获取(SD卡缓冲)
3. 都获取不到的话从网络下载图片并保存到SD卡同时加入内存并显示(视情况看是否要显示)
OK,先上adapter的代码:
关键代码是ImageLoader的DisplayImage方法,再看ImageLoader的实现
先从内存中加载,没有则开启线程从SD卡或网络中获取,这里注意从SD卡获取图片是放在子线程里执行的,否则快速滑屏的话会不够流畅,这是优化一。于此同时,在adapter里有个busy变量,表示listview是否处于滑动状态,如果是滑动状态则仅从内存中获取图片,没有的话无需再开启线程去外存或网络获取图片,这是优化二。ImageLoader里的线程使用了线程池,从而避免了过多线程频繁创建和销毁,有的童鞋每次总是new一个线程去执行这是非常不可取的,好一点的用的AsyncTask类,其实内部也是用到了线程池。在从网络获取图片时,先是将其保存到sd卡,然后再加载到内存,这么做的好处是在加载到内存时可以做个压缩处理,以减少图片所占内存,这是优化三。
而图片错位问题的本质源于我们的listview使用了缓存convertView,假设一种场景,一个listview一屏显示九个item,那么在拉出第十个item的时候,事实上该item是重复使用了第一个item,也就是说在第一个item从网络中下载图片并最终要显示的时候其实该item已经不在当前显示区域内了,此时显示的后果将是在可能在第十个item上输出图像,这就导致了图片错位的问题。所以解决之道在于可见则显示,不可见则不显示。在ImageLoader里有个imageViews的map对象,就是用于保存当前显示区域图像对应的url集,在显示前判断处理一下即可。
下面再说下内存缓冲机制,本例采用的是LRU算法,先看看MemoryCache的实现
首先限制内存图片缓冲的堆内存大小,每次有图片往缓存里加时判断是否超过限制大小,超过的话就从中取出最少使用的图片并将其移除,当然这里如果不采用这种方式,换做软引用也是可行的,二者目的皆是最大程度的利用已存在于内存中的图片缓存,避免重复制造垃圾增加GC负担,OOM溢出往往皆因内存瞬时大量增加而垃圾回收不及时造成的。只不过二者区别在于LinkedHashMap里的图片缓存在没有移除出去之前是不会被GC回收的,而SoftReference里的图片缓存在没有其他引用保存时随时都会被GC回收。所以在使用LinkedHashMap这种LRU算法缓存更有利于图片的有效命中,当然二者配合使用的话效果更佳,即从LinkedHashMap里移除出的缓存放到SoftReference里,这就是内存的二级缓存,有兴趣的童鞋不凡一试。
可上github下载
github下载地址:https://github.com/geniusgithub/SyncLoaderBitmapDemo
转载自:http://www.eoeandroid.com/thread-254866-1-1.html
相关文章推荐
- Listview 异步加载图片之优化篇(有图有码有解释)
- Listview异步加载图片之优化篇(有图有码有解释)
- Listview异步加载图片之优化篇(有图有码有解释)
- Listview异步加载图片之优化篇(有图有码有解释) ...
- [Android实例]Listview异步加载图片之优化篇(有图有码有解释)
- Listview异步加载图片之优化篇(有图有码有解释)
- Android ListView&异步加载的学习(三)——AsyncTask加载图片&运用Lru算法优化图片加载
- Android进阶:ListView性能优化异步加载图片 使滑动效果流畅
- listview异步加载图片(深度优化)(转载)
- ListView优化,获取网络图片异步加载,分批加载,分页显示,图片缓存等优化方式
- listview异步图片加载之优化篇
- android-------用双缓存技术优化listview异步加载网络图片
- listview异步图片加载之优化篇(android)
- Listview异步加载图片之优化篇
- Android进阶:ListView性能优化异步加载图片 使滑动效果流畅
- ListView的常见优化:获取网络图片异步加载,分批加载,分页显示,图片缓存等优化方式
- ListView的常见优化:获取网络图片异步加载,分批加载,分页显示,图片缓存等优化方式
- 进一步优化Android ListView GridView中异步加载图片
- Android之ListView异步加载网络图片(优化缓存机制)和对图片资源进行优化,并且实现内存双缓存 + 磁盘缓存
- Android异步加载学习笔记之四:利用缓存优化网络加载图片及ListView加载优化