內容概述
[翻譯]開發文檔:android Bitmap的高效使用
本文內容來自開發文檔“Traning > Displaying Bitmaps Efficiently”,包括大尺寸Bitmap的高效加載,圖片的異步加載和數據緩存。
Bitmap的處理和加載非常重要,這關系到app的流暢運行和內存占用,如果方法不當,很容易導致界面卡頓和OOM。其中的原因大致有:
- android系統對進程的內存分配限制,移動設備的配置較低。
- Bitmap會消耗很大內存。比如相機拍下的 2592x1936 像素的照片,以ARGB_8888 格式一次加載到內存,將占據19M(259219364 bytes)的內存!
- 通常像ListView,GridView,ViewPager這樣的UI元素會同時顯示或預加載多個View,這導致內存中同時需要多個Bitmaps。
下面從幾個方面來分析如何高效的使用圖片。
高效地加載大圖
原始圖片和最終顯示它的View對應,一般要比顯示它的View的大小要大,一些拍攝的照片甚至要比手機的屏幕分辨率還要大得多。
原則上“顯示多少加載多少”,沒有必要加載一個分辨率比將要顯示的分辨率還大的圖片,除了浪費內存沒有任何好處。
下面就來看如何加載一個圖片的較小的二次采樣后的版本。
讀取Bitmap的尺寸和類型
BitmapFactory類提供了幾個方法用來從不同的源來加載位圖(decodeByteArray(), decodeFile(), decodeResource(), etc.) ,它們都接收一個BitmapFactory.Options類型的參數,為了獲取目標圖片的尺寸類型,可以將此參數的 inJustDecodeBounds設置為true來只加載圖片屬性信息,而不去實際加載其內容到內存中。
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(getResources(), R.id.myimage, options);
int imageHeight = options.outHeight;
int imageWidth = options.outWidth;
String imageType = options.outMimeType;
上面的代碼展示了如何不加載圖片,而預先讀取它的Width、Height、MiMeType。有了這些信息,就可以根據可用內存來“選擇性”地加載圖片,避免OOM。
加載縮小后的圖片
知道目標圖片的尺寸后,可以根據當前內存狀態或者顯示需求來決定是加載原始圖片,或者是采樣后的版本。下面是一些參考:
- 估算加載完整圖片需要的內存。
- 加載這些圖片允許的內存大小,要知道總得給程序其它操作留夠內存。
- 使用此圖片資源的目標ImageView或其它UI組件的尺寸。
- 當前設備的屏幕大小和分辨率。
比如,在一個作為縮略圖的大小為128x96的ImageView中加載1024x768的圖片是完全沒有必要的。
為了讓圖片解碼器(decoder)在加載圖片時使用二次采樣(subsample),可以設置參數BitmapFactory.Options 的inSampleSize屬性。比如,一張2048x1536 分辨率的圖片,使用inSampleSize為4的參數加載后,以ARGB_8888格式計算,最終是 512x384的圖片,占0.75M的內存,而原始分辨率則占12M。
下面的方法用來計算采樣率,它保證縮放的比例是2的次方,參見inSampleSize的說明:
If set to a value > 1, requests the decoder to subsample the original image, returning a smaller image to save memory. The sample size is the number of pixels in either dimension that correspond to a single pixel in the decoded bitmap. For example, inSampleSize == 4 returns an image that is 1/4 the width/height of the original, and 1/16 the number of pixels. Any value <= 1 is treated the same as 1. Note: the decoder uses a final value based on powers of 2, any other value will be rounded down to the nearest power of 2.
public static int calculateInSampleSize(
BitmapFactory.Options options, int reqWidth, int reqHeight) {
// Raw height and width of image
final int height = options.outHeight;
final int width = options.outWidth;
int inSampleSize = 1;
if (height > reqHeight || width > reqWidth) {
final int halfHeight = height / 2;
final int halfWidth = width / 2;
// Calculate the largest inSampleSize value that is a power of 2 and keeps both
// height and width larger than the requested height and width.
while ((halfHeight / inSampleSize) > reqHeight
&& (halfWidth / inSampleSize) > reqWidth) {
inSampleSize *= 2;
}
}
return inSampleSize;
}
先設置 inJustDecodeBounds為true獲得圖片信息,計算出采樣率,之后設置 inJustDecodeBounds為false,傳遞得到的inSampleSize來實際加載縮略圖:
public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId,
int reqWidth, int reqHeight) {
// First decode with inJustDecodeBounds=true to check dimensions
final BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(res, resId, options);
// Calculate inSampleSize
options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);
// Decode bitmap with inSampleSize set
options.inJustDecodeBounds = false;
return BitmapFactory.decodeResource(res, resId, options);
}
通過上述的方法,就可以把任意大小的圖片加載為一個100x100的縮略圖。類似這樣:
mImageView.setImageBitmap(
decodeSampledBitmapFromResource(getResources(), R.id.myimage, 100, 100));
其它幾個BitmapFactory.decode**的方法都接收相同的參數,可以采用同樣的方法來安全地加載大圖。
在非UI線程中處理Bitmap
從網絡和磁盤加載圖片可能很耗時,這樣如果在UI線程中執行加載就會很容易引起ANR,下面使用AsyncTask來在后臺線程中異步加載圖片,并演示一些同步技巧。
使用AsyncTask
AsyncTask提供了一個簡單的方式異步執行操作,然后回到UI線程中處理結果。下面就實現一個AsyncTask子類來加載圖片到ImageView。
class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> {
private final WeakReference<ImageView> imageViewReference;
private int data = 0;
public BitmapWorkerTask(ImageView imageView) {
// Use a WeakReference to ensure the ImageView can be garbage collected
imageViewReference = new WeakReference<ImageView>(imageView);
}
// Decode image in background.
@Override
protected Bitmap doInBackground(Integer... params) {
data = params[0];
return decodeSampledBitmapFromResource(getResources(), data, 100, 100));
}
// Once complete, see if ImageView is still around and set bitmap.
@Override
protected void onPostExecute(Bitmap bitmap) {
if (imageViewReference != null && bitmap != null) {
final ImageView imageView = imageViewReference.get();
if (imageView != null) {
imageView.setImageBitmap(bitmap);
}
}
}
}
上面方法decodeSampledBitmapFromResource()是前一節“加載大圖”的代碼示例。
WeakReference保證了其它對ImageView的強引用消失后,它可以被正常回收。也許異步加載操作執行結束后ImageView已經不存在了(界面銷毀?橫豎屏切換引起Activity重建?),這時就沒必要去繼續顯示圖片了。所以在onPostExecute()中需要額外的null檢查。
有了上面的BitmapWorkerTask后,就可以異步加載圖片:
public void loadBitmap(int resId, ImageView imageView) {
BitmapWorkerTask task = new BitmapWorkerTask(imageView);
task.execute(resId);
}
并發處理
對于在像ListView和GridView中顯示圖片這樣的場景,ImageView很可能會被“復用”,這樣在快速滑動時,一個ImageView很可能在圖片尚未加載顯示時就被用來顯示另一個圖片,此時,上面的BitmapWorkerTask就無法保證onPostExecute中收到的Bitmap就是此ImageView當前需要顯示的圖片。簡單地說就是圖片在這些列表控件中發生錯位了,本質來看,這是一個異步操作引發的并發問題。
下面采取“綁定/關聯”的方式來處理上面的并發問題,這里創建一個Drawable的子類AsyncDrawable,它設置給ImageView,同時它持有對應BitmapWorkerTask 的引用,所以在對ImageView加載圖片時,可以根據此AsyncDrawable來獲取之前執行中的BitmapWorkerTask,之后取消它,或者在發現重復加載后放棄操作。
static class AsyncDrawable extends BitmapDrawable {
private final WeakReference<BitmapWorkerTask> bitmapWorkerTaskReference;
public AsyncDrawable(Resources res, Bitmap bitmap,
BitmapWorkerTask bitmapWorkerTask) {
super(res, bitmap);
bitmapWorkerTaskReference =
new WeakReference<BitmapWorkerTask>(bitmapWorkerTask);
}
public BitmapWorkerTask getBitmapWorkerTask() {
return bitmapWorkerTaskReference.get();
}
}
上面,AsyncDrawable的作用類似View.setTag和ViewHolder。
在執行BitmapWorkerTask前,創建一個AsyncDrawable,然后把它綁定到目標ImageView。
注意:列表異步加載圖片的場景下,ImageView是容器,是復用的。也就是并發的共享資源。
public void loadBitmap(int resId, ImageView imageView) {
if (cancelPotentialWork(resId, imageView)) {
final BitmapWorkerTask task = new BitmapWorkerTask(imageView);
final AsyncDrawable asyncDrawable =
new AsyncDrawable(getResources(), mPlaceHolderBitmap, task);
imageView.setImageDrawable(asyncDrawable);
task.execute(resId);
}
}
上面setImageDrawable()方法把ImageView和最新加載圖片給它的異步任務關聯起來了。
cancelPotentialWork方法()用來判斷是否已經有一個任務正在加載圖片到此ImageView中。如果沒有,或者有但加載的是其它圖片,則取消此“過期”的異步任務。如果有任務正在加載同樣的圖片到此ImageView那么就沒必要重復開啟任務了。
public static boolean cancelPotentialWork(int data, ImageView imageView) {
final BitmapWorkerTask bitmapWorkerTask = getBitmapWorkerTask(imageView);
if (bitmapWorkerTask != null) {
final int bitmapData = bitmapWorkerTask.data;
// If bitmapData is not yet set or it differs from the new data
if (bitmapData == 0 || bitmapData != data) {
// Cancel previous task
bitmapWorkerTask.cancel(true);
} else {
// The same work is already in progress
return false;
}
}
// No task associated with the ImageView, or an existing task was cancelled
return true;
}
輔助方法getBitmapWorkerTask()用來獲取ImageView關聯的BitmapWorkerTask。
private static BitmapWorkerTask getBitmapWorkerTask(ImageView imageView) {
if (imageView != null) {
final Drawable drawable = imageView.getDrawable();
if (drawable instanceof AsyncDrawable) {
final AsyncDrawable asyncDrawable = (AsyncDrawable) drawable;
return asyncDrawable.getBitmapWorkerTask();
}
}
return null;
}
最后,修改BitmapWorkerTask的 onPostExecute()方法,只有在任務未被取消,而且目標ImageView關聯的BitmapWorkerTask對象為當前BitmapWorkerTask時,才設置Bitmap給此ImageView:
class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> {
...
@Override
protected void onPostExecute(Bitmap bitmap) {
if (isCancelled()) {
bitmap = null;
}
if (imageViewReference != null && bitmap != null) {
final ImageView imageView = imageViewReference.get();
final BitmapWorkerTask bitmapWorkerTask =
getBitmapWorkerTask(imageView);
if (this == bitmapWorkerTask && imageView != null) {
imageView.setImageBitmap(bitmap);
}
}
}
}
通過上述過程,就可以使用BitmapWorkerTask 正確安全地異步加載圖片了。
Bitmap的緩存
上面分別從節約內存和避免耗時加載卡頓界面兩個方面討論了有關圖片處理的技巧。
在列表顯示大量圖片,或者其它任意的圖片顯示操作下,默認地系統會對內存中無強引用的圖片數據進行回收,而很多時候,如列表來回滑動多次顯示同樣的圖片,引起圖片的內存釋放和反復加載,圖片加載是耗時操作,最終,使得圖片展示交互體驗無法流暢進行。
下面從“緩存”的方式講起,介紹下如何使用內存緩存和磁盤緩存來提高圖片顯示的流暢度。
內存緩存
從Android 2.3 (API Level 9)開始,GC對Soft/WeakReference的回收更加頻繁,所以基于這些引用的緩存策略效果大打折扣。而且在Android 3.0 (API Level 11)以前,Bitmap的數據是以native的方式存儲的,對它們的“默認回收”的行為可能引發潛在的內存泄露。
所以,現在推薦的方式是使用強引用,結合LruCache類提供的算法(它在API 12引入,Support庫也提供了相同的實現使得支持API 4以上版本)來實現緩存。LruCache算法內部使用 LinkedHashMap 保持緩存對象的強引用,它維持緩存在一個限制的范圍內,在內存要超越限制時優先釋放最近最少使用的key。
在選擇LruCache要維護的緩存總大小時,下面時一些參考建議:
- 其余Activity或進程對內存的大小要求?
- 屏幕同時需要顯示多少圖片,多少會很快進入顯示狀態?
- 設備的大小和分辨率?高分辨率設備在顯示相同“大小”和數量圖片時需要的內存更多。
- 圖片被訪問的頻率,如果一些圖片的訪問比其它一些更加頻繁,那么最好使用多個LruCache來實現不同需求的緩存。
- 數量和質量的平衡:有時可以先加載低質量的圖片,然后異步加載高質量的版本。
緩存的大小沒有標準的最佳數值,根據app的需求場景而定,如果太小則帶來的速度收益不大,如果太大則容易引起OOM。
下面是一個使用LruCache來緩存Bitmap的簡單示例:
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);
}
上面的代碼使用了進程分配內存的1/8來作為緩存的最大值。在一個標準/hdpi分辨率的設備上,最小值大約為4MB(32/8)。一個800x480的設備上,全屏的GridView填滿圖片后大約使用1.5MB(8004804 bytes)的內存,這樣,緩存可以保證約2.5頁的圖片數據。
在使用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;
}
...
}
磁盤緩存
內存緩存的確是最快速的,但是一方面內存容易受限,另一方面進程重建后緩存就失效了。可以增加一個磁盤緩存的策略,這樣可以緩存更多的內容,而且依然提供比網絡獲取數據更好的速度。如果圖片被訪問非常頻繁,也可以考慮使用ContentProvider實現圖片數據的緩存。
下面的代碼使用DiskLruCache(它從android源碼中可獲得,在sdk提供的sample中也有)來實現磁盤緩存:
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) {
// 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);
}
因為磁盤讀取依然屬于耗時操作,需要在后臺線程中從磁盤加載圖片。另一方面,磁盤緩存需要一個初始化過程,也是異步完成,所以上面提供一個mDiskCacheLock 來保證DiskLruCache的訪問同步。顯然,磁盤緩存結合內存緩存是最佳的選擇,上面數據從網絡和從磁盤讀取后都會同步到內存緩存中。
Bitmap內存管理
上面介紹了對Bitmap的緩存的實現,更進一步,下面來看看如何高效地釋放Bitmap的內存,以及促進對它的復用。
首先,Bitmap的內存管理在不同的android版本中默認策略不同:
在android 2.2(API 8)及更低的版本中,GC回收內存時主線程等待,而之后3.0 (API level 11)引入了并發的垃圾回收線程,這樣,如果Bitmap不再被引用時,它對應的內存很快就會被回收。
在2.3.3 (API level 10)版本及以前,Bitmap對應圖片的像素數據是native內存中存儲的,和Bitmap對象(在Dalvik堆內存中)是分開的。當Bitmap對象回收后對應的內存的回收行為不可預期,這樣就會導致程序很容易達到內存邊界。3.0版本就將像素數據和Bitmap對象存儲在一起(Dalvik heap中 ),對象回收后對應像素數據也被釋放。
android 2.3.3及更低版本的Bitmap內存管理
在2.3.3及以前版本中,android.graphics.Bitmap#recycle
方法被推薦使用,調用后對應圖片數據回盡快被回收掉。但確保對應圖片的確不再使用了,因為方法執行后就不能再對對應的Bitmap做任何使用了,否則收到“"Canvas: trying to use a recycled bitmap"”這樣的錯誤。
下面的代碼演示了使用“引用計數”的方式來管理recycle()方法的執行,當一個Bitmap對象不再被顯示或緩存時,就調用其recycle()方法主動釋放其像素數據。
/**
* A BitmapDrawable that keeps track of whether it is being displayed or cached.
* When the drawable is no longer being displayed or cached,
* {@link android.graphics.Bitmap#recycle() recycle()} will be called on this drawable's bitmap.
*/
public class RecyclingBitmapDrawable extends BitmapDrawable {
static final String TAG = "CountingBitmapDrawable";
private int mCacheRefCount = 0;
private int mDisplayRefCount = 0;
private boolean mHasBeenDisplayed;
public RecyclingBitmapDrawable(Resources res, Bitmap bitmap) {
super(res, bitmap);
}
/**
* Notify the drawable that the displayed state has changed. Internally a
* count is kept so that the drawable knows when it is no longer being
* displayed.
*
* @param isDisplayed - Whether the drawable is being displayed or not
*/
public void setIsDisplayed(boolean isDisplayed) {
synchronized (this) {
if (isDisplayed) {
mDisplayRefCount++;
mHasBeenDisplayed = true;
} else {
mDisplayRefCount--;
}
}
// Check to see if recycle() can be called
checkState();
}
/**
* Notify the drawable that the cache state has changed. Internally a count
* is kept so that the drawable knows when it is no longer being cached.
*
* @param isCached - Whether the drawable is being cached or not
*/
public void setIsCached(boolean isCached) {
synchronized (this) {
if (isCached) {
mCacheRefCount++;
} else {
mCacheRefCount--;
}
}
// Check to see if recycle() can be called
checkState();
}
private synchronized void checkState() {
// If the drawable cache and display ref counts = 0, and this drawable
// has been displayed, then recycle
if (mCacheRefCount <= 0 && mDisplayRefCount <= 0 && mHasBeenDisplayed
&& hasValidBitmap()) {
if (BuildConfig.DEBUG) {
Log.d(TAG, "No longer being used or cached so recycling. "
+ toString());
}
getBitmap().recycle();
}
}
private synchronized boolean hasValidBitmap() {
Bitmap bitmap = getBitmap();
return bitmap != null && !bitmap.isRecycled();
}
}
android 3.0 及以上版本bitmap內存的管理
在3.0(API 11)版本后 增加了BitmapFactory.Options.inBitmap 字段,使用為此字段設置了Bitmap對象的參數的decode方法會嘗試復用現有的bitmap內存,這樣避免了內存的分配和回收。
不過實際的實現很受限,比如在4.4(API 19)版本以前,只有大小相同的bitmap可以被復用。
下面的代碼中,使用一個HashSet來維護一個WeakReference的集合,它們引用了使用LruCache緩存被丟棄的那些Bitmap,這樣后續的decode就可以復用它們。
Set<SoftReference<Bitmap>> mReusableBitmaps;
private LruCache<String, BitmapDrawable> mMemoryCache;
// If you're running on Honeycomb or newer, create a
// synchronized HashSet of references to reusable bitmaps.
if (Utils.hasHoneycomb()) {
mReusableBitmaps =
Collections.synchronizedSet(new HashSet<SoftReference<Bitmap>>());
}
mMemoryCache = new LruCache<String, BitmapDrawable>(mCacheParams.memCacheSize) {
// Notify the removed entry that is no longer being cached.
@Override
protected void entryRemoved(boolean evicted, String key,
BitmapDrawable oldValue, BitmapDrawable newValue) {
if (RecyclingBitmapDrawable.class.isInstance(oldValue)) {
// The removed entry is a recycling drawable, so notify it
// that it has been removed from the memory cache.
((RecyclingBitmapDrawable) oldValue).setIsCached(false);
} else {
// The removed entry is a standard BitmapDrawable.
if (Utils.hasHoneycomb()) {
// We're running on Honeycomb or later, so add the bitmap
// to a SoftReference set for possible use with inBitmap later.
mReusableBitmaps.add
(new SoftReference<Bitmap>(oldValue.getBitmap()));
}
}
}
....
}
復用已有的Bitmap
decode方法可以從前面的集合中先查看是否有可用的對象。
public static Bitmap decodeSampledBitmapFromFile(String filename,
int reqWidth, int reqHeight, ImageCache cache) {
final BitmapFactory.Options options = new BitmapFactory.Options();
...
BitmapFactory.decodeFile(filename, options);
...
// If we're running on Honeycomb or newer, try to use inBitmap.
if (Utils.hasHoneycomb()) {
addInBitmapOptions(options, cache);
}
...
return BitmapFactory.decodeFile(filename, options);
}
方法addInBitmapOptions() 完成Bitmap的查找和對inBitmap的設置:
private static void addInBitmapOptions(BitmapFactory.Options options,
ImageCache cache) {
// inBitmap only works with mutable bitmaps, so force the decoder to
// return mutable bitmaps.
options.inMutable = true;
if (cache != null) {
// Try to find a bitmap to use for inBitmap.
Bitmap inBitmap = cache.getBitmapFromReusableSet(options);
if (inBitmap != null) {
// If a suitable bitmap has been found, set it as the value of
// inBitmap.
options.inBitmap = inBitmap;
}
}
}
// This method iterates through the reusable bitmaps, looking for one
// to use for inBitmap:
protected Bitmap getBitmapFromReusableSet(BitmapFactory.Options options) {
Bitmap bitmap = null;
if (mReusableBitmaps != null && !mReusableBitmaps.isEmpty()) {
synchronized (mReusableBitmaps) {
final Iterator<SoftReference<Bitmap>> iterator
= mReusableBitmaps.iterator();
Bitmap item;
while (iterator.hasNext()) {
item = iterator.next().get();
if (null != item && item.isMutable()) {
// Check to see it the item can be used for inBitmap.
if (canUseForInBitmap(item, options)) {
bitmap = item;
// Remove from reusable set so it can't be used again.
iterator.remove();
break;
}
} else {
// Remove from the set if the reference has been cleared.
iterator.remove();
}
}
}
}
return bitmap;
}
要知道并不一定可以找到“合適”的Bitmap來復用。方法canUseForInBitmap()通過對大小的檢查來判定是否可以被復用:
static boolean canUseForInBitmap(
Bitmap candidate, BitmapFactory.Options targetOptions) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
// From Android 4.4 (KitKat) onward we can re-use if the byte size of
// the new bitmap is smaller than the reusable bitmap candidate
// allocation byte count.
int width = targetOptions.outWidth / targetOptions.inSampleSize;
int height = targetOptions.outHeight / targetOptions.inSampleSize;
int byteCount = width * height * getBytesPerPixel(candidate.getConfig());
return byteCount <= candidate.getAllocationByteCount();
}
// On earlier versions, the dimensions must match exactly and the inSampleSize must be 1
return candidate.getWidth() == targetOptions.outWidth
&& candidate.getHeight() == targetOptions.outHeight
&& targetOptions.inSampleSize == 1;
}
/**
* A helper function to return the byte usage per pixel of a bitmap based on its configuration.
*/
static int getBytesPerPixel(Config config) {
if (config == Config.ARGB_8888) {
return 4;
} else if (config == Config.RGB_565) {
return 2;
} else if (config == Config.ARGB_4444) {
return 2;
} else if (config == Config.ALPHA_8) {
return 1;
}
return 1;
}
在界面顯示圖片
下面分別示范ViewPager和GridView的形式來展示圖片,綜合了上面的異步加載,緩存等知識。
使用ViewPager
可以用ViewPager實現“swipe view pattern”,比如在圖片瀏覽功能中左右滑動來查看不同的圖片(上一個,下一個)。
既然使用ViewPager,就需要為它提供PagerAdapter子類。假設圖片的預計內存使用不用太過擔心,那么PagerAdapter或者FragmentPagerAdapter就夠用了,更復雜的內存管理需求下,可以采用FragmentStatePagerAdapter,它在ViewPager顯示的不同Fragment離開屏幕后自動銷毀它們并保持其狀態。
下面代碼中,ImageDetailActivity中定義了顯示用的ViewPager和它對應的ImagePagerAdapter:
public class ImageDetailActivity extends FragmentActivity {
public static final String EXTRA_IMAGE = "extra_image";
private ImagePagerAdapter mAdapter;
private ViewPager mPager;
// A static dataset to back the ViewPager adapter
public final static Integer[] imageResIds = new Integer[] {
R.drawable.sample_image_1, R.drawable.sample_image_2, R.drawable.sample_image_3,
R.drawable.sample_image_4, R.drawable.sample_image_5, R.drawable.sample_image_6,
R.drawable.sample_image_7, R.drawable.sample_image_8, R.drawable.sample_image_9};
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.image_detail_pager); // Contains just a ViewPager
mAdapter = new ImagePagerAdapter(getSupportFragmentManager(), imageResIds.length);
mPager = (ViewPager) findViewById(R.id.pager);
mPager.setAdapter(mAdapter);
}
public static class ImagePagerAdapter extends FragmentStatePagerAdapter {
private final int mSize;
public ImagePagerAdapter(FragmentManager fm, int size) {
super(fm);
mSize = size;
}
@Override
public int getCount() {
return mSize;
}
@Override
public Fragment getItem(int position) {
return ImageDetailFragment.newInstance(position);
}
}
}
類ImageDetailFragment作為ViewPager的item,用來展示一個圖片的詳細內容:
public class ImageDetailFragment extends Fragment {
private static final String IMAGE_DATA_EXTRA = "resId";
private int mImageNum;
private ImageView mImageView;
static ImageDetailFragment newInstance(int imageNum) {
final ImageDetailFragment f = new ImageDetailFragment();
final Bundle args = new Bundle();
args.putInt(IMAGE_DATA_EXTRA, imageNum);
f.setArguments(args);
return f;
}
// Empty constructor, required as per Fragment docs
public ImageDetailFragment() {}
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mImageNum = getArguments() != null ? getArguments().getInt(IMAGE_DATA_EXTRA) : -1;
}
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
// image_detail_fragment.xml contains just an ImageView
final View v = inflater.inflate(R.layout.image_detail_fragment, container, false);
mImageView = (ImageView) v.findViewById(R.id.imageView);
return v;
}
@Override
public void onActivityCreated(Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
final int resId = ImageDetailActivity.imageResIds[mImageNum];
mImageView.setImageResource(resId); // Load image into ImageView
}
}
上面的圖片加載是在UI線程中執行的,利用之前的AsyncTask實現的異步加載功能,將操作放在后臺線程中去:
public class ImageDetailActivity extends FragmentActivity {
...
public void loadBitmap(int resId, ImageView imageView) {
mImageView.setImageResource(R.drawable.image_placeholder);
BitmapWorkerTask task = new BitmapWorkerTask(mImageView);
task.execute(resId);
}
... // include BitmapWorkerTask class
}
public class ImageDetailFragment extends Fragment {
...
@Override
public void onActivityCreated(Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
if (ImageDetailActivity.class.isInstance(getActivity())) {
final int resId = ImageDetailActivity.imageResIds[mImageNum];
// Call out to ImageDetailActivity to load the bitmap in a background thread
((ImageDetailActivity) getActivity()).loadBitmap(resId, mImageView);
}
}
}
正如上面展示的那樣,可以將需要的耗時處理放在BitmapWorkerTask中去執行。下面為整個代碼加入緩存功能:
public class ImageDetailActivity extends FragmentActivity {
...
private LruCache<String, Bitmap> mMemoryCache;
@Override
public void onCreate(Bundle savedInstanceState) {
...
// initialize LruCache as per Use a Memory Cache section
}
public void loadBitmap(int resId, ImageView imageView) {
final String imageKey = String.valueOf(resId);
final Bitmap bitmap = mMemoryCache.get(imageKey);
if (bitmap != null) {
mImageView.setImageBitmap(bitmap);
} else {
mImageView.setImageResource(R.drawable.image_placeholder);
BitmapWorkerTask task = new BitmapWorkerTask(mImageView);
task.execute(resId);
}
}
... // include updated BitmapWorkerTask from Use a Memory Cache section
}
上面的代碼實現使得圖片的加載顯示灰常流暢,如果還需要對圖片施加額外的處理,都可以繼續去擴展異步任務來實現。
使用GridView展示圖片
網格視圖的顯示風格非常適合每個Item都是縮略圖這樣的情形。這時,同時在屏幕上會展示大量圖片,隨著滑動ImageView也會被回收利用。相比ViewPager每次展示一個圖片的較大的情況,此時除了可以使用上面提到的緩存,異步加載技術外,一個需要處理的問題就是“并發”——異步加載時保證ImageView顯示圖片不會錯亂。同樣的問題在ListView中也是存在的,因為它們的re-use原則。
下面的ImageGridFragment 用來顯示整個GridView,它里面同時定義了用到的BaseAdapter:
public class ImageGridFragment extends Fragment implements AdapterView.OnItemClickListener {
private ImageAdapter mAdapter;
// A static dataset to back the GridView adapter
public final static Integer[] imageResIds = new Integer[] {
R.drawable.sample_image_1, R.drawable.sample_image_2, R.drawable.sample_image_3,
R.drawable.sample_image_4, R.drawable.sample_image_5, R.drawable.sample_image_6,
R.drawable.sample_image_7, R.drawable.sample_image_8, R.drawable.sample_image_9};
// Empty constructor as per Fragment docs
public ImageGridFragment() {}
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mAdapter = new ImageAdapter(getActivity());
}
@Override
public View onCreateView(
LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
final View v = inflater.inflate(R.layout.image_grid_fragment, container, false);
final GridView mGridView = (GridView) v.findViewById(R.id.gridView);
mGridView.setAdapter(mAdapter);
mGridView.setOnItemClickListener(this);
return v;
}
@Override
public void onItemClick(AdapterView<?> parent, View v, int position, long id) {
final Intent i = new Intent(getActivity(), ImageDetailActivity.class);
i.putExtra(ImageDetailActivity.EXTRA_IMAGE, position);
startActivity(i);
}
private class ImageAdapter extends BaseAdapter {
private final Context mContext;
public ImageAdapter(Context context) {
super();
mContext = context;
}
@Override
public int getCount() {
return imageResIds.length;
}
@Override
public Object getItem(int position) {
return imageResIds[position];
}
@Override
public long getItemId(int position) {
return position;
}
@Override
public View getView(int position, View convertView, ViewGroup container) {
ImageView imageView;
if (convertView == null) { // if it's not recycled, initialize some attributes
imageView = new ImageView(mContext);
imageView.setScaleType(ImageView.ScaleType.CENTER_CROP);
imageView.setLayoutParams(new GridView.LayoutParams(
LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT));
} else {
imageView = (ImageView) convertView;
}
imageView.setImageResource(imageResIds[position]); // Load image into ImageView
return imageView;
}
}
}
上面的代碼暴露的問題就是異步加載和ImageView復用會產生錯亂,下面使用之前異步加載圖片中討論過的“關聯”技術來解決它:
public class ImageGridFragment extends Fragment implements AdapterView.OnItemClickListener {
...
private class ImageAdapter extends BaseAdapter {
...
@Override
public View getView(int position, View convertView, ViewGroup container) {
...
loadBitmap(imageResIds[position], imageView)
return imageView;
}
}
public void loadBitmap(int resId, ImageView imageView) {
if (cancelPotentialWork(resId, imageView)) {
final BitmapWorkerTask task = new BitmapWorkerTask(imageView);
final AsyncDrawable asyncDrawable =
new AsyncDrawable(getResources(), mPlaceHolderBitmap, task);
imageView.setImageDrawable(asyncDrawable);
task.execute(resId);
}
}
static class AsyncDrawable extends BitmapDrawable {
private final WeakReference<BitmapWorkerTask> bitmapWorkerTaskReference;
public AsyncDrawable(Resources res, Bitmap bitmap,
BitmapWorkerTask bitmapWorkerTask) {
super(res, bitmap);
bitmapWorkerTaskReference =
new WeakReference<BitmapWorkerTask>(bitmapWorkerTask);
}
public BitmapWorkerTask getBitmapWorkerTask() {
return bitmapWorkerTaskReference.get();
}
}
public static boolean cancelPotentialWork(int data, ImageView imageView) {
final BitmapWorkerTask bitmapWorkerTask = getBitmapWorkerTask(imageView);
if (bitmapWorkerTask != null) {
final int bitmapData = bitmapWorkerTask.data;
if (bitmapData != data) {
// Cancel previous task
bitmapWorkerTask.cancel(true);
} else {
// The same work is already in progress
return false;
}
}
// No task associated with the ImageView, or an existing task was cancelled
return true;
}
private static BitmapWorkerTask getBitmapWorkerTask(ImageView imageView) {
if (imageView != null) {
final Drawable drawable = imageView.getDrawable();
if (drawable instanceof AsyncDrawable) {
final AsyncDrawable asyncDrawable = (AsyncDrawable) drawable;
return asyncDrawable.getBitmapWorkerTask();
}
}
return null;
}
... // include updated BitmapWorkerTask class
以上的代碼保證了對GridView展示的圖片的異步加載不會導致錯亂,必須牢記耗時操作不要阻塞UI,保證交互流暢。對應ListView上面的代碼依然適用。
資料
- sdk開發文檔
Training > Displaying Bitmaps Efficiently,
目錄:/docs/training/displaying-bitmaps/index.html
(本文使用Atom編寫 2016/3/1)
文章列表