2015.09.20 15:23


안드로이드 앱을 만들 때 가장 많이 하는 일 중에 하나가 사진을 찍어서 올리거나 인터넷에 있는 사진을 받아다 사용자에게 보여주는 일입니다. 스마트폰이 가진 중요한 기능 중의 하나가 카메라가 내장되어 있다는 것이고 이것이 인터넷과 연결되어 다른 사용자들에게 쉽게 공유할 수 있다는 것이기 때문이죠. 그래서 모바일 앱의 주요 컨텐츠 생산이나 소비 형태도 사진으로 많이 이루어져 있습니다.

드로이드 개발자 공식 사이트에서도 상당히 앞쪽 부분에 사진을 다루는 비트맵에 대한 트레이닝 세션을 만들어 놓았습니다. 공부차 공식 사이트의 내용을 간단히 추려서 옮겨 봅니다. 원문과 샘플코드 다운로드는 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크기로 줄여들여 읽어들인다.(면적은 1/16로) 자 이제 다음 코드처럼 이미지를 보여줄 화면의 크기만큼 해상도를 떨어뜨려 읽을 수 있다. 

 // 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에 적용하는 내용인데 이건 직접 해보시면 될 것 같습니다. 사실 이 부분은 많이 쓰이는 부분이기 때문에 구글에서 검색하면 수많은 오픈소스를 만나실 수 있습니다.

오픈소스를 사용하셔도 되지만 위의 샘플코드를 가져다가 쓰는게 그렇게 어렵지 않고 또 이미 이해한 코드이기 때문에  커스터마이즈 하기도 좀더 수월하지 않을까 싶습니다. 또 위의 내용을 읽다보면 안드로이드가 이미지(비트맵)을 다루는 다양한 방식과 한계에 대해서도 이해하게 되는 부분이 있으리라고 생각합니다. 도움이 되셨길 바랍니다.

신고


Posted by injunech
2015.09.13 00:41


[Intro]

 

Android에서 사용하는 이미지는 Bitmap이라는 클래스에서 다~ 알아서 해줍니다.
그리고 이런 Bitmap Object를 쉽게 만들 수 있도록 도와주는 
BitmapFactory 클래스 라는 것도 있습니다.

 

BitmapFactory는 여러가지 소스로 부터 Bitmap Object를 만들어 주는 일을 하는데,
전부 static이며 decodeXXX 라는 이름을 가진 메소드들로 이루어져 있습니다.

XXX에는 어떤 것으로 부터 decode를 하여 
Bitmap Object를 만들어 낼지에 대한 말들이 들어 가겠죠.

 


[Decoding Methods]

 

BitmapFactory.decodeByteArray() 메소드는 Camera.PictureCallback 으로 부터 받은
Jpeg 사진 데이터를 가지고 Bitmap으로 만들어 줄 때 많이 사용 합니다.
Camera.PictureCallback에서 들어오는 데이터가 byte[] 형식이기 때문에
저 메소드를 사용 해야 하는 것이죠.

 

BitmapFactory.decodeFile() 메소드는 파일을 그대로 읽어 옵니다.
내부적으로는 파일 경로를 가지고 FileInputStream을 만들어서 decodeStream을 합니다.
그냥 파일 경로만 쓰면 다 해주는게 편리 한 것이죠.

 

BitmapFactory.decodeResource() 메소드는 Resource로 부터 Bitmap을 만들어 내며
BitmapFactory.decodeStream() 메소드는 InputStream으로 부터 Bitmap을 만들어 냅니다.
뭐 그냥 이름만 봐도 알 수 있는 것들이지요.

 


[OutOfMemoryError??]

 

보통 이미지 파일을 읽어서 Resizing을 해야 할 때가 있는데, 
그럴때는 BitmapFactory로 읽어서 Bitmap.createScaledBitmap() 메소드를 사용하여 줄이면

간단하게 처리 할 수 있습니다.

 

그런데 BitmapFactory를 사용할 때 주의해야 할 점이 있습니다.
아래의 예를 한번 보시죠.

Bitmap src = BitmapFactory.decodeFile("/sdcard/image.jpg");
Bitmap resized = Bitmap.createScaledBitmap(src, dstWidth, dstHeight, true);

이미지 파일로부터 Bitmap을 만든 다음에

다시 dstWidth, dstHeight 만큼 줄여서 resized 라는 Bitmap을 만들어 냈습니다.
보통이라면 저렇게 하는게 맞습니다.

 

읽어서, 줄인다.

 

그런데 만약 이미지 파일의 크기가 아주 크다면 어떻게 될까요?
지금 Dev Phone에서 카메라로 촬영하면
기본적으로 2048 x 1536 크기의 Jpeg 이미지가 촬영된 데이터로 넘어옵니다.
이것을 decode 하려면 3MB 정도의 메모리가 필요 할 텐데,

과연 어떤 모바일 디바이스에서 얼마나 처리 할 수 있을까요?

 

실제로 촬영된 Jpeg 이미지를 여러번 decoding 하다보면

아래와 같은 황당한 메세지를 발견 할 수 있습니다.

java.lang.OutOfMemoryError: bitmap size exceeds VM budget

네... OutOfMemory 입니다.
더 이상 무슨 말이 필요 하겠습니까...
메모리가 딸려서 처리를 제대로 못합니다.

 

이것이 실제로 decoding 후 메모리 해제가 제대로 되지 않아서 그런 것인지, 
하더라도 어디서 Leak이 발생 하는지에 대한 정확한 원인은 알 수 없습니다.
이것은 엔지니어들이 해결해야 할 문제 겠죠...

 

하지만 메모리 에러를 피할 수 있는 방법이 있습니다.

 


[BitmapFactory.Options.inSampleSize]

 

BitmapFactory.decodeXXX 시리즈는 똑같은 메소드가 두 개씩 오버로딩 되어 있습니다.
같은 이름이지만 Signature가 다른 메소드의 차이점은
BitmapFactory.Options를 파라메터로 받느냐 안받느냐의 차이죠.

BitmapFactory.Options를 사용하게 되면 decode 할 때 여러가지 옵션을 줄 수 있습니다.


여러가지 많지만 저희가 지금 사용할 것은 inSampleSize 옵션 입니다.

 

inSampleSize 옵션은,
애초에 decode를 할 때 얼마만큼 줄여서 decoding을 할 지 정하는 옵션 입니다.

 

inSampleSize 옵션은 1보다 작은 값일때는 무조건 1로 세팅이 되며,
1보다 큰 값, N일때는 1/N 만큼 이미지를 줄여서 decoding 하게 됩니다.
즉 inSampleSize가 4라면 1/4 만큼 이미지를 줄여서 decoding 해서 Bitmap으로 만들게 되는 것이죠.

 

2의 지수만큼 비례할 때 가장 빠르다고 합니다.
2, 4, 8, 16... 정도 되겠죠?

 

그래서 만약 내가 줄이고자 하는 이미지가 1/4보다는 작고 1/8보다는 클 때,
inSampleSize 옵션에 4를 주어서 decoding 한 다음에,

Bitmap.createScaledBitmap() 메소드를 사용하여 한번 더 줄이면 됩니다.

BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 4;
Bitmap src = BitmapFactory.decodeFile("/sdcard/image.jpg", options);
Bitmap resized = Bitmap.createScaledBitmap(src, dstWidth, dstHeight, true);

당연한 이야기 이겠지만,
내가 원하고자 하는 사이즈가 딱 1/4 크기라면

Bitmap.createScaledBitmap() 메소드를 쓸 필요가 없지요.

 

inSampleSize 옵션을 잘 활용하면 메모리 부족 현상을 대략적으로 해소 할 수 있습니다.
참고로 제가 저 옵션을 사용한 뒤로는 메모리 에러를 본적이 한~번도 없답니다.

 


[Appendix]

 

inSampleSize 옵션을 사용하면

SkScaledBitmapSampler Object (Library Level) 를 생성 하게 되는데,
Object를 만들때 정해진 SampleSize 만큼 축소하여 width와 height를 정한 뒤에 만들게 됩니다.
그러니까 애초에 축소된 사이즈로 이미지를 decoding 하는 것이죠.

 


[Outro]

 

Android의 기본 어플리케이션 소스를 분석 하다보면
상당히 테크니컬한 기법들을 많이 얻을 수 있습니다.
어떻게 이런 방법으로 만들었나 싶을 정도로 매우 정교하고 복잡하게 만들어져 있지요.
참 대단한 것 같습니다.





출처 - http://blog.naver.com/visualc98

신고


Posted by injunech
2015.09.08 02:24


안드로이드 앱을 만들때 배경이미지를 넣어야 하는 경우 OutOfMemoryError에 직면하는 경우가 많다.. 


특히 사이즈가 큰 배경이미지 일수록... 자주 발생한다...


즉, OutOfMemoryError는 이름처럼 이미지를 로딩할때 메모리가 부족해서 발생하는것이다...


이럴경우 그원인이 되는 이미지 사이즈 자체를 줄이거나 로딩할때 아래와 같이 사이즈를 줄여서 불러오면 일단 해결은 된다.



 


BitmapFactory.Options options = new BitmapFactory.Options();

options.inSampleSize = 2;


Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.drawable.opening, options);





하지만 이방법은 치명적 단점이 있다.


사이즈를 줄이므로 이미지가 선명하지 못하고 깨져서 보이며, 보통 LinearLayout과 같은 배경으로 많이 쓰이는 view에는 setBackgroundDrawable() 뿐이라서 bitmap을 Drawable로 변환해야 하는 번거로움이 있다...


이 두가지 단점을 한번에 해결하는 방법은 과연 없을까?


있다. 나도 항상 위와 같은 방법을 쓰다가 영 마음에 안들어서 여러 테스트를 거쳐 알아냈다...

물론 나중에 안거지만 다른분들 포스팅을 보니 이미 그렇게 사용하고 계시는 분들이 있으셨다..

역시 세상에는 코딩신님들이 많은것 같다ㅎㅎ 난 무한 샆질끝에 알아냈다고 좋아했는데ㅎㅎㅎ


방법은 무지 간단하다...





LinearLayout layout = (LinearLayout)findViewById(R.id.BgLayout);


layout.setBackgroundDrawable(new BitmapDrawable(getResources(), BitmapFactory.decodeResource(getResources(), R.drawable.opening)));





이렇게 로딩을 해서 바로 집어넣고 onDestroy()에서 메모리를 풀어주면 된다...





@Override

public void onDestroy() {

recycleView(findViewById(R.id.BgLayout));

}


private void recycleView(View view) {

if(view != null) {

Drawable bg = view.getBackground();

if(bg != null) {

bg.setCallback(null);

((BitmapDrawable)bg).getBitmap().recycle();

view.setBackgroundDrawable(null);

}

}

    }





참고로


xml에서 android:background="@drawable/opening" 로 바로 넣거나 layout.setBackgroundResource(R.drawable.opening) 또는  getResources().getDrawable(R.drawable.opening) 로 이미지를 가져오면 원본을 그대로 사용하는것이라서 메모리도 많이 잡아먹고 recycle를 하게 되면 다음번 실행때 에러가 난다...


결론은...


반드시 위와 같이 new로 복사본을 새로 생성해서 사용해야 메모리도 적게 먹고 recycle도 할수 있어서 OutOfMemoryError를 예방할 수 있다....






출처 : http://gyjmobile.tistory.com/

신고


Posted by injunech
2015.06.08 23:57


리소스 접근시 여러가지 방법이 있겠지만

Bitmap testImg = BitmapFactory.decodeResource(res, R.drawable.testRes0);

이런식으로 파일 ID로 리소스를 읽어와 사용하고 있었습니다.
그런데 리소스가 많을 경우 

testImg = new Bitmap[10];
for(int i = 0; i < 10; i++)
        testImg[i] = BitmapFactory.decodeResource(res, R.drawable.testRes0+i);

이런식으로 ID로 연산을 하여 읽어오다보면 ID가 꼬이는 경우 문제가 발생할 여지가 많더군요.
파일명이 순차적으로 되어 있다고 하더라도 이런식의 접근은 안좋은 방법인것으로 알고 있습니다.

이럴경우

int tmpID;
testImg = new Bitmap[10];
for(int i = 0; i < 10; i++)
{
       tmpID = res.getIdentifier( "testRes"+i, "drawable" , "com.androidpub.android.test");
       testImg[i] = BitmapFactory.decodeResource(res, tmpID);
}

이런식으로 리소스 파일명으로 ID를 알아와 접근하는 방식을 사용할 수 있습니다.

"패키지명 : 타입 / 리소스명", null, null
getIdentifier("com.androidpub.android.test:drawable/testRes", null, null);

또는

"리소스명", "타입", "패키지명"
getIdentifier("testRes", "drawable", "com.androidpub.android.test");

---------------------------------------------------------------------------


문자열로 해당 Resource (혹은 레이아웃에 포함된 View) 의 ID 값을 가져온다;

-----------------------------------------------------------------
getResources().getIdentifier(파일명디렉토리명패키지명);
또는,
getResources().getIdentifier(패키지명:디렉토리/파일명nullnull);
으로도 가능하다.
-----------------------------------------------------------------

String resName = "@drawable/imgEnd";
String packName = this.getPackageName(); // 패키지명
int resID = getResources().getIdentifier(resName, "drawable", packName);

String viewName = "imgViewEnd";
String packName = this.getPackageName(); // 패키지명
int resID = getResources().getIdentifier(resName, "id", packName);


주로 리소스/ 뷰의 이름을 조합형식으로 만들어 가져와야 할 경우에
이 같은 코드를 사용하여 처리할 수 있다.


예를 들어,

for (int i=0; i < 3; i++) {
    String resName = "@drawable/img_" + i;
    // 결론적으로 이미지 리소스 이름은 img_1, img_2, img_3 이 되겠다;
    int resID = getResources().getIdentifier(resName, "drawable", packName);

    ImageView iv = (ImageView)findViewById(R.id.imgView);
    iv.setImageResource(resID); // 이미지뷰의 이미지를 설정한다;
}

이렇게 사용이 가능하다.

신고


Posted by injunech

티스토리 툴바