原blog地址:http://blog.csdn.net/hknock/article/details/9329761
问题:列表滑动不流畅,容易出现Out Of Memory的Bug
1.问题:
之前做图片频道,一个列表含有20+个条目,每个条目包含一个大小为50K左右的图片。图片是通过网络异步获取的,返回结果后调用notifyDataSetChanged()方法刷新列表。存在的问题是当图片没有加载完成时,上下滑动列表非常卡,点击“加载更多”后,列表增加到40+个条目,很容易就出现OOM的Bug。
2.分析:
引起滑动不流畅的主要原因是在异步返回图片后整个刷新列表,尤其是列表正处于滚动状态。造成OOM的原因是一个列表中包含了太多的Bitmap引用,造成了内存溢出。
3.解决方法:
为了解决滑动中更新列表时不流畅的问题,很自然的就想到应该在列表滑动停止时再加载图片,Android SDK 的 ApiDemos - Views - Lists - Slow Adapter 提供了延迟更新的方法,于是添加了onScrollListener,当scroller的状态变为IDLE时,才把标志位设置为true,允许加载图片。
因为有50+的图片,如果在每次返回之后都要调用
notifyDataSetChanged()方法,其实就做了很多的无用功,为了刷新一张图片而让整个列表都重新填充了一遍内容,这个做法是非常不合适的。为了解决这个问题,初步想了两种思路:一、建立一个HashMap,把图片的url和ImageView对象放在map里,通过异步返回图片的url信息更新对应的ImageView;二、在adapter的getView()方法里封装ListItem所要呈现的convertView对象,在每个子View里进行图片的异步下载操作,下载后调用子View的刷新方法。在实际中采用了后一种方法,两者的优劣还没用能够具体的分析比较。
至于OOM问题,在之前的很多工程里都遇到过,但都没有彻底的解决。之前的通常做法是设置一个计数器,当列表滑动到某一位置后,对N张之前和N张之后的Bitmap对象执行recycle()操作。这个做法是可行的,缺陷是在一些极端情况——如滑动过快或是涉及到多线程的操作——可能会引发RuntimeException: Canvas: trying to use a recycled bitmap。
Android本身对ListView是做过优化的,查看源码我们可以发现AbsListView类当中有一个内部类——RecycleBin,和一个接口RecyclerListener。ListView中所包含的所有子View被分为“mActiveViews”“mScrapViews”两个部分,前者是当前活动的,也就是屏幕上显示的Views,后者是不可见的Views。如果实现了
RecyclerListener接口,
当一个View由于ListView的滑动被系统回收到
RecycleBin的
mScrapViews数组时,会调用
RecyclerListener中的onMovedToScrapHeap(View view)方法。
RecycleBin相当于一个临时存储不需要显示的那部分Views的对象,随着列表滑动,这些Views需要显示出来的时候,他们就被从RecycleBin中拿了出来,
RecycleBin
本身并不对
mScrapViews中的对象做回收操作。
于是在工程里,为ListView添加
RecyclerListener接口 ,并在
onMovedToScrapHeap方法中释放ListItem包含的Bitmap资源,这样可以极大的减少内存占用。