2017.02.19 01:07


Color 지정방법에 대한 다양한 방법 소개


You can use various functions from the Color class to get the same effect of course.

  • holder.text.setTextColor(Color.RED);

  • Color.parseColor (Manual) (like LEX uses)

    text.setTextColor(Color.parseColor("#FFFFFF"));
  • Color.rgb and Color.argb (Manual rgb) (Manual argb) (like Ganapathy uses)

    holder.text.setTextColor(Color.rgb(200,0,0));
    holder.text.setTextColor(Color.argb(0,200,0,0));
  • And of course, if you want to define your color in an XML file, you can do this:

    <color name="errorColor">#f00</color>

    because the getColor() function is deprecated1, you need to use it like so:

    ContextCompat.getColor(context, R.color.your_color);
  • You can also insert plain HEX, like so:

    myTextView.setTextColor(0xAARRGGBB);

    Where you have an alpha-channel first, then the color value.

Check out the complete manual of course, public class Color extends Object.


https://developer.android.com/reference/android/graphics/Color.html#parseColor(java.lang.String)



저작자 표시
신고


Posted by injunech
2016.09.23 01:26


ListView를 보시면 화면을 터치한 후 드래그하는 속도에 따라 ListView의 스크롤링 속도가 변하는 것을 볼 수 있습니다. 천천히 하면 스크롤도 천천히 되고 빠르게 드래그하면 바퀴 돌 듯이 ListView가 스크롤 되지요. 이런 효과는 어떻게 구현될 수 있을까요? 안드로이드에서 제공하는 클래스를 통해 쉽게 구현할 수 있습니다. 다음의 코드를 보시죠.


public class MyOnTouchListener implements OnTouchListener {

    private VelocityTracker mVelocityTracker;

    public boolean onTouch(View v, MotionEvent event) {

        if (mVelocityTracker == null) {

            mVelocityTracker = VelocityTracker.obtain();

        }

        mVelocityTracker.addMovement(event);


        switch (event.getAction()) { 

        case MotionEvent.ACTION_DOWN:

            Log.v(TAG"ACTION_DOWN");

            break



        case MotionEvent.ACTION_MOVE:

            Log.v(TAG"ACTION_MOVE");

            mVelocityTracker.computeCurrentVelocity(1);

            float velocity = mVelocityTracker.getXVelocity();

            break


        case MotionEvent.ACTION_UP:

            Log.v(TAG"ACTION_UP");

            if (mVelocityTracker != null) {

                mVelocityTracker.recycle();

                mVelocityTracker = null;

            }

            break

        } 

        return true;

    }

}


요점은 VelocityTracker가 드래그의 속도를 측정해준다는 것입니다. 위의 예제에서는 VelocityTracker의 5가지 메소드가 사용되었습니다.

1. obtain()
   이것은 정적 메소드입니다. VelocityTracker의 인스턴스를 구하기 위한 팩토리 메소드입니다.
2. addMovement(MotionEvent e)
   속도를 측정하기 위해서 VelocityTracker 인스턴스에 MotionEvent를 입력합니다.
3. computeCurrentVelocity(int unit)
   입력된 데이타를 기반으로 속도를 측정합니다. unit은 측정 시간 단위이며 1은 1밀리초를, 1000은 1초를 의미합니다. 다시 말해 unit이 1이라면 1밀리초동안의 픽셀단위의 이동 거리를 측정합니다.
4. getXVelocity()
   X축으로의 속도를 구합니다. Y축으로의 속도는 getYVelocity()를 사용하면 됩니다. 
5. recycle()
   객체를 재사용할 수 있도록 초기화 합니다.
   드래깅 속도 측정은 빈번하게 일어나는 연산입니다. 하지만 이를 위해서 각각의 OnTouchListener가 VelocityTracker의 인스턴스를 하나씩 점유하는 것은 분명 낭비입니다.(안드로이드는 임베디드 시스템을 위한 운영체제임!) 따라서 VelocityTracker 객체의 생성은 팩토리 메소드에 위임하고 객체는 사용 후 반환합니다. 그러면 결과적으로 VelocityTracker 객체 하나가 모든 드래깅 동작에 공유되어 사용될 수 있습니다. 




출처 : http://anddev.tistory.com/16


신고


Posted by injunech
2016.09.14 01:20



# String to Int



 int numInt = Integer.parseInt(numStr);


 


# Int to String



 String numStr2 = String.valueOf(numInt);
 

신고


Posted by injunech
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
2015.04.05 15:06


배경 : 
 안드로이드 앱을 등록할때, 2.2~ 2.3 버전별 앱과
 4.0 이상의 버전에 대한 앱을 만들고,
 이를 같은 배포 버전인 1.1로 하여 사용자에 따라 해당 앱을 다운로드 받게 하기 위함.

방법 :
 SDK버전별 앱을 두개를 만들고,
 각 배포 버전으로 똑같이 한다.
 단, 버전 코드를 다르게 해야 마켓에 동시에 활성화를 시킬수 있다.
 따라서 버전코드는 다르게 하고, 버전은 똑같이하여 APK 만들어서 마켓에 올린 후, 둘다 활성화 시킨다. 
 예) 2.2~2.3 용 : 버전코드 1, 버전 1.1
      4.0 ~     용 : 버전코드 2, 버전 1.1

신고

'Operating System > Android' 카테고리의 다른 글

Android Market SDK버전별 어플 등록하기  (0) 2015.04.05


Posted by injunech
2015.03.20 11:10


아이폰과 안드로이드의 속도 경쟁은 결국 32bit와 64bit 운영체제의 논쟁으로까지 번지는 형국이다. 하지만 그 싸움에서 안드로이드 진영은 애플을 이길 수 없다. 그 이유는 안드로이드의 앱 구동 체계의 구조적 문제 때문이다.


안드로이드는 리눅스 운영체제의 일종이면서도 사용자가 사용하는 앱은 모두 Java 언어로 개발된다. Java로 개발된 앱의 소스파일은 바이트 코드로 컴파일되기 때문에 운영체제가 직접 실행하는 것이 불가능하다. 왜냐하면 Java에서 컴파일된 바이트코드는 java Run-time 이라고 하는 실행환경(가상의 운영체제)에서만 읽고 해석(Just-In-Time 컴파일)이 가능하기 때문이다. 그리고 이러한 역할을 수행하는 것이 안드로이드에서 지원하는 앱구동 환경인 달빅(Dalvik)이다.


하지만 iOS는 앱이 기계어로 컴파일되어 저장소에 파일로 저장되어 있다가 사용자가 앱을 실행하면 곧바로 메모리에 올려져 운영체제에 의해 실행된다. 즉 안드로이드 처럼 앱과 운영체제의 중간에 존재하는 달빅과 같은 JIT 컴파일러가 필요없다. 이런 차이점은 바로 안드로이드의 앱 개발환경이 Java 이고 iOS의 앱 개발환경이 Object-C라고 불리는 C언어 환경이기 때문에 발생하는 차이다. iOS의 오브젝트C는 C언어로 작성된 앱의 소스파일을 아이폰의 운영체제인 iOS가 직접 읽어 메모리에 적재(loading)하고 곧바로 실행할 수 있도록 기계어코드(목적코드 혹은 Object-Code)로 만들어 저장소에 저장된다.


이 두가지 앱 구동 환경을 이해하기 쉽게 표시하면 아래그림과 같다.





간단한 그림의 표현만으로도 "안드로이드 스마트폰이 메모리도 더 크고 CPU도 더 빠른데 왜 아이폰보다 느린지"를 이해할 수 있을 것이다.


안드로이드와 애플의 64bit 전쟁.


앞에서 살펴본 스마트폰의 운영체제와 앱구동환경의 차이로 인해 최근 논란이 되고 있는 64bit 지원 논쟁에서 애플은 64bit 지원에 대해 자신감을 보이고 있는 반면 안드로이드를 만드는 구글은 멈칫하며 주저하는 미묘한 입장차이를 보이고 있기도 하다.


애플은 iOS와 오브젝트C 개발환경 그리고 CPU까지 모두 스스로 만들고 있으며 64bit CPU (AP : Application Processor라고도 부름)개발과 64bit iOS개발, 그리고 64bit 오브젝트C의 개발이 모두 하나의 작업처럼 진행될 수 있기 때문에 현재의 기술로서 64bit를 지원하는 것은 그리 어려운 일이 아니다. 게다가 32bit 오브젝트C로 개발된 앱의 64bit 포팅도 충분히 가능하다.


하지만 구글의 입장은 매우 복잡하다. 


리눅스 운영체제부터 64bit로 전환해야 하고 그 위에서 구동되는 Java는 Oracle에서 만들고 있으며 앱의 개발환경은 또 다른 곳에서 개발되고 있고 앱의 구동환경인 달빅의 64bit 포팅도 여러가지 문제로 인해 쉽지 않은 입장이다. 


여러 자유(?)진영의 합작품인 안드로이드가 64bit 지원이라는 복병을 만나 잠시 주춤하는 모습을 보이고 있다. 어찌보면 구글은 아이폰의 대항마였던 안드로이드를 만들면서 가장 쉬운길이었던 두가지의 선택, 즉 운영체제로서 리눅스를 선택한 것과 개발환경 및 앱 운영환경으로 가장 범용적이고 많은 개발자를 확보할 수 있었던 Java를 선택한 댓가를 64bit 환경의 지원이라는 과제 앞에서 치르고 있는지도 모르겠다.


어쩌면 구글은 64bit 문제로 인해 장기적으로는 안드로이드를 버리는 계획을 내부적으로 수립하고 있을지도 모른다. 그리고 그 대안으로 크롬(Chrome) OS를 밀어줄 것이 확실시 된다.


Dalvik vs ART(Android Run-time)


하지만 구글은 당장 안드로이드를 버릴 수 없기 때문에 현실적인 판단을 할 수 밖에 없다. 그 결과로서 구글은 안드로이드의 앱 구동에 대한 부정적인 이미지를 벗기위해 성능개선에 매달렸고 새로운 앱 구동환경 즉 런타임환경을 새롭게 만들었다.


구글은 최근에 출시한 넥서스5에서 Dalvik을 대체할 새로운 앱의 구동환경으로 내놓은 ART가 그것이다. 보다 빠른 앱의 구동을 지원하는 ART는 이 포스트를 올리는 현재시간 기준으로 넥서스5에서만 사용이 가능하다.



구글이 나름대로 안드로이드의 성능개선을 위해 많은 노력을 하고있긴 하지만 언제까지 지원을 아끼지 않을지는 알 수 없다. 그리고 "리눅스-Java-앱"의 3계층 구조 자체를 뜯어고치지 않는 이상 아이폰의 성능을 쫒아가는 것은 거의 불가능하다고 보여진다.  하지만 그러기엔 너무 먼길을 왔다. 아마도 그래서 구글이 크롬을 밀어줄 것 같다는 생각은 더욱 확실해진다.

신고

'Life > IT' 카테고리의 다른 글

Gear S3 Design  (0) 2017.05.29
Gear S3 시계화면 추천  (0) 2016.12.16
[앱추천] 촛불시위 어플  (0) 2016.11.29
기어 S3 프론티어 개봉&리뷰  (0) 2016.11.16
안드로이드와 아이폰 앱 실행 속도 비교  (0) 2015.03.20


Posted by injunech
2015.02.25 23:07


Android ACTIVITY 전환시 액티비티의 History 관련 설정

일반적인 경우, 안드로이드 용 어플리케이션을 작성하게 되면 여러가지 Activity 들을 생성하게 됩니다. 이때, 가장 골치가 아픈 일 중 하나는 바로 Activity 와 Activity 간의 Flow 를 설계하고 이를 적절하게 구현하는 일입니다. (특히 안드로이드를 사용해보지도 않은 UX 팀과 함께 일하게 되는 경우라면 더욱 그러합니다...)

 기본적으로 안드로이드 플랫폼 상에서 Activity 는 또 다른 Activity 를 시작할 수 있고, 각각의 Activity 는 차곡 차곡 Task 라고 불리우는 Activity Stack 에 쌓이게 됩니다. 사용자는 일반적으로 Back 버튼을 이용해서 현재 화면상에 보이는 Activity 를 종료 시키고, 바로 직전에 사용된 Activity 로 돌아갈 수 있습니다. 안드로이드 펍의 회색님의 말을 빌리자면, 인터넷 브라우저를 통해 웹페이지를 검색하는 것과 유사한 방식입니다. 

 하지만 이러한 방법만으로는 효과적인 UX Flow 를 구축하는데 어려움이있습니다. 다행히, 구글에서는 Activity 를 호출할 때 사용되는 Intent 에 적절한 플래그 값을 설정해서 Activity Stack 을 제어할 수 있는 방법을 제공해 줍니다. 이 플래그들은  FLAG_ACTIVITY 라는 접두어를 갖고 있는데, 종류가 다양해 헷갈리는 수도 있는데, 개인적으로 제가 가장 요긴하게 사용하고 있는 FLAG_ACTIVITY 네 가지를 소개해 봅니다. 

 먼저 FLAG_ACTIVITY_SINGLE_TOP 입니다. 우선 간단하게 그림으로 표현해 보았습니다. A 와 B  두 가지 Activity 가 있는 데, A 라는 Activity 는 B 를 B 라는 Activity 는 다시 자기 자신인 B 를 호출 하는 경우라고 가정해 보겠습니다. 


 호출하는 Activity B 가 이미 Task 의 가장 앞에 위치하는 경우, 또 하나의 B 를 생성하는 대신, 기존에 존재하는 B Activity 가 재활용됩니다. 이 때 B 가 재활용된다는 것을 개발자가 알아채고 새롭게 전달되는 Intent 를 사용할 수 있도록 B Activity 의 onPause() / onNewIntent() / onResume() 가 순차적으로 호출됩니다. 별 생각없이 동일한 Activity 를 여러번 생성하는 것은 메모리 사용량과 Activity 시작 속도 양쪽 모두에 악영향을 끼칠 수 있습니다. (특히 이미지가 덕지덕지 붙어 있는 Activity 라면). 이런 경우 FLAG_ACTIVITY_SINGLE_TOP 를 적절하게 활용하면 제법 큰 효과를 볼 수 있습니다.


 두 번째는, FLAG_ACTIVITY_NO_HISTORY 플래그입니다. 우선 간단하게 그림으로 표현해 보았습니다. A 와 B  두 가지 Activity 가 있는 데, A 라는 Activity 는 B 를 B 라는 Activity 는 A 를 호출한 후 에 (A->B->A) 사용자가 Back 키를 누르는 경우를 가정해 보겠습니다.


 말 그대로, FLAG_ACTIVITY_NO_HISTORY 로 설정된 Intent 로 시작된 Activity B 는 Task 에 그 흔적을 남기지 않게 됩니다. B 에서 또다른 A 를 시작한 후, Back 을 누르면 일반적인 경우 이전에 실행되었던 B 가 나타나지만, NO_HISTORY 를 사용하는 경우 맨 처음에 실행 되었던 A 가 화면에 표시됩니다. 몇 가지 주의할 점이 있습니다. 우선 NO_HISTORY 를 사용하게 되면 Task 에 해당 Intent 의 정보가 기록되지 않기 때문에, A->B 인 상황 (그림에서 두 번째 단계...) 에서 홈키등을 눌러 다른 Task 로 전환된 후, 다시 본 Task 로 돌아오게 되면, A Activity 가 화면에 표시됩니다. 또한, B Activity 의 onDestroy() 가 호출되는 시점이 조금 애매합니다.일반적인 예상과는 달리, B 에서 또다른 A Activity 를 호출하는 세 번째 단계에서는 onStop 까지만 호출되고, 이 후에 새롭게 호출된 A Activity 가 사라지는 순간 (네 번째 단계) 에서야 onDestroy() 가 호출 됩니다.

 FLAG_ACTIVITY_NO_HISTORY 는 여러가지로 쓸모가 있는데, 특히 특정한 이벤트에 대한 알람등을 위해 다이얼로그 형태로 화면에 표시되는 Activity 들에 적용하기에 편리합니다. (대게의 경우 팝업은 해당 시점에 한번만 보여주면 되니까.)

 다음으로 굉장히 유용한 플래그 두 가지를 동시에 설명해보고자 합니다.FLAG_ACTIVITY_REORDER_TO_FRONT 와 FLAG_ACTIVITY_CLEAR_TOP 플래그입니다. 우선 간략하게 그림으로 살펴 보겠습니다. A Activity 에서 B Activity 를 그리고 B 에서 A 를 호출하는 상황을 가정해보았습니다. (A->B->A)


 FLAG_ACTIVITY_REORDER_TO_FRONT 는 매우 특이하게도 Task 의 순서 자체를 뒤바꿔 줍니다. 이 플래그를 사용하면, 런치하고자 하는 Activity 가 이미 Task 상에 존재하는 경우 해당 Activity 를 새롭게 생성하는 대신, 아래쪽에 위치한 Activity 의 순서를 Task 의 가장 위로 끌어올려줍니다. 따라서 A->B->A 의 순서로 Activity 호출이 일어날때, 새로운 A 가 생성되는 대신 아래쪽에 위치한 A 가 위로 올라와 최종적으로 B->A 의 형태로 Task 가 구성되게 됩니다. 어떤 Activity 에서 특정 Activity 로 점프하는 형식의 Flow 를 구성해야하는 경우 요긴하게 사용될 수도 있지만, Task 의 순서를 뒤섞는 다는 점에서 사용에 주의를 기울일 필요가 있습니다.  (별 생각없이 남발하게 되면 Back 키가를 누를 때 엉뚱한 Activity 가 표시되어 사용자들이 굉장히 혼란스러워 하는 경우가 있습니다.) 

 마지막으로 소개해 드릴 플래그는 바로 FLAG_ACTIVITY_CLEAR_TOP 입니다. 제가 개인적으로 가장 사랑스럽게 생각하는 녀석입니다. 이 플래그가 사용되는 경우  
런치하고자 하는 Activity 가 이미 Task 상에 존재하는 경우, 해당 Activity 위에 존재하는 다른 Activity 를 모두 종료시켜 줍니다. 따라서 A->B->A 로 호출이 일어나는 경우, B Activity 가 종료 되고, A Activity 만 Task 에 남게 됩니다. (A->B->C->A 인 경우에도 마찬가지로 B와 C 가 종료되고 A 만 남게 됩니다.)

  이 Flag 는 특정 어플리케이션의 대쉬보드 (혹은 홈) Activity 를 호출할 때 굉장히 유용하게 사용될 수 있습니다. 즉 하나의 어플리케이션이 하나 혹은 두 가지의 주요한 Activity 와 그 외 특정 값을 선택하는등 단순한 일을 수행하기 위한 여러 개의 Sub-Activity 로 구성되어 있다면, 주요 Activity 를 호출하는데 이 Flag 를 사용함으로서 어플리케이션의 홈버튼등을 손쉽게 구현할 수 있습니다. 또 이 Flag 는 FLAG_ACTIVITY_REORDER_TO_FRONT 와는 달린 Task 의 순서를 뒤섞지 않음으로 사용자에게도 큰 혼란을 주지 않습니다. (사용을 적극 권장합니다.)

 한 가지 주의해야할 점은 A->B->A 형태로 Activity 를 호출 하고자 할 때, 단순히 FLAG_ACTIVITY_CLEAR_TOP 만을 사용하게 되면, 기존에 생성되었던 A Activity 가 종료된 후 (onDestroy() 가 호출됨) 새롭게 A 가 생성 (onCreate()) 됩니다. 만일 기존에 사용된 A Activity 가 계속 사용되기를 원한다면, SINGLE_TOP 플래그와 함께 사용해야 합니다.





신고


Posted by injunech

티스토리 툴바