Bitmap缓存机制

Bitmap缓存机制

加载一个bitmap到UI里面比较简单直接，但是，如果我们一次加载大量的bitmap数据的时候就变得复杂了。许多情况下（比如这些组件：ListVIew，GridView或者ViewPager），显示的图片和将要滚动显示的图片一般是没有限制的。

内存的使用量可以被降下来，通过回收那些移出屏幕之外的组件。Android的垃圾回收机制同样会释放你的资源，如果它们没有被引用。这种机制是好的，但是为了获得流畅快速的UI体验，我们想避免重复下载图片。一种本地内存缓存的方法提供了很大的帮助，可以快速的重新加载本地缓存的资源。

本章将带你使用内存缓存的机制来提高UI的响应速度和流畅的体验，当加载多张图片的时候。

原文：http://wear.techbrood.com/training/displaying-bitmaps/cache-bitmap.html#config-changes

使用内存缓存

内存缓存使用有限的应用内存去缓存bitmap。LruCache这个类（also available in the Support
Li brary for use back to API Level 4），非常适合缓存bitmaps，他使用LinkedHashMap，它会在超过缓存大小的时候回收最近最少使用的指向。

Note：过去，我们常使用 SoftReference or WeakReference 来缓存，但是现在不推荐了。从Android2.3（API
Level 9），垃圾回收器抵制使用它们。Android3.0（11）之后，bitmap被存储在有效的缓存里面，在可预测的情况下并不能被释放，这样导致超过内存限制并且导致崩溃。

为了为LrcCache选择合适的内存空间，下面几个因素要被大家重视的：

  • 你应用的空余内存是多大？
  • 一次将要加载多少张图片显示？现在已经显示了多少张图片？
  • 屏幕的尺寸大小和密度是多少？高密度的是被比如Galaxy Nexus要比低密度的设备需要更大的缓存。
  • bitmap的尺寸和配置是什么，没一张图片所占资源的大小是多少？
  • 你需要什么样的用户体验？还是有一部分需要流畅的体验？如果是这样的话，你可以把他们长久的放到内存里面或者使用LrcCache缓存。
  • 你需要在质量（内存大小）和“质量”（图片的质量）上做出选择？有时候，我们可以选择存储缩略图，后台加载更高质量的图片。

没有一个特定大小的内存可以使用所有的应用，他取决于你去分析内存的使用情况寻找一个合适的解决方法。缓存太小的话没有什么意义，缓存太大容易引起java.lang.OutOfMemory exceptions并且只留给你的应用很少的一部分内存。

这里有个使用LruCache的例子：

private LruCache<String, Bitmap> mMemoryCache;

@Override
protected void onCreate(Bundle savedInstanceState) {
    ...
    // Get max available VM memory, exceeding this amount will throw an
    // OutOfMemory exception. Stored in kilobytes as LruCache takes an
    // int in its constructor.
    final int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);

    // Use 1/8th of the available memory for this memory cache.
    final int cacheSize = maxMemory / 8;

    mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {
        @Override
        protected int sizeOf(String key, Bitmap bitmap) {
            // The cache size will be measured in kilobytes rather than
            // number of items.
            return bitmap.getByteCount() / 1024;
        }
    };
    ...
}

public void addBitmapToMemoryCache(String key, Bitmap bitmap) {
    if (getBitmapFromMemCache(key) == null) {
        mMemoryCache.put(key, bitmap);
    }
}

public Bitmap getBitmapFromMemCache(String key) {
    return mMemoryCache.get(key);
}

Note: In this example, one eighth of the application memory is allocated for our cache. On a normal/hdpi device this is a minimum of around 4MB (32/8). A fullscreen GridView filled
with images on a device with 800x480 resolution would use around 1.5MB (800*480*4 bytes), so this would cache a minimum of around 2.5pages of images in memory.

当我们加载一张图片到ImageView，首先检查Lrucache。如果一旦找到接口，我们可以很快速的更新这个ImageView,否则，我们启动一个线程去执行加载这张图片。

public void loadBitmap(int resId, ImageView imageView) {
    final String imageKey = String.valueOf(resId);

    final Bitmap bitmap = getBitmapFromMemCache(imageKey);
    if (bitmap != null) {
        mImageView.setImageBitmap(bitmap);
    } else {
        mImageView.setImageResource(R.drawable.image_placeholder);
        BitmapWorkerTask task = new BitmapWorkerTask(mImageView);
        task.execute(resId);
    }
}

BitmapWorkerTask需要更新资源和资源的缓存接口：

class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> {
    ...
    // Decode image in background.
    @Override
    protected Bitmap doInBackground(Integer... params) {
        final Bitmap bitmap = decodeSampledBitmapFromResource(
                getResources(), params[0], 100, 100));
        addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);
        return bitmap;
    }
    ...
}

使用本地缓存

内存缓存是一种很好的提高速度的方法，但是你不能完全依靠它。像GridView组件很快的占用掉大量内存。你的应用可能会被其他任务打断，比如来电，并且后台进程可能会被终止，内存缓存也可能会被释放，当你的应用再次启动时候，你不得不重新加载。

本地缓存可以解决这个问题，帮助你存储那些缓存不需要的资源来减少重复加载的次数，当然，本地缓存的使用要比内存缓存的速度要慢，需要在后台操作，担任果然读取的事件是不可预知的

Note: A ContentProvider might
be a more appropriate place to store cached images if they are accessed more frequently, for example in an image gallery application.

下面的代码DiskLrcCache，是从本地加载的一个例子：

private DiskLruCache mDiskLruCache;
private final Object mDiskCacheLock = new Object();
private boolean mDiskCacheStarting = true;
private static final int DISK_CACHE_SIZE = 1024 * 1024 * 10; // 10MB
private static final String DISK_CACHE_SUBDIR = "thumbnails";

@Override
protected void onCreate(Bundle savedInstanceState) {
    ...
    // Initialize memory cache
    ...
    // Initialize disk cache on background thread
    File cacheDir = getDiskCacheDir(this, DISK_CACHE_SUBDIR);
    new InitDiskCacheTask().execute(cacheDir);
    ...
}

class InitDiskCacheTask extends AsyncTask<File, Void, Void> {
    @Override
    protected Void doInBackground(File... params) {
        synchronized (mDiskCacheLock) {
            File cacheDir = params[0];

mDiskLruCache = DiskLruCache.open(cacheDir, DISK_CACHE_SIZE);
            mDiskCacheStarting = false; // Finished initialization
            mDiskCacheLock.notifyAll(); // Wake any waiting threads
        }
        return null;
    }
}

class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> {
    ...
    // Decode image in background.
    @Override
    protected Bitmap doInBackground(Integer... params) {
        final String imageKey = String.valueOf(params[0]);

        // Check disk cache in background thread
        Bitmap bitmap = getBitmapFromDiskCache(imageKey);

        if (bitmap == null) { // Not found in disk cache
            // Process as normal
            final Bitmap bitmap = decodeSampledBitmapFromResource(
                    getResources(), params[0], 100, 100));
        }

        // Add final bitmap to caches
        addBitmapToCache(imageKey, bitmap);

        return bitmap;
    }
    ...
}

public void addBitmapToCache(String key, Bitmap bitmap) {
    // Add to memory cache as before
    if (getBitmapFromMemCache(key) == null) {
        mMemoryCache.put(key, bitmap);
    }

    // Also add to disk cache
    synchronized (mDiskCacheLock) {
        if (mDiskLruCache != null && mDiskLruCache.get(key) == null) {
            mDiskLruCache.put(key, bitmap);
        }
    }
}

public Bitmap getBitmapFromDiskCache(String key) {
    synchronized (mDiskCacheLock) {
        // Wait while disk cache is started from background thread
        while (mDiskCacheStarting) {
            try {
                mDiskCacheLock.wait();
            } catch (InterruptedException e) {}
        }
        if (mDiskLruCache != null) {
            return mDiskLruCache.get(key);
        }
    }
    return null;
}

// Creates a unique subdirectory of the designated app cache directory. Tries to use external
// but if not mounted, falls back on internal storage.
public static File getDiskCacheDir(Context context, String uniqueName) {<pre name="code" class="java">private LruCache<String, Bitmap> mMemoryCache;

@Override
protected void onCreate(Bundle savedInstanceState) {
    ...
    RetainFragment retainFragment =
            RetainFragment.findOrCreateRetainFragment(getFragmentManager());
    mMemoryCache = retainFragment.mRetainedCache;
    if (mMemoryCache == null) {
        mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {
            ... // Initialize cache here as usual
        }
        retainFragment.mRetainedCache = mMemoryCache;
    }
    ...
}

class RetainFragment extends Fragment {
    private static final String TAG = "RetainFragment";
    public LruCache<String, Bitmap> mRetainedCache;

    public RetainFragment() {}

    public static RetainFragment findOrCreateRetainFragment(FragmentManager fm) {
        RetainFragment fragment = (RetainFragment) fm.findFragmentByTag(TAG);
        if (fragment == null) {
            fragment = new RetainFragment();
            fm.beginTransaction().add(fragment, TAG).commit();
        }
        return fragment;
    }

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setRetainInstance(true);
    }
}


Note: Even initializing the disk cache requires disk operations and therefore should not take place on the main thread. However, this does mean there‘s a chance the cache is accessed before initialization. To address this, in the above implementation, a lock

 object ensures that the app does not read from the disk cache until the cache has been initialized.


内存缓存在UI线程里面检测，本地缓存需要在后台使用，本地缓存不能取代内存缓存在UI线程里面的地位，最终，为了以后的使用bitmap同事被放到内存和本地


处理配置的变化


运行时的配置变化，比如屏幕方向的变化会引起Android摧毁和重启Activity(For more information about this behavior, see Handling

 Runtime Changes)，你想避免再次process你的图片，为了更快的体验。


幸运的是，你有一个很好的内存缓存机制，你可以使用Fragment来忽略这些通过使用setRetainInstance(true)，当Activity被重新创建的时候，该保留的Fragment同样会被重新附着到你的应用上面。


下面是一个应对配置改变时的例子：


class RetainFragment extends Fragment {
    private static final String TAG = "RetainFragment";
    public LruCache<String, Bitmap> mRetainedCache;

    public RetainFragment() {}

    public static RetainFragment findOrCreateRetainFragment(FragmentManager fm) {
        RetainFragment fragment = (RetainFragment) fm.findFragmentByTag(TAG);
        if (fragment == null) {
            fragment = new RetainFragment();
            fm.beginTransaction().add(fragment, TAG).commit();
        }
        return fragment;
    }

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setRetainInstance(true);
    }
}


为了测试它，我们可以旋转屏幕在保留和不保留Fragment的情况下。你应该会注意到，当你保留Fragment的时候，你会注意到图片会毫无滞留的从内存缓存加载，内存中没有找到的会被缓存到本地，如果不这样的话，和常规一样。


缓存的图片的优化请看上一篇：多线程处理Bitmaps
				


				
时间： 2024-10-28 05:24:16 

		


		


	

	
	

		


		
Bitmap缓存机制的相关文章


								

		

			

                Android客户端中Bitmap的下载过程和缓存机制
			

		

		

									

				加载流程: if(内存命中){ 从内存中读取 }else{ create AsyncTasks,task中的多个Runnable是通过堆栈先进后出的方式来调度,而非队列式的先进先出,目的是最先加载用户最近划到或打开的图片. } AsyncTask: //do in background——该后台进程在用户scroll列表的时候会暂停,从而减小了列表划动时cpu的overhead,此方法也被ImageLoader和facebook的官方app所使用. if(磁盘缓存命中){ 从缓存中读取 }els			

		

	

				

		

			

                Android开源框架ImageLoader：加载图片的三级缓存机制
			

		

		

									

				前言:可从  https://github.com/nostra13/Android-Universal-Image-Loader 下载三级缓存机制的开源框架.下文简单介绍该框架中主要的常用方法,掌握这些方法,基本就可应对多数图片下载的需求. 注意:以下代码为示意代码片断,仔细读一下应能知道怎么用.蓝色表示为开源框架中的类. 1.初始化ImageLoader类对象: ImageLoader imageLoader = ImageLoader.getInstance(); imageLoader.			

		

	

				

		

			

                从源码带看Volley的缓存机制
			

		

		

									

				转载请注明出处:http://blog.csdn.net/asdzheng/article/details/45955653 磁盘缓存DiskBasedCache 如果你还不知道volley有磁盘缓存的话,请看一下我的另一篇博客请注意,Volley已默认使用磁盘缓存 DiskBasedCache内部结构 它由两部分组成,一部分是头部,一部分是内容:先得从它的内部静态类CacheHeader(缓存的头部信息)讲起,先看它的内部结构: responseHeaders; } //可以看到,头部类里包含			

		

	

				

		

			

                Android缓存机制&amp;一个缓存框架推荐
			

		

		

									

				1.先推荐一个轻量级缓存框架--ACache(ASimpleCache) ACache介绍: ACache类似于SharedPreferences,但是比SharedPreferences功能更加强大,SharedPreferences只能保存一些基本数据类型.Serializable.Bundle等数据, 而Acache可以缓存如下数据: 普通的字符串.JsonObject.JsonArray.Bitmap.Drawable.序列化的java对象,和 byte数据. 主要特色: 1:轻,轻到只			

		

	

				

		

			

                自己定制ListView，上拉刷新和下拉刷新，加载网络图片，并且添加缓存机制。
			

		

		

									

				1 package com.lixu.listviewrefresh; 2 3 import java.util.ArrayList; 4 import java.util.HashMap; 5 import java.util.Random; 6 7 import com.lixu.listviewrefresh.Loadnetimage.OnLoadnetimageListener; 8 import com.lixu.listviewrefresh.MyRefreshListview.On			

		

	

				

		

			

                Android之ListView异步加载网络图片(优化缓存机制)【转】
			

		

		

									

				网上关于这个方面的文章也不少,基本的思路是线程+缓存来解决.下面提出一些优化: 1.采用线程池 2.内存缓存+文件缓存 3.内存缓存中网上很多是采用SoftReference来防止堆溢出,这儿严格限制只能使用最大JVM内存的1/4 4.对下载的图片进行按比例缩放,以减少内存的消耗 具体的代码里面说明.先放上内存缓存类的代码MemoryCache.java: public class MemoryCache { private static final String TAG = "MemoryCa			

		

	

				

		

			

                Android三级缓存机制工具类的实现
			

		

		

									

				一．三级缓存概述 (一)三级缓存的三级 第一级是内存,最快,不需要网络 第二级是本地,不需要网络 第三级是网络,需要网络请求 三级缓存机制的思想: 如果在内存中获取到数据,就不去本地和网络中获取. 如果在本地中获取到数据就不去网络中获取, 如果内存和本地中不存在数据,就要去网络中请求数据 三级缓存技术能有效节省用户的流量,但是也会增加一些内存负担. 二．使用示例展示三级缓存工具栏类的使用 程序运行后的页面: 虽然只用一个按钮和一个图片显示,但是通过测试(联网状态和断网状态对比)能知道图片是从网络			

		

	

				

		

			

                [Android] 缓存机制
			

		

		

									

				移动开发本质上就是手机和服务器之间进行通信,需要从服务端获取数据.反复通过网络获取数据是比较耗时的,特别是访问比较多的时候,会极大影响了性能,Android中可通过缓存机制来减少频繁的网络操作,减少流量.提升性能. 实现原理 把不需要实时更新的数据缓存下来,通过时间或者其他因素 来判别是读缓存还是网络请求,这样可以缓解服务器压力,一定程度上提高应用响应速度,并且支持离线阅读. Bitmap的缓存 在许多的情况下(像 ListView, GridView 或 ViewPager 之类的组件 )我们			

		

	

				

		

			

                【转】彻底解析Android缓存机制——LruCache
			

		

		

									

				彻底解析Android缓存机制——LruCache 关于Android的三级缓存,其中主要的就是内存缓存和硬盘缓存.这两种缓存机制的实现都应用到了LruCache算法,今天我们就从使用到源码解析,来彻底理解Android中的缓存机制. 一.Android中的缓存策略 一般来说,缓存策略主要包含缓存的添加.获取和删除这三类操作.如何添加和获取缓存这个比较好理解,那么为什么还要删除缓存呢?这是因为不管是内存缓存还是硬盘缓存,它们的缓存大小都是有限的.当缓存满了之后,再想其添加缓存,这个时候就需要删除