https://dagger.dev/hilt/subcomponents-vs-deps

10.4 Design Decisions – Subcomponents vs Component dependencies

개요

Hilt는 컴포넌트 의존성과 대조적으로 Dagger의 서브컴포넌트를 기본적으로 사용한다. 이 페이지에서는 Hilt가 왜 이러한 방식으로 설계되었는지 설명한다.

단일 바인딩 키 공간

서브 컴포넌트는 기본적으로 모든 바인딩을 전파한다. 여기에는 컴포넌트 의존성을 통해 전파하기 어려운 멀티 바인딩도 포함된다. 멀티 바인딩은 병합된 바인딩 키 공간을 만들고, 이는 보통 바인딩이 전파되거나 또는 상위 컴포넌트로부터 하위 컴포넌트로 전파되는지에 대한 걱정을 할필요가 없기 때문에. Dagger의 오브젝트 그래프를 이해하기 쉽도록 만든다. 또한 컴포넌트 의존성으로 바인딩이 전파되지 않는다면, 서로 다른 컴포넌트에서 동일한 바인딩 키에 대해 다른 두가지 정의를 사용할 수 있다. 바인딩 정의가 사용되는 문맥을 기반으로 하기 때문에 디버깅시 코드를 살펴보는 것이 어려울 수 있다.

단일 바인딩 키 공간의 한가지 단점은 코드 사용에 대한 제약조건으로 인해 추가적인 작업이 어려워 질 수 있다는 점이다 (예. 다른 기능의 바인딩을 어떤 기능에서 사용하지 않을 때). 이럴때 보통은 한정자 어노테이션을 사용하여 가시성을 제한하거나 SPI 플러그인의 사용으로 코드를 분리하는 것을 권장한다. 한정자를 사용하거나 SPI 플러그인을 사용하면 이러한 규칙이 있는 정책을 표현하기 때문에 Dagger 컴포넌트 의존성 그래프의 구조에서 이러한 걱정들을 기르는 것보다는 낫다. 이와 같은 정책 결정은 종종 유동적이고 (예외가 허용되어야하며) 이러한 변경을 기반으로 Dagger 컴포넌트 의존성 그래프를 재구성해야하는 경우 비용이 많이들 수 있다.

컴포넌트 의존성으로 바인딩을 전파하는 것은 Dagger에서 문제가 될 수 있다.

Dagger는 그래프의 진입점을 알 수 있기 때문에, 사용되지 않는 바인딩을 파악하고 해당 바인딩에 대한 코드를 생성하지 않을 수 있다. 이런 최적화는 서브컴포넌트들에서도 이루어지지만, 컴포넌트 의존성을 통해 바인딩을 전파하고자 하면 진입점 메서드가 추가되기 때문에 문제가 생긴다. 따라서 진입점 메서드가 다른 Dagger 컴포넌트와 컴포넌트 전체에서 바인딩이 사용되지 않더라도, Dagger는 강제로 관련된 코드를 생성한다.

상위 및 빌드 속도 구성하기

컴포넌트 의존성의 주된 장점 중 하나는 Dagger 코드를 개별적 그리고 병렬적으로 만든다는 것이다. 이는 컴포넌트간 관계에 있어 컴포넌트를 블랙박스로 만드는 암시적인 공유의 부재로 수행된다. 그러나 Hilt는 이미 빌드 의존성에 기반한 중앙 구성 개념을 기반으로 하고 있다. Hilt는 모듈을 통합해야하기 때문에 모든 컴포넌트가 동시에 생성되므로 병렬로 만들어질 수는 없다.

대신 빌드 속도를 해결하기 위해, Hilt는 독립적인 기능 개발에 대해 작은 테스트 앱을 만드는 것을 권장하고 있다. Hilt가 없다면 Dagger의 반복되는 보일러플레이트 코드로 인해 테스트를 수행하기가 어려울 것이다. 하지만 Hilt는 빌드 의존성에 기반한 모든 Dagger 관련 코드를 생성하므로 작은 테스트 앱을 구성하는 것이 훨씬 쉬워진다.

후원하기