[Android] Dependency Injection vs Service Locator

1. Dependency Injection   

- 컴포넌트간의 의존 관계를 소스코드 내부가 아닌 외부 설정 파일등을 통해 정의되게하는 디자인 패턴중 하나

- 객체를 직접 생성하지 않고 외부에서 주입한 객체를 사용하는 방식

- 코드간의 커플링을 줄이며 유닛테스트를 용이하게 함

      

     

      

2. Service Locator [Wikipedia]

- '서비스 로케이터' 라는 중앙 등록자를 두어, 요청이 들어왔을 때 특정 업무를 수행하기 위한 정보를 반환한다.

- apk 크기, 빌드 속도, 메서드 수 등 복잡한 제약이 있는 경우 사용하기 편하다.

3. Dependency Injection  vs Service Locator

Dependency Injection	Service Locator
일부 핵심 클래스에 종속성을 주입	모든 클래스가 서비스 로케이터에 종속
처음 한번만 호출 (명시적인 호출이 없음)	인젝터를 직접 호출 (명시적인 호출)
의존 관계 파악이 쉬움	의존 관계 파악이 어려움

4. Android에서의 DI 

- 기존 DI 프레임 워크

(1) DI 프레임 워크의 용량 부담

(2) Dalvik의 제약으로 인한 DI 프레임 워크의 기능 한정

- Android 앱의 실행 환경인 Dalvik에서는 런타임 바이트 코드 생성 라이브러리를 사용할 수 없기 때문에 프레임워크의 기능이 한정된다.

- Spring과 같은 DI 프레임워크에서는 런타임 바이트 코드 생성을 많이 이용한다. 

(3) 대체로 애플리케이션의 규모가 작아서 DI의 유연성으로 얻는 이득이 크지 않음

(4) Android 기본 프레임워크와 DI 프레임워크의 조화

- Activity, Service 등 주요 객체는 이미 Android 기본 프레임워크에서 등록되고 고유한 라이프사이클이 정의되어 있다.

특히 이렇게 객체 등록과 라이프사이클 관리가 Android에 특화되어 있는데, 모든 객체에 일반화된 접근을 하는 DI 프레임워크를 동시에 사용하면 이득이 있을지 고민해야 한다.        

- Android 지원 DI 프레임워크

(1)  패키지 구성의 경량화

- 서버 쪽에서 쓰이는 Spring이나 Google Guice등을 그대로 쓰지 않고, Android를 감안해서 작은 용량으로 개발하거나 의존성을 최소화했다. 

특히 어노테이션 프로세싱은 라이브러리에서 컴파일타임에 의존하는 부분과 런타임에 의존하는 부분을 구분해서 더욱 용량을 줄였다.

(2) Annotation processing 사용

- Dalvik에서는 바이트 코드 조작 기술을 쓸 수 없지만, 어노테이션 프로세싱을 사용하여 소스를 생성한 후 컴파일하는 방법으로 대체했다.

(3) 애플리케이션의 규모가 작아도 View나 Resource 같은 자원을 가져오는 코드가 간결해짐

5. DI Library

- Koin [게시글 이동]

- Dagger

[참고]

[Service Locator, Dependency Injection (and Container) and Inversion of Control]

[Inversion Of control vs Dependency Injection with selected quotes - is my understanding correct?]

[출처]

[The Future of Dependency Injection With Dagger 2]

[Android에서 @inject, @Test]