[Android] Context 💢

Context !?

• 어플리케이션 환경에 관한 전체 정보를 받을 수 있는 추상 클래스.
• 액티비티, 브로드캐스트, 서비스를 시작할 떄도 사용되고 리소스에 접근할 때에도 context가 사용된다.
• 어플리케이션과 관련된 정보에 접근하고자 하거나 어플리케이션과 연관된 시스템 레벨의 함수를 호출하고자 할 때 context가 필요하다.
• 안드로이드는 어플리케이션 관련 정보를 ActivityManagerService에서 관리하고 있고, 어플리케이션과 관련된 정보에 접근하려 할때 해당 어플리케이션에 대한 식별자가 필요한데 그 역할도 한다.

---

ContextWrapper & ContextImpl

• Context는 추상 클래스이기 때문에 이를 사용하기 위해서는 구현체가 있어야 한다.
• 기본 구현체는 ContextImpl이고, 이 구현체는 사용자에게 노출하지 않고 ContextWrapper로 감싸져 있다.

📌 참고 사항

• ContextImpl 클래스는 앱에서 직접 사용할 수 있는 클래스가 아니기에 소스코드로만 확인이 가능하다.
• 앞으로 Context의 구현체라는 말은 ContextWrapper가 wrapping하는 Context 구현체가 ContextImpl이 아닐 수 있기에 ContextImpl과의 용어 구분을 위해 Context 구현체라고 한다.

---

Context 클래스 구조

ContextWrapper 클래스는 생성자로 context구현체를 받아서 context동작을 context구현체의 동작으로 위임한다. (아래를 보자.)

즉, ContextWrapper를 상속하는 Activity, Service, Application과 같은 컴포넌트에서 ContextWrapper의 함수를 호출하면 Context 구현체의 동작을 수행하게 하는 것이다.
🔎 ContextWrapper가 Context의 구현체의 동작을 수행한다.

이를 Proxy 패턴이라고 하는데, 이 패턴을 사용하면 Context 구현체와 이를 사용하는 쪽의 결합도가 낮아져 쉽게 Context구현체를 변경할 수 있다느 장점이 있다.

ContextWrapper로 구현가능한 건 아래와 같이 ContextWrapper클래스를 열어보면 알 수 있다.

그래서 ContextWrapper는 생성자로 Context 구현체를 받고, Context의 모든 동작을 Context 구현체의 함수로 위임을 한다.
이 구조가 좋은 점은 앞서 말했듯 Context 구현체를 바꾸어도 Context를 사용하던 코드는 변경되지 않아도 된다는 것이다.
ContextWrapper에서 Context구현체를 바꾸는 메서드는 attachBaseContext(Context base)이다.

ContextImpl 코드를 보고싶다면 여기를 보자.

---

Context의 종류

위의 Context 구조에서 볼 수 있듯이 ContextWrapper를 상속하는 컴포넌트는 Activity, Service, Application이다.
BroadcastReceiver나 ContentProvider는 ContextWrapper를 상속하지 않는다.
여기서 Activity, Service, Application 컴포넌트는 각각 ContextImpl을 생성하고 ContextWrapper에서 getBaseContext()와 getApplicationContext()메서드를 호출하여 Context를 반환한다.

• Application Context
  • Singleton 객체로 어플리케이션의 생명주기를 따른다. 앱의 시작부터 종료시까지 살아있다.
• Activity Context
  • Activity 자체가 Context를 상속하고 있기에 Activity 인스턴스 자체가 Context 역할을 한다.
  • 그렇기에 Activity Context는 액티비티 생명주기를 따른다.

---

Context Type

• Application
  : Singleton으로 어플리케이션 객체가 생성될 때 함께 Application Context가 생성되게 Application Context는 동일한 앱 안에서 항상 동일한 인스턴스를 반환한다.

• Activity / Service
  : 액티비티나 서비스가 생성될 때마다 각각의 Context Instance가 생성된다.

• BroadcastReceiver
  : 자기 자신이 Context는 아니다. 리시버가 브로드캐스트 처리를 할 때마다 Context를 onReceive()의 인자로 전달 받아서 사용한다. 전달 받은 Context의 생명주기를 따르기 때문에 액티비티 컨텍스트로 브로드 캐스트 실행 시 액티비티가 종료되면 브로드 캐스트도 함께 종료된다.

• ContentProvider
  : 자기 자신이 Context는 아니다. 동일한 응용 프로그램에 대해 호출 시 동일한 Singleton Context 객체를 반환하고, 서로 다른 응용 프로그램에 대해 호출 시 다른 Context 객체를 반환한다.

---

Context 참조하는 방법 ✅

• ActivityName.this

  • Activty Context를 반환.
  • Activity Scope안에서 사용할 때는 this만으로도 가져올 수 있다.
  • Activity의 inner class와 같이 Activity Scope를 벗어난 곳에서 Activity Instance를 참조하고 싶을 때 ActivityName.this로 가져올 수 있다.

• getApplicationContext()

  • Application Context를 반환한다.

• getApplication()

  • Application 인스턴스를 반환한다.
  • Application도 Context의 자식 클래스임으로 Context처럼 사용할 수 있다.
  • 하지만, Application과 ApplicationContext가 동일한 인스턴스라는 보장이 없고, Application은 Activity나 Service내부에서만 참조가 가능하다는 차이도 있다.

• getBaseContext()

  • ContextWrapper의 Context 인스턴스를 반환한다.
  • 다른 Context를 참조해야 하는 경우, 그 ContextWrapper 안에 있는 context를 getBaseContext()로 가져와 사용한다.
  • 이는 Activity Context의 일종이다.

• View에서 getContext()

  • View에서도 getContext()메서드가 있어서 Context를 가져올 수 있는데, View를 생성할 때 생성자의 인자로 들어가는 Context가 getContext()의 결과로 반환된다.
  • 일반적으로 View가 속해있는 Activity의 Context가 해당 View의 Context가 된다.

---

Context의 생명주기가 다르기에 Activity와 분리된 작업에 Activity Context를 사용하면 예기치 못한 동작이 발생할 수 있다.

반대로 Activity에 종속된 작업을 Application Context를 이용하면 Activity가 종료되어도 Context를 이용한 작업이 종료되지 않아(메모리 해제가 이루어지지 않아서) 메모리 누수가 발생할 수 있다.

⚠️ 그렇기에 Context의 특징가 필요한 작업의 특성을 고려해 알맞게 써야 한다.