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缓存。
你须要在质量（内存大小）和“质量”（图片的质量）上做出选择？有时候，我们能够选择存储缩略图，后台载入更高质量的图片。

没有一个特定大小的内存能够使用全部的应用。他取决于你去分析内存的使用情况寻找一个合适的解决方法。缓存太小的话没有什么意义，缓存太大easy引起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的时候。你会注意到图片会毫无滞留的从内存缓存载入。内存中没有找到的会被缓存到本地。假设不这种话，和常规一样。

巴特西

Bitmap缓存机制

Bitmap缓存机制

使用内存缓存

使用本地缓存

处理配置的变化

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

最新文章

热门文章