LruCache & DiskLruCache

在用户界面（UI）加载一张图片时很简单，然而，如果你需要加载多张较大的图像，事情就会变得更加复杂，。在许多情况下（如与像的ListView GridView或ViewPager的组件），屏幕上的图片的总数伴随屏幕上滚动的骤然增加，且基本上是无限的。为使内存使用保持在稳定范围内，这些组件会在子view在屏幕中消失后，对其进行资源回收，垃圾回收机制会释放掉已加载的图片内存空间，所以建议你不要保持图片的常引用，这样做很好，为了保证页面的流畅性和响应速度，你可能不愿意在页面返回时频繁处理加载过图片。通过内存、磁盘的缓存就可以帮助你快速加载已加载的图片。

今天与大家分享一下图片的缓存技术，利用它可以提高UI的流畅性、响应速度，给用户好的体验。

如何在内存中做缓存？

通过内存缓存可以快速加载缓存图片，但会消耗应用的内存空间。LruCache类（通过兼容包可以支持到sdk4）很适合做图片缓存，它通过LinkedHashMap保持图片的强引用方式存储图片，当缓存空间超过设置定的限值时会释放掉早期的缓存。

注：在过去，常用的内存缓存实现是通过SoftReference或WeakReference，但不建议这样做。从Android2.3（API等级9）垃圾收集器开始更积极收集软/弱引用，这使得它们相当无效。此外，在Android 3.0（API等级11）之前，存储在native内存中的可见的bitmap不会被释放，可能会导致应用程序暂时地超过其内存限制并崩溃。

为了给LruCache设置合适的大小，需要考虑以下几点因素：

• 你的应用中空闲内存是多大？

• 你要在屏幕中一次显示多少图片？ 你准备多少张图片用于显示？

• 设备的屏幕大小与density 是多少？超高屏幕density的设备(xhdpi)像Galaxy Nexus 比 Nexus S (hdpi)这样的设备在缓存相同的图片时需要更大的Cache空间。

• 图片的大小和属性及其需要占用多少内存空间？

• 图片的访问频率是多少？ 是否比其他的图片使用的频率高？如果这样你可能需要考虑将图片长期存放在内存中或者针对不同类型的图片使用不同的缓存策略。

• 如何平衡质量与数量，有事你可能会存储一些常用的低质量的图片用户显示，然后通过异步线程加载高质量的图片。

图片缓存方案没有固定的模式使用所有的的应用，你需要根据应用的具体应用场景进行分析，选择合适的方案来做，缓存太小不能发挥缓存的优势，太大可能占用过多的内存，降低应用性能，或者发生内存溢出异常，

下面是一个使用LruCache的例子：

private LruCache mMemoryCache; 

@Override
protected void onCreate(Bundle savedInstanceState) {
    ...
    // Get memory class of this device, exceeding this amount will throw an
    // OutOfMemory exception.
    final int memClass = ((ActivityManager) context.getSystemService(
            Context.ACTIVITY_SERVICE)).getMemoryClass(); 

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

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

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

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

注意：在这个例子中，应用八分子一的内存分配给图片缓存，在普通/hdpi设备中大约为4MB（32/8）。GirdView全屏时在800x480分辨率的设备中需要1.5M图片空间（800*480*4 bytes）,这样就可以在内存中缓存2.5屏的图片。

运用LruCache向ImageView添加图片时首先先检查图片是否存在，如果在直接更行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 {
    ...
    // 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;
    }
    ...
}

如何使用磁盘缓存？

内存缓存对访问最近使用的图片时很高效，但是你不能保证它一直会在缓存中。像GirdView这样大数据量的组件很容易充满内存缓存。你的应用可能会被“来电”打断，在后台时可能会被杀掉，内存缓存就会失效，一旦用户重新回到应用中时，你需要重新处理每个图片。

在这种情况下我们可以运用磁盘缓存存储已处理的图片，当图片不再内存中时，减少重新加载的时间，当然从磁盘加载图片时要比内存中慢，需要在后台线程中做，因为磁盘的读取时间是未知的。

注意：如果你经常访问图片，ContentProvider应该是存储图片的好地方，如：Gallery图片管理应用。

下面是一个简单的DiskLruCache实现。然而推荐的实现DiskLruCache方案请参考Android4.0中（libcore/luni/src/main/java/libcore/io/DiskLruCache.java）源码。本文使用的是之前版本中的简单实现（Quick Search中是另外的实现）.

显示是简单实现DiskLruCache更新后的例子：

private DiskLruCache mDiskCache;
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
    ...
    File cacheDir = getCacheDir(this, DISK_CACHE_SUBDIR);
    mDiskCache = DiskLruCache.openCache(this, cacheDir, DISK_CACHE_SIZE);
    ...
} 

class BitmapWorkerTask extends AsyncTask {
    ...
    // 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(String.valueOf(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
    if (!mDiskCache.containsKey(key)) {
        mDiskCache.put(key, bitmap);
    }
} 

public Bitmap getBitmapFromDiskCache(String key) {
    return mDiskCache.get(key);
} 

// 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 getCacheDir(Context context, String uniqueName) {
    // Check if media is mounted or storage is built-in, if so, try and use external cache dir
    // otherwise use internal cache dir
    final String cachePath = Environment.getExternalStorageState() == Environment.MEDIA_MOUNTED
            || !Environment.isExternalStorageRemovable() ?
                    context.getExternalCacheDir().getPath() : context.getCacheDir().getPath(); 

    return new File(cachePath + File.separator + uniqueName);
}

内存缓存检查在UI线程中做，磁盘缓存的检查在后台线程中。硬盘操作不应在UI线程中。图片处理完成后应将其加入正在使用的内存、磁盘缓存中。