Android Context

안드로이드 개발을 하다보면 Context라는 말을 정말 많이 듣는다. 

Activity 전환, Service, 등등 정말 안쓰이는 곳이 없는데, 정작 이 Context를 넣어주는건 둘째 치고 이게 뭔지도 몰랐다. 눈치상 대충 맥락이라고 생각했는데, 앱에서의 맥락은 뭔지 좀 알기 어려웠다.

생각해보면 "맥락" 이라는 단어가 참 추상적인 것 같다. Tmi이지만, 나도 사실 문맥, 맥락이라는 말을 어머니께 여쭤봤던 기억이 있는데, 직접 경험해보고 이해해보는게 좋다고 생각한다. 중간 정도만 이해해도 다행인걸로..

 

공식 문서

---

공식문서에서는 Context를 아래와 같이 설명한다. 

• 앱 환경에 대한 전역적인 정보에 접근하는 인터페이스이다.
• 안드로이드 시스템에서 구현체가 제공되는 추상클래스이다.
• 어플리케이션별 리소스와 객체에 접근을 허용하고, 액티비티 실행, 인텐트 전송 및 수신 등 앱 수준의 작업에 대한 호출도 가능하다.

영어도 잔뜩 어지러운데 추상적인 단어들만 나온다. 그나마 액티비티 실행, 인텐트 전송, 수신에 대한 것들이 그나마 구체적이다.

 

일단 예시로 앱에서의 맥락이 무엇이 있을지 생각을 해볼 수 있을 것 같다. 즉, "앱 환경"을 생각해보자.

• 지금 이 스마트폰의 언어 설정이 한국어인가 영어인가?
• 어떤 화면에서 실행되고 있는가?
• 지금 기기가 세로로 들려있는가, 가로로 들려있는가?
• 지금 낮이라서 화면을 밝게 그려야할까, 밤이라서 어둡게 그려야 할까?
• 어떤 패키지 이름을 가진 앱 안에서 실행되고 있을까?

 

이 말들을 종합해 보면, 현재 기기의 상태, 앱의 설정, 디자인 테마 등의 배경 정보들을 모든 덩어리이다.

따라서 안드로이드 컨텍스트가 하는 일을 아래와 같이 설명할 수 있을 것 같다.

1. 어플리케이션의 현재 상태와 환경 정보에 접근할 수 있게 한다.
2. 시스템이 관리하는 리소스, 앱 정보를 얻기 위해서 사용한다
3. 안드로이드 시스템 서비스에서 제공하는 API에 접근하기 위해 사용한다. (네트워크 상태, GPS, 알람 등)

위의 말들을 종합해 함축적으로 말하자면 공식문서에서도 말한,

앱 환경에 대한 전역적인 정보, 또는 안드로이드 시스템과 상호작용하는 인터페이스

라고 정의할 수 있을 것이다. 

Activity, Application 을 보면 각각 Context를 상속 받는 것을 알 수 있다. 이는 화면과 어플리케이션이 안드로이드 시스템과 상호작용 할 수 있도록 해주는 존재들이기 때문이다.

Context는 추상 클래스로 선언되어있는데, 왜 추상클래스일까? 사실 나도 잘 모르겠다 ㅎㅎ,,

나의 생각으로는... Activity, Application, Service와 같은 애들이 시스템 정보에 접근해야할 게 있어서, Context를 추상클래스에 미리 시스템에 접근하는 프로퍼티나 함수를 구현하고 Activity, Application, Service를 구현하지 않았을까...싶다. 

 

그러면 이런 컨텍스트가 왜 필요할까?

Context가 필요한 이유

---

만약 안드로이드 시스템에 어떤 화면을 시작하는 요청을 보낸다고 작성해보자. 

startActivity(...)

위와 같은 방식으로 Activity를 시작하게 된다.

단순하게 시스템에 "화면 하나 실행해줘" 라는 요청만으로는 화면을 띄워주는 작업을 수행할 수 없다. 어떤 앱에서 요청했는지, 어떤 리소스를 사용해야하는지, 어떤 설정이 적용되어 있는지 와 같은 실행 환경 정보들이 필요하게 된다.

Context는 결국 이런 "환경"에 대한 정보를 받아오고 시스템 기능과 상호작용하는 인터페이스 역할을 한다.

 

Application Context vs Activity Context

---

 

컨텍스트의 종류엔 크게 두가지가 있다. 

 

1. Application Context

• 앱 내에서 유효한 컨텍스트이다
• 앱이 살아있는 동안 변하지 않고, 공유되는 하나만 존재한다.
  • Application이 거의 싱글턴과 비슷하다. 따라서 하나의 Application에 Context가 존재하므로 싱글턴과 비슷하다고는 할 수 있다. (실제로 싱글턴은 아니다.)
• 시스템 서비스, 리소스 접근에 적합하다

 

2. Activity Context

• Activity 내에서만 유효한 Context이다
  • 즉, Activity가 소멸하면, ActiviyContext도 같이 소멸하게 된다.
• 생명주기가 짧다
• UI 작업이 가능하다 (Dialog, Snackbar)

 

싱글턴과 같이 사용된다는 말은, 각각의 Activity 에서 호출되는 Application Context가 앱 Application 에 존재하는 Context를 공유한다는 의미가 된다.

 

그렇다면, 전역적인 싱글턴이 있는데 왜 AcitivityContext가 필요하게 된 것일까?

우선적으로, ApplicationContext에는 현재 화면(Activity)에 대한 UI 정보(테마, 생명주기 등)가 존재하지 않는다. ApplicationContext는 같은 앱 내의 전반적인 환경, 정보 등에 접근하고 있다.

• 앱 이름
• 패키지명
• 리소스
• 파일 저장소
• SharedPreferences
• 시스템 서비스

위와 같은 정보들을 Application Context를 통해 접근한다. 반대로 화면은 이미 Activity가 접근하고 있다. 

• 테마
• Dialog를 띄울 것인지
• 화면에 Toast를 띄울 것인지

는 각 화면마다 다르다. 

따라서 Application은 전역적으로 앱이 가지고 있는 정보들에 접근하고, Activity는 화면 정보에 접근하게 된다. 책임의 분리를 통해서 Application은 현재 어떤 화면이 현재 사용자에게 보여져있는지 모르기 때문에 일반적으로 UI를 그리는데 적합하지 않다. 

그리고, 앞서 ApplicationContext가 앱 내에서 전역적인 싱글턴과 비슷하게 동작한다고 했는데, 네트워크 연결, 시스템 서비스, 파일 저장소, 로컬 DB 등에다가 화면까지 접근하는 로직을 담게 된다면, 테스트가 어려워지고 의존성이 커지면서 UI 로직을 분리하지 못하게 된다.

따라서 모든 곳에 전역적인 ApplicationContext를 쓰면 안되는 이유는 

• UI 정보가 없다
• 모든 것을 전역적으로 처리하게 된다.
  • 테스트 어려움
  • 의존성 커짐
  • UI 로직 분리 못함

와 같다. UI와 관련된 작업까지 모두 Application Context로 처리하는 것은 지양하자.

그럼 왜 Activity와 Application을 나눠야 하나라고 고민이 든다. 이는 아래에 한번 나의 생각을 정리해보겠다.

 

Context 사용 시 주의할 점

---

외부에서 Activity Context를 외부에서 쓸 때 주의할 점이 있다. 바로 생명주기가 긴 객체에 파라미터로 Context를 이리저리 넘기는 일이다.

 

예를 들어서 ViewModel에 Activity Context가 필요하게 되었다고 가정하자. 그래서 ViewModel에 Activity Context를 아래와 같이 주입을 해줬다. 

좋다. 그러면 가로로 화면을 보던 사용자가 갑자기 세로로 보고싶다고 화면을 전환한다. (소신 발언: 화면 전환을 막아버리면 안되나...라고 하면 안되겟죠?)

그러면 Activity의 생명 주기에 따라서, Activity는 onDestroy가 호출되어 Activity가 완전히 파괴되고, 새로운 응애 Activity가 생성되게 된다. 그리고 ViewModel의 생명주기는 Activity에 독립적이므로 여전히 같은 ViewModel이 남아있다. (해당 화면 재구성에서는 살아남는다)

JVM의 GC(가비지 컬렉터)가 ViewModel을 보고 여전히 살아 있다고 판단해 메모리에서 해제하지 않는다. 이때, 이전 Activity Context에 대한 참조가 여전히 ViewModel에 남아 있으므로, GC가 해당 Activity Context가 사용되지 않는 객체라고 판단하지 못한다. 결과적으로 수거 대상이라고 판단하지 않아 해당 Activity Context를 메모리에서 해제 하지 않는다.

이러면 이전 Activity가 좀비처럼 그대로 남아 메모리에서 해제되지 못하고 여전히 남아있게 된다. Activity Context는 화면에 대한 정보를 담고 있으므로 화면을 회전 시킬때마다, 메모리에서 무거운 좀비 Activity가 발생하게 되는 것이다. 

이는 결국 불필요한, 큰 데이터가 메모리에 쌓이게 되고, 결국 메모리를 터뜨릴 수 있는 원인이 된다. 

따라서, Activity보다 생명주기가 긴 객체에 파라미터로 Context를 이리저리 넘기는 일은 강력하게 지양해야한다.

 

그렇다면 언제 사용해야할까?

---

Activity Context와 Application Context를 분리해야하고 주의할 점을 알았으니, 어떻게 써야할까?

1. Application Context
   • 앞서 말한 것과 같이, UI정보가 없으므로 UI와 무관한 작업
   • Service, DB 관리 객체 등과 같이 장기적으로 오래 유지해야하는 객체 (Room 생성, SharedPreferences 접근 등)
   • 외부 라이브러리 같은 곳에서 context를 필요로 할 때
   • 파일 저장
2. Activity Context
   • UI 관련 작업
   • Dialog 표시
   • 테마, 스타일이 적용 될 때

---

테코톡 발표한 PPT에서 그림 자료를 들고왔다.

https://canva.link/veagaune0zwop91