앱 개발을 하고, 출시를 준비하면서 QA를 하다보면, MemoryLeak과 마주하게 되는데요.

오늘은 안드로이드 개발을 하면서 생기는 MemeoryLeak에 대해서 정리해 보겠습니다.



1. Memory Leak 


모든 앱은 작업을 수행하는데 필요한 리소스로 메모리가 필요합니다. Android의 각 앱에 충분한 메모리가 있는지 확인하려면 Android 시스템에서 메모리 할당을 효율적으로 관리해야 합니다. Android 런타임은 메모리가 부족한 경우 가비지 수집(GC)을 트리거합니다. GC의 목적은 더 이상 유용하지 않은 객체를 정리하여 메모리를 회수하는 것입니다



Android는 메모리가 부족해지면 가비지 콜렉팅(Garbage Collect = G.C.)을 합니다. 줄여서 GC라고 부르겠습니다.

GC를 하면, 더 이상 사용되지 않는 객체(object)를 정리해서 메모리를 확보해줍니다.


그런데, 더 이상 사용되지 않는 객체를 다른 객체가 참조하게 되는 경우 어떻게 될까요?

필요하지 않는 객체를 참조한 A객체를 다시, B객체가 참조하게 된다면 더욱 심각한 문제가 생길것이라는 걸 예상하실 수 있겠죠.



2. Memory Leak의 문제 


구체적으로 어떤 문제가 생길까요?

필요하지 않은 객체가 다른 객체에 의해 참조, 즉 레퍼런스를 자기게 된다면, 

GC는 유용한 객체로 보고, 정리를 하지 않게 됩니다.


안드로이드에서는, 필요하지 않는 객체가 액티비티의 레퍼런스를 가지고 있다면,

액티비티도 Memory leak이 생기게 되는 거죠.



계속해서 필요하지 않은 객체가 한정정인 메모리 공간을 차지하게 되구요.

이는 GC를 더욱 자주 활성화 시킵니다.

메모리 공간이 부족하니 더욱 자주 정리해 주어야 하기 때문인데요.

GC를 하는 것 자체가 상당한 부담이 됩니다.

모바일에서의 생명인 사용자 반응까지도 멈추게 할 수 있으니,

ANR에러까지도 불러올 수 있게되는 거죠.


심지어 아래와 같이 시스템에서 경고장을 받는 앱이 될수 있구요.

(사용자에게 굉장히 않좋은 인식을 심어주겠지요)

종국에 가서는 시스템이 앱을 강제종료하는 상황에 이를텐데요.

사용자들은 이런앱을 결코 계속 사용하지 않을 것입니다.




2. Memory Leak 방지


2-1. Activity를 참조하는 객체를 오랫동안 방치하지 말것

2-2. context-application보다는  context-activity

2-3. GC를 밎지말라.





2. Memory Leak 대응


2-1. LeakCanary


Square 사에서 만든 라이브러리입니다.

아래 링크에서 라이브러리 설치 방법을 확인할 수 있습니다.

https://github.com/square/leakcanary






































+ Recent posts

티스토리 툴바