android 缓存Bitmap - 开发文档翻译

分类：android 2013-08-25 13:02 735人阅读评论(0) 收藏举报 android memory cache disk cache LruCache 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的例子：

[java] view plain copy

privateLruCache<String,Bitmap>mMemoryCache;
@Override
protectedvoidonCreate(BundlesavedInstanceState){
...
//GetmaxavailableVMmemory,exceedingthisamountwillthrowan
//OutOfMemoryexception.StoredinkilobytesasLruCachetakesan
//intinitsconstructor.
finalintmaxMemory=(int)(Runtime.getRuntime().maxMemory()/1024);
//Use1/8thoftheavailablememoryforthismemorycache.
finalintcacheSize=maxMemory/8;
mMemoryCache=newLruCache<String,Bitmap>(cacheSize){
@Override
protectedintsizeOf(Stringkey,Bitmapbitmap){
//Thecachesizewillbemeasuredinkilobytesratherthan
//numberofitems.
returnbitmap.getByteCount()/1024;
}
};
...
}
publicvoidaddBitmapToMemoryCache(Stringkey,Bitmapbitmap){
if(getBitmapFromMemCache(key)==null){
mMemoryCache.put(key,bitmap);
}
}
publicBitmapgetBitmapFromMemCache(Stringkey){
returnmMemoryCache.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上面，否则使用一个后台线程来处理这张图片：

[java] view plain copy

publicvoidloadBitmap(intresId,ImageViewimageView){
finalStringimageKey=String.valueOf(resId);
finalBitmapbitmap=getBitmapFromMemCache(imageKey);
if(bitmap!=null){
mImageView.setImageBitmap(bitmap);
}else{
mImageView.setImageResource(R.drawable.image_placeholder);
BitmapWorkerTasktask=newBitmapWorkerTask(mImageView);
task.execute(resId);
}
}

The BitmapWorkerTask also needs to be updated to add entries to the memory cache:
BitmapWorkerTask也需要更新来以便加实体到内存缓存中

[java] view plain copy

classBitmapWorkerTaskextendsAsyncTask<Integer,Void,Bitmap>{
...
//Decodeimageinbackground.
@Override
protectedBitmapdoInBackground(Integer...params){
finalBitmapbitmap=decodeSampledBitmapFromResource(
getResources(),params[0],100,100));
addBitmapToMemoryCache(String.valueOf(params[0]),bitmap);
returnbitmap;
}
...
}

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的实现
下面更新一下示例代码，除了已存在的内存缓存，还要添加一个磁盘缓存

[java] view plain copy

privateDiskLruCachemDiskLruCache;
privatefinalObjectmDiskCacheLock=newObject();
privatebooleanmDiskCacheStarting=true;
privatestaticfinalintDISK_CACHE_SIZE=1024*1024*10;//10MB
privatestaticfinalStringDISK_CACHE_SUBDIR="thumbnails";
@Override
protectedvoidonCreate(BundlesavedInstanceState){
...
//Initializememorycache
...
//Initializediskcacheonbackgroundthread
FilecacheDir=getDiskCacheDir(this,DISK_CACHE_SUBDIR);
newInitDiskCacheTask().execute(cacheDir);
...
}
classInitDiskCacheTaskextendsAsyncTask<File,Void,Void>{
@Override
protectedVoiddoInBackground(File...params){
synchronized(mDiskCacheLock){
FilecacheDir=params[0];
mDiskLruCache=DiskLruCache.open(cacheDir,DISK_CACHE_SIZE);
mDiskCacheStarting=false;//Finishedinitialization
mDiskCacheLock.notifyAll();//Wakeanywaitingthreads
}
returnnull;
}
}
classBitmapWorkerTaskextendsAsyncTask<Integer,Void,Bitmap>{
...
//Decodeimageinbackground.
@Override
protectedBitmapdoInBackground(Integer...params){
finalStringimageKey=String.valueOf(params[0]);
//Checkdiskcacheinbackgroundthread
Bitmapbitmap=getBitmapFromDiskCache(imageKey);
if(bitmap==null){//Notfoundindiskcache
//Processasnormal
finalBitmapbitmap=decodeSampledBitmapFromResource(
getResources(),params[0],100,100));
}
//Addfinalbitmaptocaches
addBitmapToCache(imageKey,bitmap);
returnbitmap;
}
...
}
publicvoidaddBitmapToCache(Stringkey,Bitmapbitmap){
//Addtomemorycacheasbefore
if(getBitmapFromMemCache(key)==null){
mMemoryCache.put(key,bitmap);
}
//Alsoaddtodiskcache
synchronized(mDiskCacheLock){
if(mDiskLruCache!=null&&mDiskLruCache.get(key)==null){
mDiskLruCache.put(key,bitmap);
}
}
}
publicBitmapgetBitmapFromDiskCache(Stringkey){
synchronized(mDiskCacheLock){
//Waitwhilediskcacheisstartedfrombackgroundthread
while(mDiskCacheStarting){
try{
mDiskCacheLock.wait();
}catch(InterruptedExceptione){}
}
if(mDiskLruCache!=null){
returnmDiskLruCache.get(key);
}
}
returnnull;
}
//Createsauniquesubdirectoryofthedesignatedappcachedirectory.Triestouseexternal
//butifnotmounted,fallsbackoninternalstorage.
publicstaticFilegetDiskCacheDir(Contextcontext,StringuniqueName){
//Checkifmediaismountedorstorageisbuilt-in,ifso,tryanduseexternalcachedir
//otherwiseuseinternalcachedir
finalStringcachePath=
Environment.MEDIA_MOUNTED.equals(Environment.getExternalStorageState())||
!isExternalStorageRemovable()?getExternalCacheDir(context).getPath():
context.getCacheDir().getPath();
returnnewFile(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对象

[java] view plain copy

privateLruCache<String,Bitmap>mMemoryCache;
@Override
protectedvoidonCreate(BundlesavedInstanceState){
...
RetainFragmentretainFragment=
RetainFragment.findOrCreateRetainFragment(getFragmentManager());
mMemoryCache=retainFragment.mRetainedCache;
if(mMemoryCache==null){
mMemoryCache=newLruCache<String,Bitmap>(cacheSize){
...//Initializecachehereasusual
}
retainFragment.mRetainedCache=mMemoryCache;
}
...
}
classRetainFragmentextendsFragment{
privatestaticfinalStringTAG="RetainFragment";
publicLruCache<String,Bitmap>mRetainedCache;
publicRetainFragment(){}
publicstaticRetainFragmentfindOrCreateRetainFragment(FragmentManagerfm){
RetainFragmentfragment=(RetainFragment)fm.findFragmentByTag(TAG);
if(fragment==null){
fragment=newRetainFragment();
}
returnfragment;
}
@Override
publicvoidonCreate(BundlesavedInstanceState){
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

android 管理Bitmap内存 - 开发文档翻译

分类：android 2013-08-27 15:40 683人阅读评论(0) 收藏举报 android bitmap recycle BitmapFactory.Option OOM

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

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

Managing Bitmap Memory

管理Bitmap内存

In addition to the steps described in Caching Bitmaps, there are specific things you can do to facilitate garbage collection and bitmap reuse.

The recommended strategy depends on which version(s) of Android you are targeting.

The BitmapFun sample app included with this class shows you how to design your app to work efficiently across different versions of Android.

除了在Caching Bitmaps里描述的，还有一些具体的事情有助于垃圾回收和bitmap的重用

建议的策略取决于你针对的Android版本。

BitmapFun样本应用中包括这个类，它展示给你如何设计你的应用使得跨版本工作更有效率

To set the stage for this lesson, here is how Android's management of bitmap memory has evolved:

为课程打基础，下面是android的bitmap内存管理是如何演化的

On Android Android 2.2 (API level 8) and lower, when garbage collection occurs, your app's threads get stopped.

This causes a lag that can degrade performance.

Android 2.3 adds concurrent garbage collection, which means that the memory is reclaimed soon after a bitmap is no longer referenced.

在Android2.2（API 8）以及更低的版本中，当发生垃圾回收时，你的应用线程会停止。

这会导致延迟，使得性能降低

Android2.3添加了并发垃圾收集，这意为着一个bitmap不再被引用的时候，内存很快就被回收

On Android 2.3.3 (API level 10) and lower, the backing pixel data for a bitmap is stored in native memory.

It is separate from the bitmap itself, which is stored in the Dalvik heap.

The pixel data in native memory is not released in a predictable manner, potentially causing an application to briefly exceed its memory limits and crash.

As of Android 3.0 (API Level 11), the pixel data is stored on the Dalvik heap along with the associated bitmap.

在Android2.3.3（API 10）和更低的版本中，bitmap的像素数据是存储在native内存中的

它独立于bitmap本身，bitmap是存储在Dalvik堆中的

在native内存中的bitmap的像素数据不会在一个可预测的行为之释放，潜在的导致应用内存超过限制并且崩溃

在android3.0（API 11）中，bitmap的像素数据存储在Dalvik堆中于bitmap相关联

The following sections describe how to optimize bitmap memory management for different Android versions.

下面章节讲述在不同的android版本中，如何最优化bitmap内存管理

Manage Memory on Android 2.3.3 and Lower

在android2.3.3以及更低的版本中管理内存

On Android 2.3.3 (API level 10) and lower, using recycle() is recommended.

If you're displaying large amounts of bitmap data in your app, you're likely to run into OutOfMemoryError errors.

The recycle() method allows an app to reclaim memory as soon as possible.

在android2.3.3以及更低的版本中，建议使用recycle()

如果你在你的应用中大量的显示bitmap数据，你很可能得到OutOfMemoryError错误

recycle()方法允许一个应用尽快回收内存

Caution: You should use recycle() only when you are sure that the bitmap is no longer being used.

If you call recycle() and later attempt to draw the bitmap, you will get the error: "Canvas: trying to use a recycled bitmap".

注意：仅当你确定这个bitmap不会再被使用的时候，你才应该使用recycle()

如果你调用了recycle()，之后又试图绘制这个bitmap，你会得到错误：“Canvas: trying to use a recycled bitmap”

The following code snippet gives an example of calling recycle().

It uses reference counting (in the variables mDisplayRefCount and mCacheRefCount) to track whether a bitmap is currently being displayed or in the cache.

The code recycles the bitmap when these conditions are met:

下面的代码片断给出了一个调用recycle()例子

它使用引用计数（在变量mDisplayRefCount 和 mCacheRefCount中）来跟踪一个bitmap当前正在被显示还是在缓存中

代码回收bitmap需要的条件是：

The reference count for both mDisplayRefCount and mCacheRefCount is 0.

The bitmap is not null, and it hasn't been recycled yet.

引用计数mDisplayRefCount和mCacheRefCount都要=0

bitmap不为null，并且它还没有被回收

[java] view plain copy

privateintmCacheRefCount=0;
privateintmDisplayRefCount=0;
...
//Notifythedrawablethatthedisplayedstatehaschanged.
//Keepacounttodeterminewhenthedrawableisnolongerdisplayed.
publicvoidsetIsDisplayed(booleanisDisplayed){
synchronized(this){
if(isDisplayed){
mDisplayRefCount++;
mHasBeenDisplayed=true;
}else{
mDisplayRefCount--;
}
}
//Checktoseeifrecycle()canbecalled.
checkState();
}
//Notifythedrawablethatthecachestatehaschanged.
//Keepacounttodeterminewhenthedrawableisnolongerbeingcached.
publicvoidsetIsCached(booleanisCached){
synchronized(this){
if(isCached){
mCacheRefCount++;
}else{
mCacheRefCount--;
}
}
//Checktoseeifrecycle()canbecalled.
checkState();
}
privatesynchronizedvoidcheckState(){
//Ifthedrawablecacheanddisplayrefcounts=0,andthisdrawable
//hasbeendisplayed,thenrecycle.
if(mCacheRefCount<=0&&mDisplayRefCount<=0&&mHasBeenDisplayed
&&hasValidBitmap()){
getBitmap().recycle();
}
}
privatesynchronizedbooleanhasValidBitmap(){
Bitmapbitmap=getBitmap();
returnbitmap!=null&&!bitmap.isRecycled();
}

Manage Memory on Android 3.0 and Higher

在android3.0以及更高的版本中管理内存

Android 3.0 (API Level 11) introduces the BitmapFactory.Options.inBitmap field.

If this option is set, decode methods that take the Options object will attempt to reuse an existing bitmap when loading content.

This means that the bitmap's memory is reused, resulting in improved performance, and removing both memory allocation and de-allocation.

There are some caveats in using inBitmap:

Android3.0（API 11）引入了BitmapFactory.Options.inBitmap

如果设置了这个选项，当加载内容的时候，使用Options对象的解码方法将会尝试复用一个存在的bitmap

这意为着bitmap的内存被复用了，导致性能提升，并且无须分配与重新分配内存

使用inBitmap有一些需要注意的地方：

The reused bitmap must be of the same size as the source content (to make sure that the same amount of memory is used), and in JPEG or PNG format (whether as a resource or as a stream).

重用的bitmap必须与源内容尺寸一致（保证相同的内存被使用），并且是JPEG或者PNG格式（作为resource或者stream）

The configuration of the reused bitmap overrides the setting of inPreferredConfig, if set.

You should always use the returned bitmap of the decode method, because you can't assume that reusing the bitmap worked (for example, if there is a size mismatch).

Save a bitmap for later use

如果设置了inPreferredConfig，重用的bitmap的配置就重写了inPreferredConfig

你应该总数使用解码函数返回的bitmap，因为你不能假定重用的bitmap能工作（例如，如果尺寸不匹配）

为之后使用保存一个bitmap

The following snippet demonstrates how an existing bitmap is stored for possible later use in the sample app.

When an app is running on Android 3.0 or higher and a bitmap is evicted from the LruCache, a soft reference to the bitmap is placed in a HashSet, for possible reuse later with inBitmap:

下面的代码片断示范在样本应用中，一个存在的图片如何为之后可能的使用而存储

当一个应用运行在andoid3.0或者更高版本中，并且LruCache已经回收了bitmap，为了之后使用inBitmap重用bitmap，在HashSet中存放bitmap的一个软引用。

[java] view plain copy

HashSet<SoftReference<Bitmap>>mReusableBitmaps;
privateLruCache<String,BitmapDrawable>mMemoryCache;
//Ifyou'rerunningonHoneycombornewer,create
//aHashSetofreferencestoreusablebitmaps.
if(Utils.hasHoneycomb()){
mReusableBitmaps=newHashSet<SoftReference<Bitmap>>();
}
mMemoryCache=newLruCache<String,BitmapDrawable>(mCacheParams.memCacheSize){
//Notifytheremovedentrythatisnolongerbeingcached.
@Override
protectedvoidentryRemoved(booleanevicted,Stringkey,
BitmapDrawableoldValue,BitmapDrawablenewValue){
if(RecyclingBitmapDrawable.class.isInstance(oldValue)){
//Theremovedentryisarecyclingdrawable,sonotifyit
//thatithasbeenremovedfromthememorycache.
((RecyclingBitmapDrawable)oldValue).setIsCached(false);
}else{
//TheremovedentryisastandardBitmapDrawable.
if(Utils.hasHoneycomb()){
//We'rerunningonHoneycomborlater,soaddthebitmap
//toaSoftReferencesetforpossibleusewithinBitmaplater.
mReusableBitmaps.add
(newSoftReference<Bitmap>(oldValue.getBitmap()));
}
}
}
....
}

Use an existing bitmap

使用已经存在的bitmap

In the running app, decoder methods check to see if there is an existing bitmap they can use.

For example:

在运行中的应用中，解码方法检查是否有已经存在的bitmap可供使用

[java] view plain copy

publicstaticBitmapdecodeSampledBitmapFromFile(Stringfilename,
intreqWidth,intreqHeight,ImageCachecache){
finalBitmapFactory.Optionsoptions=newBitmapFactory.Options();
...
BitmapFactory.decodeFile(filename,options);
...
//Ifwe'rerunningonHoneycombornewer,trytouseinBitmap.
if(Utils.hasHoneycomb()){
addInBitmapOptions(options,cache);
}
...
returnBitmapFactory.decodeFile(filename,options);
}

The next snippet shows the addInBitmapOptions() method that is called in the above snippet.

It looks for an existing bitmap to set as the value for inBitmap.

Note that this method only sets a value for inBitmap if it finds a suitable match (your code should never assume that a match will be found):

下面的代码片断展示上面代码中调用的addInBitmapOptions()方法

它寻找一个存在的bitmap作为inBitmap的值

注意，这个方法只设置inBitmap，如果找到了合适的匹配的话（你的代码不该假设这个匹配一定会找到）

[java] view plain copy

privatestaticvoidaddInBitmapOptions(BitmapFactory.Optionsoptions,
ImageCachecache){
//inBitmaponlyworkswithmutablebitmaps,soforcethedecoderto
//returnmutablebitmaps.
options.inMutable=true;
if(cache!=null){
//TrytofindabitmaptouseforinBitmap.
BitmapinBitmap=cache.getBitmapFromReusableSet(options);
if(inBitmap!=null){
//Ifasuitablebitmaphasbeenfound,setitasthevalueof
//inBitmap.
options.inBitmap=inBitmap;
}
}
}
//Thismethoditeratesthroughthereusablebitmaps,lookingforone
//touseforinBitmap:
protectedBitmapgetBitmapFromReusableSet(BitmapFactory.Optionsoptions){
Bitmapbitmap=null;
if(mReusableBitmaps!=null&&!mReusableBitmaps.isEmpty()){
finalIterator<SoftReference<Bitmap>>iterator
=mReusableBitmaps.iterator();
Bitmapitem;
while(iterator.hasNext()){
item=iterator.next().get();
if(null!=item&&item.isMutable()){
//ChecktoseeittheitemcanbeusedforinBitmap.
if(canUseForInBitmap(item,options)){
bitmap=item;
//Removefromreusablesetsoitcan'tbeusedagain.
iterator.remove();
break;
}
}else{
//Removefromthesetifthereferencehasbeencleared.
iterator.remove();
}
}
}
returnbitmap;
}

Finally, this method determines whether a candidate bitmap satisfies the size criteria to be used for inBitmap:

最后，这个方法决定一个备选bitmap是否满足设置inBitmap的尺寸标准

[java] view plain copy

privatestaticbooleancanUseForInBitmap(
Bitmapcandidate,BitmapFactory.OptionstargetOptions){
intwidth=targetOptions.outWidth/targetOptions.inSampleSize;
intheight=targetOptions.outHeight/targetOptions.inSampleSize;
//Returnstrueif"candidate"canbeusedforinBitmapre-usewith
//"targetOptions".
returncandidate.getWidth()==width&&candidate.getHeight()==height;
}

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

http://developer.android.com/training/displaying-bitmaps/manage-memory.html

转贴请保留以下链接

本人blog地址

http://su1216.iteye.com/

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

android 缓存Bitmap

android 缓存Bitmap - 开发文档翻译

android 管理Bitmap内存 - 开发文档翻译

更多相关文章

随机推荐