어플리케이션 환경에 대한 전역 정보라고 할 수 있고, 여러 컴포넌트의 상위 클래스 입니다. 컨텍스트가 없으면 액티비티를 시작할 수도, 브로드캐스트 서비스를 발생시킬수도, 서비스를 시작할 수도 없습니다. 리소스에 접근할때도 컨텍스트를 통해서만 가능합니다.
컨텍스트는 추상 클래스로 메서드 구현이 거의 없고 상수 정의와 추상 메서드로 이루어집니다. 컨텍스트를 직접 상속한 것은 컨텍스트 래퍼이고 컨텍스트 래퍼를 상속한 것은 액티비티, 서비스, 애플리케이션입니다.
컨텍스트 래퍼 클래스
컨텍스트를 직접 상속한 클래스로 컨텍스트를 래핑하여 컨텍스트와 관련된 호출을 모두 담당하여 처리합니다. 이 클래스의 생성자와 attachBaseContext 메소드에서는 컨텍스트를 파라미터로 받고 있는데, 이때 대입되는 것은 컨텍스트의 구현체인 ContextImpl 인스턴스 입니다. 액티비티, 서비스, 애플리케이션은 기본 생성자를 사용하지 않고 attachBaseContext를 사용하여 컨텍스트를 설정합니다.
설정된 컨텍스트를 통해 컨텍스트 래퍼가 컨텍스트 임플리먼트의 메소드를 대신 호출해주는 역할을 할 수 있게 되고,
getBaseContext로 제공받은 컨텍스트 임플리먼트 인스턴스를 반환받을 수 있고, getApplicationContext로 액티비티 스레드의 애플리케이션 인스턴스를 반환받을 수 있습니다.
메서드의 종류
context와 하위 클래스
액티비티 서비스 애플리케이션은 컨텍스트 인플리먼트를 직접 상속하지 않고 컨텍스트 인플리먼트의 메서드를 호출하는 형태인데, 이런 구조로 컨텍스트 구현체와 이를 사용하는 쪽의 결합도가 낮아져 컨텍스트 구현체를 쉽게 변경할 수 있다는 장점을 가지게 됩니다.
컨텍스트 사용 시에는 라이프 사이클을 잘 생각해서 사용해야 합니다. 애플리케이션 컨텍스트는 싱글톤으로 앱에서 1개의 인스턴스밖에 없기 때문에 싱글톤 오브젝트나 전역으로 사용하는 클래스 같은 경우에 사용하면 좋습니다. 하지만 액티비티의 컨텍스트를 싱글톤 오브젝트에 참고하게 되면 액티비티가 onDestroy까지 갔지만 컨텍스트를 사용하기 때문에 GC의 대상이 되지 않아 메모리 릭이 발생할 수 있습니다. 따라서 컴포넌트의 라이프 사이클을 잘 파악하고 컨텍스트를 사용해야 합니다.