Hilt(1)

앞으로 뭘 하든 아키텍쳐를 제대로 적용하려면 DI가 꼭 필요하고 그렇게 하기 위해 필요한 게 Hilt 라이브러리다.

오늘부터 Hilt를 뽀개보겠다.

 

Hilt를 추가하는 방법은 여기 써놨다. 기본적으로 정해진 컴포넌트들로만 이루어져있어서 Dagger보다는 러닝커브가 낮다고 할 수 있다.(좀 더 추상화된 느낌)

컴포넌트 그래프를 보면 하위 컴포넌트가 상위 컴포넌트에 접근가능하지만 상위컴포넌트는 하위 컴포넌트에 접근할 수 없는 걸 알 수 있다.

# `@HiltAndroidApp`

https://dagger.dev/hilt/application

Hilt Application

Hilt의 시작점이 되는 어노테이션이다. 이걸 ApplicationClass에 지정하면 최상위 컴포넌트인 `SingletonComponent`가 빌드 시 생성된다. 그리고 이건 곧 컨테이너 역할을 한다. 컴포넌트에 의존성을 주입하는 걸 바인딩이라고 표현하는데 주입된 의존성을 유저가 요청하는 방향으로 소비된다.

# 바인딩 - `@Inject, @Provides, @Module`

Hilt컴포넌트가 의존성 주입을 받으려면 @Inject로 선언하면 된다.

@Inject
lateinit var test: Test

이렇게만 하면 주입이 될까? 주입은 하더라도 초기화가 안됐기 때문에 사용하려고하면 바로 죽어버릴것이다. 그래서 Test클래스에도 생성자에 @Inject를 붙여주는 작업이 필요하다.

class Test @Inject constructor(){

}

이렇게 선언하면 이제 Test클래스도 Hilt컴포넌트에 붙여둔다는 의미라서 처음 @Inject한 부분에서 사용할 수 있다.

이건 클래스를 직접 컴포넌트로 만들어서 올린거고, 모듈을 사용해서 주입하는 방식도 있다. 모듈이라 하면 보통 관련 데이터, 함수(역할)을 한 데 모아서 관리하는 단위다. 역할을 각각 나눈 멀티모듈을 생각해보면 바로 감이 올 것이다.

@Module
@InstallIn(SingletonComponent::class)
object ApplicationModule {

}

모듈은 전역에서 사용될거니까 `@InstallIn`으로 SingletonComponent에 설치한다고 명시해준다. 그리고 아까 직접 주입하던 걸 모듈로 가져오는데 이때 @Provides 어노테이션을 붙인다. 

@Module
@InstallIn(SingletonComponent::class)
object ApplicationModule {
    @Provides
    fun provideTest(): Test{
        return Test() //Binding한 형태
    }
    
    @Singleton // 이렇게 선언하면 언제 호출해도 동일한 인스턴스를 반환한다
    @Provides
    fun provideTestSingleton(): Test{
        return Test()
    }
}

객체를 Provide 해주는 형태기 때문에 이 경우에는 Test클래스에서 생성자를 @Inject해주지 않아도 된다. 

# `@AndroidEntryPoint`

https://dagger.dev/hilt/android-entry-point.html

Android Entry Points

이건 컴포넌트에 붙여주는 어노테이션이다. 안드로이드 클래스를 주입(@Inject)하기 위해 사용하는 어노테이션이고 `Activity, Fragment, Service, BroadcastReceiver(얘는 싱글톤만 가능), View`에 붙인다. 컴포넌트라고 했으면서 왜 ContentProvider는 없냐고 물어볼 수 있다. 말 그대로 진입점에 붙여주는 어노테이션인데 `ContentProvider`의 경우는 Dagger가 정의한 Entrypoint와 onCreate 시점이 다르기 때문이다. 이 부분에서 Fragment도 그대로 적용된다. Activity위에 Fragment가 떠있기 때문에 둘다 `@AndroidEntryPoint`를 붙여줘야된다.

클래스가 생성(onCreate)되고 AndroidEntryPoint로 인식을 해야 Hilt컴포넌트에 접근해서 @Inject로 의존성을 주입받아올 수 있다. 

 

근데 @Inject로 갖고오는 부분에서 중요한 게 있다.

@AndroidEntryPoint(FragmentActivity. class)
public final class FooActivity extends Hilt_FooActivity {
    @Inject Foo foo;

    @Override
    public void onCreate(Bundle savedInstanceState) {
    	super. onCreate(savedInstanceState);  // The foo field is injected in super. onCreate()
    }
}

`super.onCreate` 가 호출 될 때 주입되기 때문에, 이게 호출되기 전에 @Inject로 선언된 멤버에 접근하면 런타임에러가 발생하게된다. Hilt는 기본적으로 컴파일타임 위주라 컴파일 시점에서는 발견되지않는 오류다. 공식문서에 있는 도표를 보면 한번에 이해할 수 있다.

Component	Scope(Annotation)	Created at	Destroyed at
SingletonComponent	@Singleton	Application#onCreate()	Application process is destroyed
ActivityRetainedComponent	@ActivityRetainedScoped	Activity#onCreate()1	Activity#onDestroy()1
ViewModelComponent	@ViewModelScoped	ViewModel created	ViewModel destroyed
ActivityComponent	@ActivityScoped	Activity#onCreate()	Activity#onDestroy()
FragmentComponent	@FragmentScoped	Fragment#onAttach()	Fragment#onDestroy()
ViewComponent	@ViewScoped	View#super()	View destroyed
ViewWithFragmentComponent	@ViewScoped	View#super()	View destroyed
ServiceComponent	@ServiceScoped	Service#onCreate()	Service#onDestroy()

Hilt 컴포넌트 생명주기를 올바르게 사용하지 않으면 런타임에러가 발생해 앱 크래시가 발생한다.

 

각 컴포넌트가 가지는 스코프를 보면 `@Inject`는 스코프에 해당하지않는 걸 볼 수 있다. 따라서 그렇게 바인딩한 건 매번 인스턴스를 생성하고, 지정한 스코프 안에 있는 컴포넌트는 Hilt컴포넌트 생명주기 안에서 인스턴스를 재사용하는데 성능을 중요시한다면 이때 사용되는 생명주기를 굉장히 섬세하게 다뤄야한다.

 

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요!