Android ListView控件的资源回收机制

转自：http://blog.sina.com.cn/s/blog_70a3eebd0101e30h.html

问题：列表滑动不流畅，容易出现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资源，这样可以极大的减少内存占用。