참조 사이트
Displaying Bitmaps Efficiently
http://developer.android.com/training/displaying-bitmaps/index.html
출저 : http://www.androidpub.com/2426245
안드로이드 개발자 공식 사이트에 있는 트레이닝 세션을 번역해 보았습니다.
http://yonght.tumblr.com/post/40418244176
트레이닝의 내용이 대체로 많이 쓰이고 좋은 내용이 많은 것 같아. 공부하면서 하나씩 올려보려고 합니다.
안드로이드 앱을 만들 때 가장 많이 하는 일 중에 하나가 사진을 찍어서 올리거나 인터넷에 있는 사진을 받아다 사용자에게 보여주는 일입니다. 스마트폰이 가진 중요한 기능 중의 하나가 카메라가 내장되어 있다는 것이고 이것이 인터넷과 연결되어 다른 사용자들에게 쉽게 공유할 수 있다는 것이기 때문이죠. 그래서 모바일 앱의 주요 컨텐츠 생산이나 소비 형태도 사진으로 많이 이루어져 있습니다.
안드로이드 개발자 공식 사이트에서도 상당히 앞쪽 부분에 사진을 다루는 비트맵에 대한 트레이닝 세션을 만들어 놓았습니다. 공부차 공식 블로그의 내용을 간단히 추려서 옮겨 봅니다. 원문과 샘플코드 다운로드는 Displaying Bitmaps Efficiently에서 보실 수 있습니다.
출처: 안드로이드 개발 사이트(http://develper.android.com). 번역: 용현택
안드로이드에서 처음에 아무생각없이 Bitmap 오브젝트를 이용해 사진을 불러오려다.
java.lang.OutofMemoryError: bitmap size exceeds VM budget
라는 메세지와 부딪히게 될 것이다. 당연히 메모리가 부족해서 나는 에러 이고 몇가지 이유가 있을 수 있는데 대강 다음의 이유로 뻗는 것이다.
- 안드로이드 장비의 메모리는 무한정이 아니다. 안드로이드 장비가 하나의 앱에 허용하는 메모리는 16MB이하를 사용하도록 하고 있다. 대부분의 디바이스들에서는 16MB보다 높게 제한이 걸려있긴 하지만 이보다 작은 메모리를 사용하도록 최적화 해야 할 것이다. 따라서 이 제한을 넘게되면 에러가 난다.
- 이미지는 메모리를 굉장히 많이 잡아 먹는다. 특히 요즘폰들은 화소가 높아서. 갤럭시 넥서스 같이 500만 화소 카메라로 찍게되면 2592*1936픽셀의 사진이 생겨나는데 ARGB_8888로 셋팅되어 있다면 한 픽셀당 4바이트를 사용해서 결과적으로 19MB를 차지하게 된다.한두장만 사용해도 장비의 메모리 제한은 가벼웁게 넘어버린다.
- 여러개의 이미지를 한방에 로드하려는 경우가 많다. 예를들어 ListView나 GridView, ViewPager 같은 경우에는 한 화면에 여러개의 이미지를 보여주어야 하고 스크롤에 대비해서 미리 이미지들을 가지고 있어야 되는 경우도 많기 때문이다.
그러면 큰 이미지를 어떻게 로드해서 화면에 보여주는게 효과적일지, 디스크나 인터넷으로 부터 비동기식으로 이미지를 받아와 처리하는 방법, 이미지를 캐싱하는 방법에 대해서 설명하도록 하겠다.
1. 큰 이미지를 (효율적으로)화면에 보여주자.
위에서도 얘기했지만 고해상도의 이미지를 불러와 그대로 메모리에 넣고 화면에 보여주는 것은 바로 OutOfMemory로 가는 지름길이다. 그러면 어떻게 할 것인가. 원래 이미지의 해상도와 상관없이 화면에 보여질 해상도 만큼 줄여서 읽어들이면 되지 않을까? 그러려면 원래 이미지의 해상도와 화면에 보이려는 ImageView의 해상도를 알아내어 품질을 떨어뜨리면 된다.
읽어드리려는 이미지의 해상도를 알아내기 위해서는 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;
이미지를 메모리에 로드하지 않고 크기만 알아내는 코드이다. 여기서 decodeResource 함수는 decodeFile처럼 BitmapFactory.decode* 메소드들로 바꾸어서 쓸 수 있다. 이제 BitmapFactofy.Options의 inSampleSize 파라메터를 이용해서 이미지의 해상도를 줄일 수 있다. inSampleSize는 이미지의 몇분의 1로 해상도를 줄일지를 나타낸다. 예를들어 inSampleSize를 4로 셋팅하면 2048x1536의 이미지를 읽어들일 때 512*384로 1/4크기로 줄여들여 읽어들인다. 자 이제 다음 코드처럼 이미지를 보여줄 화면의 크기만큼 해상도를 떨어뜨려 읽을 수 있다.
// Get the dimensions of the View
int targetW = mImageView.getWidth();
int targetH = mImageView.getHeight();
// Get the dimensions of the bitmap
BitmapFactory.Options bmOptions = new BitmapFactory.Options();
bmOptions.inJustDecodeBounds = true;
BitmapFactory.decodeFile(mCurrentPhotoPath, bmOptions);
int photoW = bmOptions.outWidth;
int photoH = bmOptions.outHeight;
// Determine how much to scale down the image
int scaleFactor = Math.min(photoW/targetW, photoH/targetH);
// Decode the image file into a Bitmap sized to fill the View
bmOptions.inJustDecodeBounds = false;
bmOptions.inSampleSize = scaleFactor;
bmOptions.inPurgeable = true;
Bitmap bitmap = BitmapFactory.decodeFile(mCurrentPhotoPath, bmOptions);
mImageView.setImageBitmap(bitmap);
위와 같이 실제 이미지를 읽어들일 때는 inJustDecodeBounds를 false로 해둔다. inSampleSize의 경우 2의 배수로 사용할 경우 퍼포먼스가 가장 좋긴 하지만 퍼포먼스보다 메모리를 조금이라도 아끼는게 중요하니 2의 배수가 아니더라도 줄일 수 있으면 더 줄이는게 좋다.
2. 멀티 쓰레드로 이미지를 읽어들이자.
이미지를 디스크나 네트워크로 부터 읽어들일 때는 메인 UI 쓰레드에서 읽어들이면 안된다. 시간이 얼마나 걸릴지도 모르는 것이고 마냥 기다리게 되면 사용자가 터치를 해도 반응이 없어서 닫으려고 할 것이기 때문이다. 따라서 이미지를 읽어들이는 작업은 별도의 쓰레드에서 해야 하는데 가장 쉬운 방법은 AsyncTask를 이용하는 것이다.
다음은 AsyncTask를 이용하여 이미지를 읽어들이는 예제이다.
class BitmapWorkerTask extends AsyncTask {
private final WeakReference imageViewReference;
private int data = 0;
public BitmapWorkerTask(ImageView imageView) {
// Use a WeakReference to ensure the ImageView can be garbage collected
imageViewReference = new WeakReference(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);
}
}
}
}별도의 쓰레드에서 진행되므로 작업중에 사용자가 다른창으로 이동하거나 할 수 있다. ImageView의 WeakReference를 가지고 있게하여 사용자가 다른창으로 이동하거나 하면 작업이 끝나지 않았더라도 ImageView가 가비지 콜렉팅되게 하였다. 다만 onPostExcute에서 WeakReference에서 ImageView를 가져와 ImageView가 아직 살아있는지 여부를 체크하게 하였다.
이제 이미지를 별도의 쓰레드에서 비동기식으로 로딩하려면 다음과 같이 실행해주면 된다.
public void loadBitmap(int resId, ImageView imageView) {
BitmapWorkerTask task = new BitmapWorkerTask(imageView);
task.execute(resId);
}일반 뷰에서는 위와 같이 읽어 들이면 되지만 ListView나 GridView에서 사용하게 될 경우 문제가 발생하게 된다. ListView나 GridView는 메모리를 아끼기 위해 유저가 스크롤 하거나 할 때 이미 만들어 놓았던 뷰를 재활용하기 때문이다. 따라서 이미지 로딩 작업이 끝났을 때 업데이트 하려는 뷰가 이미 다른 이미지를 로딩하며 재활용된 뷰일 수도 있고 이미지 로딩이 언제 끝나느냐에 따라서 이미지를 업데이트 하는 작업이 꼬일 수도 있다.
Multithreading for Performance에서는 이 이미지 뷰를 가장 최근에 건드렸던 AsyncTask가 어떤 놈인지 기억해 두었다가 작업이 끝났을 때 그 AsyncTask가 가장 최근놈이 맞는지를 체크하는 방법으로 해결한다. 우리도 비슷한 방법으로 해결해 보자.
아까 만들었던 workertask를 저장할 수 있는 Drawable클래스를 하나 만든다. 이경우에는 ImageView가 가지고 있는 BitmapDrawable을 사용할 거고 따라서 작업이 끝났을 때 ImageView는 자신이 갖고 있는 BitmapDrawable을 통하여 어느 workertask가 가장최근 놈인지 알 수 있다.
static class AsyncDrawable extends BitmapDrawable {
private final WeakReference bitmapWorkerTaskReference;
public AsyncDrawable(Resources res, Bitmap bitmap,
BitmapWorkerTask bitmapWorkerTask) {
super(res, bitmap);
bitmapWorkerTaskReference =
new WeakReference(bitmapWorkerTask);
}
public BitmapWorkerTask getBitmapWorkerTask() {
return bitmapWorkerTaskReference.get();
}
}그리고 BitampWorkerTask를 실행하기 전에, 타겟 ImageView를 가지고 있는 AsyncDrawable을 하나 만들거다.
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);
}
}여기서 cancelPotentialWork 메소드에서 이미 다른 task가 ImageView를 참조하고 있고 돌아가고 있는지를 체크할 수 있다. 그래서 아직 돌고 있는 놈이 있으면 새로운 task를 실행하기 전에 돌고 있는 task를 cancel시켜 버린다. 다음은 cancelPotentialWork의 구현이다.
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;
}위의 코드에서 getBitmapWorkerTask() 메소드는 이 이미지뷰를 업데이트하기 위해 아직 실행중인 task를 리턴하는 메소드이다.
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;
}마지막으로 작업이 끝나면 BitmapWorkTask에서 이미 cancel됐는지 여부를 체크하고 그렇지 않을 때는 업데이트 하도록 한다.
class BitmapWorkerTask extends AsyncTask {
...
@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);
}
}
}
}이제 뷰를 재활용하는 ListView나 GridView에서 있더라도 이 샘플을 사용할 수 있게 되었다. 이제 loadBitmap을 getView()와 같은 곳에서 콜해서 이미지를 로드하면 된다.
3. 이미지를 캐싱하자.
ListView나 GridView, ViewPager에서는 보통 여러장의 이미지를 동시에 로딩하게 된다. 그리고 사용자가 스크롤을 하게 되면 그 중에 화면에 보이지 않게 되는 이미지의 뷰는 재활용 될 것이고, 메모리가 별로 없기 때문에(이것들이 메모리를 많이 차지하는 작업들이라..) 예전에 로딩된 이미지는 곧 가비지 콜렉팅 될 것이다. 그럼 매번 다시 스크롤해서 올라가고 하면 하게 될 때마다 예전에 불렀던 이미지를 새로 다시 로드하고 하게 하는건 네트웍이 느린 안드로이드 폰에서는 뻘짓이다. 그래서 메모리나 디스크에 캐싱하는 방법을 사용한다.
- 메모리 캐시를 사용해보자
안드로이드에서는 LruCache를 제공한다. LruCache는 LinkedHashMap을 사용하여 최근에 사용된 object의 strong reference를 보관하고 있다가 정해진 사이즈를 넘어가게 되면 가장 최근에 사용되지 않은 놈부터 쫓아내는 LRU 알고리즘을 사용하는 메모리 캐시다. 예전에는 bitmap cache에 SoftReference나 WeakReference를 사용하는 방식을 썼으나 안드로이드 2.3부터 가비지 콜렉터가 공격적으로 이놈들의 메모리를 가비지 콜렉팅하면서 몹쓸 방법이 됐다. 게다가 이 방법은 3.0이전 버전에서 메모리 해제를 제대로 못해 크래쉬문제도 있다.
그러니 LruCache를 사용하자. LruCache의 캐시사이즈를 정하기 위해서는 다음 요소들을 고려해야 한다.
- 우리 앱에서 앞으로 메모리를 얼마나 써야 되는가.
- 얼마나 많은 이미지들이 한 화면에 보일 것인가. 얼마나 많은 이미지들이 다음에 보여주기 위해 준비되어야 하는가.
- 화면 해상도가 어떻게 되는가.
- 각 이미지마다 메모리를 얼마나 차지하는가.
- 이미지는 얼마나 자주 액세스 되는가.
- 질보다 양? 양보다 질? 어떤 경우에는 많은 양의 저해상도 이미지를 미리 보여주고 백그라운드로 고해상도 이미지를 로드하는 방법이 좋을 수도 있다.
딱히 어느정도 캐시사이즈가 적당한지 공식은 없고 앱의 메모리 사용량을 측정해보면서 적당히 정해야 한다. 당연한 말이겠지만 너무 사이즈를 작게하면 괜히 오버헤드만 발생하게 되고 사이즈를 너무 크게했다가 OutOfMemory Exception을 보게 될거다. 아래는 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);
}이 예제에서 앱에서 사용하능한 메모리의 1/8을 캐시에 할당하였다. 일반적으로 hdpi 디바이스에서는 이 크기가 4MB(32/8)정도 된다. 800x480이미지가 1.5MB정도 되므로 GridView를 사용한다면 2.5 페이지의 이미지를 메모리에 캐싱할 수 있게 된다.
이미지를 로드할 때 LruCache에서 먼저 찾아보고 있으면 그걸로 바로 업데이트 하고 아니면 백그라운드 쓰레드에서 로딩한다.
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;
}
...
}- 디스크 캐시 이용하기
메모리 캐시는 빠르기는 하지만 메모리가 얼마 되지 않기 때문에 이것만 가지고는 부족하다. 그리고 전화가 오거나 하면 앱이 백그라운드로 가버리면서 캐시가 사라져 버리게 된다. 디스크 캐시를 사용하면 데이터가 지속적으로 남아있고 용량도 좀 더 많이 쓸 수 있다. 하지만 당연히 메모리 캐시보다 느리다. 그래도 네트웍에서 읽어들이는 것에 비하면 어딘가. 그리고 ContentProvider를 사용하는게 자주 액세스 되는 이미지를 캐시에 저장하기에 좋다. 아래 코드는 위의 메모리 캐시에 디스크 캐시를 추가한 버전이다.
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 {
@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 {
...
// 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);
}메모리 캐시에서의 로딩은 메인 쓰레드에서 진행된 반면 디스크 캐시는 백그라운드 로딩을 사용하였다. 디스크 작업은 언제 끝날지 모르므로 백그라운드를 사용하자. 그리고 이미지 프로세싱이 끝나면 메모리 캐시에도 업데이트를 해주었다.
=======================================================
이상입니다. 나머지 부분은 위에서 만든 코드를 실제 GridView나 ViewPager에 적용하는 내용인데 이건 직접 해보시면 될 것 같습니다. 사실 이 부분은 많이 쓰이는 부분이기 때문에 구글에서 검색하면 수많은 오픈소스를 만나실 수 있습니다.
오픈소스를 사용하셔도 되지만 위의 샘플코드를 가져다가 쓰는게 그렇게 어렵지 않고 또 이미 이해한 코드이기 때문에 커스터마이즈 하기도 좀더 수월하지 않을까 싶습니다. 또 위의 내용을 읽다보면 안드로이드가 이미지(비트맵)을 다루는 다양한 방식과 한계에 대해서도 이해하게 되는 부분이 있으리라고 생각합니다. 도움이 되셨길 바랍니다.
