[课程] 【转】Android 通过软引用实现图片缓存，防止内存溢出 [复制链接]

public class BitmapCache {
? ? static private BitmapCache cache;
? ? /** 用于Chche内容的存储 */
? ? private Hashtable<Integer, MySoftRef> hashRefs;
? ? /** 垃圾Reference的队列（所引用的对象已经被回收，则将该引用存入队列中） */
? ? private ReferenceQueue<Bitmap> q;

? ? /**
? ???* 继承SoftReference，使得每一个实例都具有可识别的标识。
? ?? ? */
? ? private class MySoftRef extends SoftReference<Bitmap> {
? ?? ??? private Integer _key = 0;

? ?? ??? public MySoftRef(Bitmap bmp, ReferenceQueue<Bitmap> q, int key) {
? ?? ?? ?? ? super (bmp, q);
? ?? ?? ?? ?_key = key;
? ?? ???}
? ? }

? ? private BitmapCache() {
? ?? ???hashRefs = new Hashtable<Integer, MySoftRef>();
? ?? ???q = new ReferenceQueue<Bitmap>();
? ? }

? ? /**
? ???* 取得缓存器实例
? ?? ? */
? ? public static BitmapCache getInstance() {
? ?? ??? if (cache == null ) {
? ?? ?? ?? ?cache = new BitmapCache();
? ?? ???}
? ?? ??? return cache;
? ? }

? ? /**
? ???* 以软引用的方式对一个Bitmap对象的实例进行引用并保存该引用
? ?? ? */
? ? private void addCacheBitmap(Bitmap bmp, Integer key) {
? ?? ???cleanCache(); // 清除垃圾引用
? ?? ?? ?MySoftRef ref = new MySoftRef(bmp, q, key);
? ?? ???hashRefs.put(key, ref);
? ? }

? ? /**
? ???* 依据所指定的drawable下的图片资源ID号（可以根据自己的需要从网络或本地path下获取），重新获取相应Bitmap对象的实例
? ??? */
? ? public Bitmap getBitmap( int resId, Context context) {
? ?? ???Bitmap bmp = null ;
? ?? ??? // 缓存中是否有该Bitmap实例的软引用，如果有，从软引用中取得。
? ?? ?? ? if (hashRefs.containsKey(resId)) {
? ?? ?? ?? ?MySoftRef ref = (MySoftRef) hashRefs.get(resId);
? ?? ?? ?? ?bmp = (Bitmap) ref.get();
? ?? ???}
? ?? ??? // 如果没有软引用，或者从软引用中得到的实例是null，重新构建一个实例，
? ?? ?? ? // 并保存对这个新建实例的软引用
? ?? ?? ? if (bmp == null ) {
? ?? ?? ?? ? // 传说decodeStream直接调用JNI>>nativeDecodeAsset()来完成decode，
? ?? ?? ?? ??? // 无需再使用java层的createBitmap，从而节省了java层的空间。
? ?? ?? ?? ???bmp = BitmapFactory.decodeStream(context.getResources()
? ?? ?? ?? ?? ?? ???.openRawResource(resId));
? ?? ?? ?? ? this .addCacheBitmap(bmp, resId);
? ?? ???}
? ?? ??? return bmp;
? ? }

? ? private void cleanCache() {
? ?? ???MySoftRef ref = null ;
? ?? ??? while ((ref = (MySoftRef) q.poll()) != null ) {
? ?? ?? ?? ?hashRefs.remove(ref._key);
? ?? ???}
? ? }

? ? /**
? ???* 清除Cache内的全部内容
? ??? */
? ? public void clearCache() {
? ?? ???cleanCache();
? ?? ???hashRefs.clear();
? ?? ???System.gc();
? ?? ???System.runFinalization();
? ? }
}


*****************************************************
*****************************************************
一般Java虚拟机要求支持verbosegc选项，输出详细的垃圾收集调试信息。dalvik虚拟机很安静的接受verbosegc选项，然后什么都不做。dalvik虚拟机使用自己的一套LOG机制来输出调试信息。

如果在Linux下运行adb logcat命令，可以看到如下的输出：
D/dalvikvm(??745): GC_CONCURRENT
freed 199K, 53% free 3023K/6343K,external 0K/0K, paused 2ms+2ms

其中D/dalvikvm表示由dalvikvm输出的调试信息，括号后的数字代表dalvikvm所在进程的pid。

GC_CONCURRENT表示触发垃圾收集的原因，有以下几种：





GC_MALLOC, 内存分配失败时触发

GC_CONCURRENT，当分配的对象大小超过384K时触发

GC_EXPLICIT，对垃圾收集的显式调用(System.gc)

GC_EXTERNAL_ALLOC，外部内存分配失败时触发

freed 199K表示本次垃圾收集释放了199K的内存，

53% free 3023K/6343K，其中6343K表示当前内存总量，3023K表示可用内存，53%表示可用内存占总内存的比例。

external 0K/0K，表示可用外部内存/外部内存总量
paused
2ms+2ms，第一个时间值表示markrootset的时间，第二个时间值表示第二次mark的时间。如果触发原因不是GC_CONCURRENT，这一行为单个时间值，表示垃圾收集的耗时时间。