안드로이드 개발을하며 Context는 빼놓을 수 없는 존재이다. 근데 막상 Context에 대해서 제대로 설명을 하려고하니 말문이 막히는 날 발견할 수 있었다. 이번 기회에 Context에 대해서 다시한번 짚고 넘어가고자 한다.
Context?
안드로이드에서 어플리케이션 환경 정보에 접근할 수 있도록 해주는 인터페이스로, 매우 다양한곳에서 사용할 수 있다. Context를 잘못 사용하면 메모리 누수로 이어질 수 있기 때문에 적재적소에 맞게 사용해야한다.
종류
크게 Application Context와 Activity Context로 나눌 수 있다.
Application Context
어플리케이션 라이프사이클과 묶여있어, 현재 Context가 종료되고 나서도 Context가 필요한 작업이나 액티비티 범위를 벗어난곳에 Context가 필요한 작업에 적합하다
만약 어플리케이션내에 싱글톤 객체를 만드려고 하는데, 이 객체가 Context를 필요로 할때 ApplicationContext를 사용하면 적절하다. 만약 Activity Context를 넘겨주게 되면 Activity에 대한 참조 메모리를 남겨두며 GC되지 않아 메모리 누수가 발생할 수 있다.
따라서 앱 전역에서 사용해야할 경우 Application Context를 넘겨 사용해야한다.
Application Context는 만능이 아니다.
GUI 관련 동작들에 있어, Application Context를 사용하면 오류가 발생할 확률이 높다.
예를들어, Application Context를 활용하여 AlertDialog show()하게 되면 Crash가 발생된다.
Activity는 생명주기 완료 시 GC가 가능하지만, Application은 앱이 살아있는 동안 게속 유지되기 때문에 메모리 누수의 주요 원인이 될 수 있다.
Activity Context
해당 Context는 액티비티 내부에서 사용 가능하며, Activity의 라이프사이클에 종속되어 있기 때문에 호출한 Activity가 소멸되면 해당 Context도 함께 소멸된다. 따라서 Activity의 라이프사이클에 따라 동작이 필요한 경우 사용하는게 적절하다.
참고사항
그렇다면 ViewModel에서 Room에 있는 데이터를 호출할 때 사용하는 Context는 어떤 Context가 적절할까?
정답은 Application Context이다. 순서대로 생각해보면 ViewModel에 Activity Context를 넘기고 데이터를 불러오는 시간동안 Activity가 종료되면 사용했던 Context도 함께 소멸되기 때문에 앱이 종료될 수 있다. 따라서 Activity의 생명주기와 관계없는 Application Context를 사용하면 된다.
Service Context
백그라운드 작업을 실행할 때 사용되며 음악 재생, 네트워크 요청, 데이터 동기화, 알람 처리등에 사용할 수 있다. UI 관련 작업은 불가능하다.
startService() 또는 bindService()로 서비스가 시작될 때 Service Context가 활성화된다.
Service Context에서는 onCreate()에서 Context가 생성되고 onStartCommand() 또는 onBind()에서 사용하며 onDestroy()에서 Context가 소멸된다.
BroadcastReceiver Context
브로드캐스트 리시버에서 제공하는 컨택스트로, UI 관련 작업이 불가능하며 짧은 시간 동안만 존재한다.
ContextWrapper
기존 Context를 감싸고 새로운 기능을 추가하는 클래스로 Context의 기능을 변경하거나 확장할 수 있다.
주요 사용처는 다른 테마를 적용(ContextThemeWrapper)하거나, 커스텀 기능을 추가할때 이다.
