[안드로이드] 메모리 누수 OutOfMemoryError 관련 링크들
원문: http://ecogeo.tistory.com/287
더보기
가끔씩 마주치게 되는 "OutOfMemoryError : bitmap size exceeds VM budget" 에러는 메모리 누수가 주요 원인입니다. 이와 관련된 링크를 모아봤습니다.
* 액티비티가 멈출 때 비트맵을 재활용(즉 GC)되게 하라
http://stackoverflow.com/questions/1949066/java-lang-outofmemoryerror-bitmap-size-exceeds-vm-budget-android
http://stackoverflow.com/questions/2191407/changing-imageview-content-causes-outofmemoryerror
- bitmap 이미지인 경우 recycle() 호출
- onPause에서 수행하는게 좋음
- ((BitmapDrawable)imageView.getDrawable()).getBitmap().recycle();
* 이미지를 미리 줄여서 읽어들여라
http://chiyo85.tistory.com/entry/Android-Bitmap-Object-Resizing-Tip
http://www.memofy.com/memofy/show/1008ab7f2836ab7f01071c2dbfe138/outofmemory-exception-when-decoding-with-bitmapfactory
- BitmapFactory.Options.inSampleSize
* Activity Context에 대한 참조(reference)를 오랫동안 유지하지 말아라
http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html
- 한글 번역 : http://blog.naver.com/huewu/110082062273
- Drawable.setCallback(null) 사용
- WeakReference를 가진 static 내부 클래스
- 이미지를 static 변수로 처리하지 마라
* 외부(outer) 클래스의 상태에 의존하지 않는 내부(inner) 클래스는 static으로 선언하라
- 내부클래스는 외부 클래스 인스턴스를 크게 만들며 또한 외부클래스 객체가 필요이상으로 오래 살아있게 되어 메모리를 더 차지할 수 있다.
- 외부클래스의 상태 필드에 접근하지 않는(즉 외부 객체의 상태에 의존하지 않는) 내부클래스는 static으로 선언한다.
[번역] 안드로이드 메모리릭 회피하기
[출처] [번역] 안드로이드 메모리릭 회피하기|작성자 휴우
더보기
Avoiding Memory Leaks
JAVA 에서도 자원 및 메모리 관리를 개발자가 전혀 신경 쓰지 않아도 되는 것은 아니더군요. 특히 제 경우, 안드로이드 플랫폼에서 Process 생명주기에 대하여 잘 몰라, 어플리케이션이 필요 이상으로 메모리를 사용하곤 했습니다. 안드로이드 개발자 사이트에 안드로이드 상에서 메모리 누수 문제를 피하기 위해 주의해야 할 점에 관해서 짧지만 유용한 글이 있어 번역해 봅니다.
안드로이드 어플리케이션 (최소한 G1 의 경우)은 최대 16MB Heap 메모리 공간을 갖을 수 있다. 이 16MB 라는 공간은 일반적인 폰 어플리케이션에서는 충분히 큰 공간이지만, 보다 다양한 일을 수행하고자 하는 개발자들에게는 부족한 공간일 수도 있다. 또, 비록 개발자가 이 메모리를 모두 사용하지 않더라도, 다른 어플리케이션이 메모리 부족으로 죽지 않고 잘 작동할 수 있도록. 최소한의 공간만을 사용하도록 주의를 기울여야 한다. 안드로이드 플랫폼이 많은 어플리케이션을 메모리 상에 유지할 수 있다면, 사용자들이 어플리케이션을 훨씬 빠르게 변경할 수 있다. (이미 메모리상에 떠있으니까...). 이와 관련하여, 안드로이드 어플리케이션의 메모리릭 문제에 관해 살펴본 결과 많은 경우 메모리릭 문제는 동일한 실수 - Context 에 대한 참조를 오랫동안 유지 하는 것 - 으로 인해 발생하는 것임을 알게 되었다.
안드로이드에서 Context 는 다양한 작업 (주로 리소스를 읽어 오는데) 을 수행하기 위해 사용된다. 때문에 UI 요소들 생성 하는 경우, 항상 Context 를 인자값으로 넘겨 주어야 한다. 안드로이드 어플리케이션 상에서 개발자는 두 종류의 Context 를 사용할 수 있다. 하나는 Activity Context 이고, 다른 하나는 Application Context 이다. 일반적으로 개발자들이 Context 를 클래스 생성 시 혹은 함수 호출 시 인자로 사용하는 경우, 첫번째 Context 를 사용한다.
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
setContentView(label);
}
위 코드에서 TextView 는 Activity 를 참조하고 있다. 다시 말해 Activtiy 와 Activity 에 포함된 그 밖의 다른 요소 - View 전체 적인 계층 구조를 비롯하여, 리소스 요소들에 대한 참조를 유지하고 있다는 뜻이다. 그럼으로, 만일 특정 어플리케이션에서 Context 릭이 발생하게 되면, (Leak 의 의미는 Context 에 관한 참조를 누군가가 계속 유지 하고 있음으로, GC 가 해당 Context 를 Collect 하지 못하게 됨을 의미 한다. ), 큰 공간의 메모리가 누수된다.
간단한 예를 들어보자. 기본적으로, 화면의 가로-세로가 변화되는 경우, 시스템은 상태값만을 유지하고 현재 Activity 를 종료 시킨 후, Activtiy 를 다시 생성한다. 이 과정에서, 해당 Activity의 UI 를 구성하기 위한 리소스를 다시 로드하게 된다. 만일 어떤 개발자가 크기가 큰 비트맵을 사용하는 어플리케이션을 작성했고, 화면이 변경될 때 마다, 해당 비트맵을 다시 로드하지 않기를 바란다고 생각해 보자. 가장 쉬운 방법은 해당 비트맵 자원을 Static 변수로 관리하는 것이다.
private static Drawable sBackground;
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
if (sBackground == null) {
sBackground = getDrawable(R.drawable.large_bitmap);
}
label.setBackgroundDrawable(sBackground);
setContentView(label);
}
이 코드는 매우 빠르게 작동하지만, 매우 잘못되었다. 이 코드 상에서 최초로 생성된 Activity의 Context 릭이 발생한다. 어떠한 Drawable 요소가 View 에 추가될 때, 해당 View 는 Drawable의 Callback 으로 등록 된다. 위의 코드에서, TextView 에 추가된 Drawable(sBackground) 은 TextView 에 대한 참조, 더 나아가 Activity 자체(Context)에 대한 참조를 갖게 된다. (TextView 생성 시 Context 가 인자로 넘어갔음으로...) 따라서, 해당 Static 변수가 살아 있는 동안, 첫번째로 생성된 Activity에서 사용된 메모리 공간은 누수된다.
이 예제는 Context 릭이 발생하는 가장 단순한 예중에 하나이다.이러한 경우를 해결하기 위해 구글 개발자들이 어떤식으로 코드를 작성했는지, HomeScreen Activity 의 소스 코드를 살펴보면 알 수 있다. (unbindDrawables 를 살펴 보라) HomeScreen Activity 가 종료되어 onDestroy 가 호출되는 경우, 저장하고 있는 Drawable 의 Callback 을 모두 null 로 설정해 주었다. 보다 상황이 나쁜 경우, 개발자가 연속적인 Context Leak 을 발생 시킬 수도 있으며, 이럴 경우 사용가능한 메모리 공간은 빠르게 줄어든다.
Context 와 관련된 메모리 누수 문제를 해결 하기 위한 두 가지 쉬운 방법이 있다. 가장 확실한 첫번째 방안은, Context 가 자신의 Scope 외에서는 사용되지 않도록 하는 것이다. 두번째 해결책은 Application Context 를 사용하는 것이다. Application Context 는 Activity 의 생명 주기와는 관계없이. Application과 동일한 생명주기를 갖게된다. 만일 오랫동안 지속되먄서 Context 가 요구되는 객체를 사용하고자 한다면, Application 객체를 기억하라. Context.getApplicationContext() 혹은 Activity.getApplication() 을 호출 하면, Application Context 를 손쉽게 얻을 수 있다.
요역하자면, Context 와 관련된 메모리 누수 문제를 피하고자 할 경우, 다음 사항을 명심해라.
- Activity Context 에 관한 참조를 오랫동안 유지하지 말아라. (해당 참조는 반드시 Activity 의 생명주기와 일치 해야 한다.)
- Activity Context 대신, Application Context 를 사용할 것을 고려하라.
- 만일 Activity 내부 클래스의 생명 주기를 잘 관리하는 경우가 아니라면, Activity 를 참조하고 있는 내부 클래스를 사용하지 말아라. 대신 Static 내부 클래스를 사용하고 해당 클래스가 Activity 와 WeakReference 를 갖도록 해라. 구체적인 구현 방식은 ViewRoot 를 참고 해라.
- 가비지 콜렉터는 메모리 누수 문제가 일어나지 않도록 보장하지 않는다.
[출처] [번역] 안드로이드 메모리릭 회피하기|작성자 휴우