android 缓存Bitmap - 开发文档翻译

由于本人英文能力实在有限，不足之初敬请谅解

本博客只要没有注明“转”，那么均为原创，转贴请注明本博客链接链接

Loading a single bitmap into your user interface (UI) is straightforward, however things get more complicated if you need to load a larger set of images at once.
In many cases (such as with components like ListView, GridView or ViewPager),
the total number of images on-screen combined with images that might soon scroll onto the screen are essentially unlimited.
加载单一的bitmap到你的UI是很简单的，然而如果你需要在同一时间加载大量图片，事情将变得复杂
很多情况中（比如使用像ListView, GridView 或者 ViewPager一类的组件时），快速滚动到屏幕上的图片合并成的屏幕图片，这些图片总量基本是不可计数的

Memory usage is kept down with components like this by recycling the child views as they move off-screen.
The garbage collector also frees up your loaded bitmaps, assuming you don't keep any long lived references.
This is all good and well, but in order to keep a fluid and fast-loading UI you want to avoid continually processing these images each time they come back on-screen.
A memory and disk cache can often help here, allowing components to quickly reload processed images.
内存的使用是由组件控制的，比如当子view移出屏幕的时候回收他们
假设你没有保持任何持久的引用，垃圾回收器也会释放你加载的图片
这样做很好，但是UI为了保持流动和快速加载，当这些图片返回到屏幕上的时候，你想避免每一次持续处理这些图片
一个内存缓存和磁盘缓存可以帮助你，允许组件快速的重新加载处理过的图片。

This lesson walks you through using a memory and disk bitmap cache to improve the responsiveness and fluidity of your UI when loading multiple bitmaps.
这一节带你浏览使用内存和磁盘bimtap缓存来改进当加载大量bitmap时你的UI响应性和流畅度

Use a Memory Cache
使用内存缓存

A memory cache offers fast access to bitmaps at the cost of taking up valuable application memory.
The LruCache class (also available in the Support Library for use back to API Level 4) is particularly well suited to the task of caching bitmaps, keeping recently referenced objects in a strong referenced LinkedHashMap and evicting the least recently used member before the cache exceeds its designated size.
内存缓存提供快速访问bitmap是以应用宝贵的内存为代价的
LruCache类特别适合缓存bitmap的任务，保持最近引用的对象在一个强引用的LinkedHashMap中，在缓存扩张到指定大小之前，移除最近最少使用的成员

Note: In the past, a popular memory cache implementation was a SoftReference or WeakReference bitmap cache, however this is not recommended.
Starting from Android 2.3 (API Level 9) the garbage collector is more aggressive with collecting soft/weak references which makes them fairly ineffective.
In addition, prior to Android 3.0 (API Level 11), the backing data of a bitmap was stored in native memory which is not released in a predictable manner, potentially causing an application to briefly exceed its memory limits and crash.
注意：过去，一个流行的内存缓存实现是用一个软引用或者弱引用bitmap缓存，但是并不推荐这么做
从Android 2.3 (API Level 9)开始，垃圾回收器对于收集软引用和弱引用变得更积极，这就使得他们相对无效。
另外，在Android 3.0 (API Level 11)之前，bitmap是储存在native内存中的，他的释放并不是一种可遇见的方式，这便存在潜在的引起应用超过它自身内存限制并且导致其崩溃的风险

In order to choose a suitable size for a LruCache, a number of factors should be taken into consideration, for example:
为了给LruCache选择一个合适的大小，下面一些因素应该考虑进去：

How memory intensive is the rest of your activity and/or application?
你其余的activity内存使用情况和应用其余部分的内存使用情况
How many images will be on-screen at once? How many need to be available ready to come on-screen?
一次同时多少图片会显示到屏幕上
多少图片要准备好以便显示随时显示到屏幕上
What is the screen size and density of the device?
An extra high density screen (xhdpi) device like Galaxy Nexus will need a larger cache to hold the same number of images in memory compared to a device like Nexus S (hdpi).
设备的屏幕尺寸和密度是多少
一个像Galaxy Nexus特别高屏幕密度的设备，与Nexus S (hdpi)这样的设备相比，会需要一个大缓存在内存中来持有相同数量的图片
What dimensions and configuration are the bitmaps and therefore how much memory will each take up?
bitmap的尺寸和结构是什么、每一张图片占用的内存是多少
How frequently will the images be accessed?
Will some be accessed more frequently than others?
If so, perhaps you may want to keep certain items always in memory or even have multiple LruCache objects for different groups of bitmaps.
图片被访问的频率是多少
是否一些图片访问频率要比其他的大一些
如果是这样，也许你应该一直保持一些在内存中，甚至可以使用多个LruCache对象来管理多组bitmap
Can you balance quality against quantity?
Sometimes it can be more useful to store a larger number of lower quality bitmaps, potentially loading a higher quality version in another background task.
你能在质量与数量直接保持平衡吗
有些时候，存储大量低质量bitmap是很有效的，而在另一个后台进程加载一个高质量版本

There is no specific size or formula that suits all applications, it's up to you to analyze your usage and come up with a suitable solution.
A cache that is too small causes additional overhead with no benefit, a cache that is too large can once again cause java.lang.OutOfMemory exceptions and leave the rest of your app little memory to work with.
没有特定的大小或公式适合所有的应用，这取决于你对你的用法的分析，然后提出一种适合的解决方案
一个过小的缓存不但没有任何好处而且还会引起额外的开销，一个过大的缓存可再次引发java.lang.OutOfMemory异常或者给你应用剩余部分只留下很小的内存

Here’s an example of setting up a LruCache for bitmaps:
下面是一个为bitmap设置LruCache的例子：

private LruCache<String, Bitmap> mMemoryCache;@Overrideprotected 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 full screen 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.5 pages of images in memory.
注意：在这个例子中，1/8的应用内存分配给了我们的缓存
一个普通的/hdpi 的设备，这个值最少是4mb（32/8）
在一个分辨率为800x480的设备上，一个全屏的、被图片填满的GridView使用大概1.5MB的内存（800*480*4 bytes），所以4mb至少缓存的2.5页的图片在内存中

When loading a bitmap into an ImageView, the LruCache is checked first.
If an entry is found, it is used immediately to update the ImageView, otherwise a background thread is spawned to process the image:
当加载一个bitmap到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);    }}

The BitmapWorkerTask also needs to be updated to add entries to the memory cache:
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;    }    ...}

Use a Disk Cache
使用磁盘缓存

A memory cache is useful in speeding up access to recently viewed bitmaps, however you cannot rely on images being available in this cache.
Components like GridView with larger datasets can easily fill up a memory cache.
Your application could be interrupted by another task like a phone call, and while in the background it might be killed and the memory cache destroyed.
Once the user resumes, your application has to process each image again.
内存缓存在加速访问最近浏览的bitmap是很有效的，然而你不能指望图片在这个缓存中是有效的
像GridView一类的带有大数据的组件，可以轻易的填满内存缓存
一旦用户用户继续浏览，你的应用就不得不再次处理每一张图片

A disk cache can be used in these cases to persist processed bitmaps and help decrease loading times where images are no longer available in a memory cache.
Of course, fetching images from disk is slower than loading from memory and should be done in a background thread, as disk read times can be unpredictable.
磁盘缓存可以用于这些情况，保持处理过的bitmap，在图片在内存缓存中失效的地方减少加载所需时间
当然，从磁盘上获取这些图片要比从内存中加载慢，并且由于磁盘读取时间是不可预知的，所以也应该在后台进程中完成

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.
注意：如果图片被访问的非常频繁的话，ContentProvider也许更适合存储缓存图片，例如在一个图片画廊应用中

The sample code of this class uses a DiskLruCache implementation that is pulled from the Android source.
Here’s updated example code that adds a disk cache in addition to the existing memory cache:
这个类的示例代码使用了android源码中的DiskLruCache的实现
下面更新一下示例代码，除了已存在的内存缓存，还要添加一个磁盘缓存

private DiskLruCache mDiskLruCache;private final Object mDiskCacheLock = new Object();private boolean mDiskCacheStarting = true;private static final int DISK_CACHE_SIZE = 1024 * 1024 * 10; // 10MBprivate static final String DISK_CACHE_SUBDIR = "thumbnails";@Overrideprotected 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) {    // 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.MEDIA_MOUNTED.equals(Environment.getExternalStorageState()) ||                    !isExternalStorageRemovable() ? getExternalCacheDir(context).getPath() :                            context.getCacheDir().getPath();    return new File(cachePath + File.separator + uniqueName);}

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.
注意：初始化磁盘缓存需要磁盘操作，所以不应该把这个工作放到主线程中
然而，这确实是意味着，在缓存初始化之前，缓存就有被访问的可能
为了解决这个问题，在上面的实现中，一个锁对象保证了应用在磁盘缓存初始化完毕之前不会访问磁盘缓存

While the memory cache is checked in the UI thread, the disk cache is checked in the background thread.
Disk operations should never take place on the UI thread.
When image processing is complete, the final bitmap is added to both the memory and disk cache for future use.
然而内存缓存是在UI线程中检查，磁盘缓存是在后台线程中检查
磁盘操作永远不该在UI线程中发生
当图片处理完成时，最终的bitmap为了之后的使用而被添加到内存缓存和磁盘缓存中

Handle Configuration Changes
处理配置改变
Runtime configuration changes, such as a screen orientation change, cause Android to destroy and restart the running activity with the new configuration (For more information about this behavior, see Handling Runtime Changes).
You want to avoid having to process all your images again so the user has a smooth and fast experience when a configuration change occurs.
运行时配置改变，比如屏幕方向改变，导致Android销毁并使用新的配置项重启运行中的activity（这种行为的更多信息参见Handling Runtime Changes）
当配置改变发生时，你想避免重新处理一遍你所有的图片，这样用户才会有流畅和快速的体验

Luckily, you have a nice memory cache of bitmaps that you built in the Use a Memory Cache section.
This cache can be passed through to the new activity instance using a Fragment which is preserved by calling setRetainInstance(true)).
After the activity has been recreated, this retained Fragment is reattached and you gain access to the existing cache object, allowing images to be quickly fetched and re-populated into the ImageView objects.
幸运的是，在Use a Memory Cache章节中，你有一个不错的存储bitmap的内存缓存
使用Fragment通过调用setRetainInstance(true)，这个缓存可以传递到新的activity实例中
在activity重新建立了之后，这个保留下来的Fragment会重新附着在activity上，你可以访问现有的缓存对象，允许图片被快速的获取并重新填充到ImageView对象中

Here’s an example of retaining a LruCache object across configuration changes using a Fragment:
下面是在配置改变时，使用Fragment保持一个LruCache对象

private LruCache<String, Bitmap> mMemoryCache;@Overrideprotected 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();        }        return fragment;    }    @Override    public void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setRetainInstance(true);    }}

To test this out, try rotating a device both with and without retaining the Fragment.
You should notice little to no lag as the images populate the activity almost instantly from memory when you retain the cache.
Any images not found in the memory cache are hopefully available in the disk cache, if not, they are processed as usual.
为了进行彻底检验，分别尝试旋转带有此Fragment和不带此Fragment的设备
你会发现机会没有延时，因为当你保持缓存的时候，图片立即从内存填充到activity
任何在内存缓存中找不到的图片希望能在磁盘缓存中找到，不然就要像平时一样处理他们

原文地址如下，英文水平实在有限，希望拍砖同时能给予指正。

http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html

 

 

转贴请保留以下链接

本人blog地址

http://su1216.iteye.com/

http://blog.csdn.net/su1216/