Context?

Interface to global information about an application environment. This is an abstract class whose implementation is provided by the Android system. It allows access to application-specific resources and classes, as well as up-calls for application-level operations such as launching activities, broadcasting and receiving intents, etc.
- Android Context

일반적인 클래스는 안드로이드 시스템의 서비스와 리소스에 접근하는 방법을 알 수 없다. 그렇기에 안드로이드 시스템에 접근하기 위해 사용되는 것이 Context로, 앱과 안드로이드 시스템을 연결하는 중간다리 역할을 한다.

Context Inheritance

Context를 상속하는 대표적인 클래스로는 Application, Activity, Service가 있다.
그리고 당연히 각각의 Context는 상속한 클래스의 생명주기를 따라간다.
예를 들어 Application Context는 Application이 생성되고 파괴될때까지, Activity Context 또한 Activity가 생성되고 파괴될 때까지 유지된다.

Application Context

Base class for maintaining global application state.
- Android Application

Application 클래스와 생명주기를 함께하는 Context로, 앱의 생명주기에 걸쳐 단 하나만 존재하고 앱 전반에서 사용된다.
따라서 앱이 종료되지 않는 한, 언제나 사용이 가능하다.
Application Context로 할 수 있는 것들

• 앱 리소스에 접근
• 서비스 시작/바인딩
• 브로드캐스트 등록/전송

Activity Context

Almost all activities interact with the user, so the Activity class takes care of creating a window for you.
- Android Activity

Activity 클래스와 생명주기를 함께하는 Context로, 사용자에게 보이는 UI를 담당하기 때문에 Theme에 접근가능한 ContextThemeWrapper를 상속한다는 특징이 있다.

Memory Leaks with Activity Context

Activity Context는 Activity가 생성되고 파괴됨에 따라 운명을 같이한다. 문제는 Activity가 Configuration Change를 통해 생각보다 생성과 파괴가 자주된다는 것이다. 그렇기에 Activity Context는 서로 다른 생명주기를 가지는 클래스(ex. ViewModel)에서 사용하면 메모리 누수의 위험이 있다.

Usage of Activity Context

그럼 Application Context보다 짧은 생명주기를 가지고 메모리 누수의 위험이 있는 Activity Context를 왜 사용하는 것일까?

그것은 Application Context의 기능에 추가적으로 Activity Context는 UI에 대한 정보를 가지고 접근이 가능하기 때문이다.
Activity Context가 할 수 있는 것들

• Layout Inflation
• 네비게이션
• 다른 액티비티 시작
• 다이얼로그 생성
  이처럼 사용자 화면과 관련된 기능들은 Activity Context를 통해서만 가능하다.

Service Context

A Service is an application component representing either an application's desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use.

• Android Service

Service Context는 Activity와 같이 Service 컴포넌트의 생명주기를 따라가며, 상대적으로 짧은 생명주기를 가진 Activity와 달리 긴 시간동안 실행되어야하는 작업에 사용된다.

Long-lived Context

오래 걸리는 작업을 위해 긴 생명주기를 가진 Context를 사용한다면, 왜 Application Context를 사용하지 않고 Service Context가 따로 존재하는 것일까?

각각의 서비스 컴포넌트가 아니라 Application Context를 통해서만 접근할 경우, 안드로이드 시스템은 어느 컴포넌트가 시스템에 접근 중인지 알 수 없기 때문이다.
또한 컴포넌트 별로 권한을 관리하거나 서비스를 바인딩 하기 위해서도 어느 서비스 컴포넌트가 요청을 하는 것인지 알 수 있어야한다.

Content Provider & Broadcast Receiver

ContentProvider와 BroadcastReceiver는 안드로이드 리소스와 시스템을 사용하는 안드로이드 컴포넌트임에도 Context를 상속하지 않는다. 왜일까?

ContentProvider와 BroadcastReceiver 모두 Context를 필요로 한다. 다만, 상속하는 대신 주입을 받는다는 차이가 있다.

/**
 * After being instantiated, this is called to tell the content provider
 * about itself.
 *
 * @param context The context this provider is running in
 * @param info Registered information about this content provider
 */
public void attachInfo(Context context, ProviderInfo info) {
    attachInfo(context, info, false);
}

- ContentProvider.attachInfo

public abstract void onReceive (Context context, Intent intent)

- BroadcastReceiver.onReceive

ContentProvider는 안드로이드 시스템에 의해 Application Context를 주입받고, BroadcastReceiver이 등록되는 위치에 따라 Application, Activity, Service의 Context를 주입받는다.

이렇게 Context를 주입받는 이유는 두 컴포넌트 모두 수동적이기 때문이라고 볼 수 있다. 리소스 요청이 있을 때 실행되고 개발자가 아닌 시스템에 의해 관리되는 ContentProvider와, Intent를 받고 처리하는 동안에만 존재하는 BroadcastReceiver의 경우 각각의 Context가 존재하기 보단 주입받는 것이 더 클래스를 목적에 집중하면서 가볍게 유지하는데 도움이 될 것이다.