Android의 의존성 주입

이 게시글은 아래의 공식문서를 보고 작성했습니다.

Android의 종속 항목 삽입 | Android 개발자 | Android Developers

Android의 종속 항목 삽입 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. 종속 항목 삽입(DI)은 프로그래밍에 널리 사용되는 기법으로, Android 개발에 적합합니

developer.android.com

Image by sentavio on Freepik

의존성 주입(Dependency Injection)

안드로이드는 관심사에 맞게 클래스로 코드를 분할하라고 합니다. 다만 이렇게 되면 코드가 여기저기로 흩어지게 됩니다.

보통 우리가 만드는 앱의 구조가 바로 아래의 그림처럼 흩어지게 되죠.

위의 그림에서 집중해서 봐야할 부분은 바로 각 클래스에 화살표가 있고 이것들이 그냥 연결된 것이 아니라 방향이 존재한다는 것입니다.

만약 이러한 방향이 없다면 어떨까요?? 그림을 조금 더 자세히 보겠습니다. 만약 Repository가 Room과 Retrofit으로 데이터를 가져오려고 한다고 생각해 보겠습니다. 그렇다면 Repository가 이러한 객체를 직접 생성해야 한다면, Repository는 Room과 Retrofit에 강하게 결합되게 됩니다.

그렇기에 우리는 의존성 주입을 해야합니다. 의존성 주입은 쉽게 말하자면 객체를 생성하는 시점에 필요한 의존성 객체를 외부에서 전달하는 방식입니다.

의존성 주입에 대한 좀 더 자세한 내용은 아래의 게시글에 있습니다.

Dependency Injection (DI, 의존성 주입) with Kotlin

의존성 주입이란? 객체는 다른 객체와 상호작용하면서 필요한 다른 객체에 의존한다. 이러한 의존 관계는 코드를 작성할 때 자연스럽게 발생하는데, 이러한 의존성이 많아지면 코드의 유지보수

everyday-develop-myself.tistory.com

안드로이드에서의 의존성 주입

안드로이드에서는 의존성 주입을 의존성 주입 라이브러리인 Dagger 로 처리합니다. 다만 Dagger 는 러닝커브가 매우 높다는 단점이 있었습니다. 그래서 구글은 Hilt 를 만들었습니다. Hilt 는 Annotation으로 쉽게 의존성을 주입해 줍니다.

저도 Hilt 를 사용해 봤지만 안드로이드 개발을 시작한지 얼마 되지 않았기 때문에 기존에는 어떻게 의존성 주입을 했는지 잘 알지못합니다. 그래서 Hilt 가 어떤 과정을 편리하게 해줬는지, 어떤 방식으로 의존성 주입을 하는지 알아보고자 합니다.

직접 의존성 주입하기

제 생각에는 의존성 주입 라이브러리를 사용하지 않고 직접 의존성을 주입 해보는 것이 Hilt 가 어떻게 의존성 주입을 하는지 이해하기 가장 쉬울 것 같습니다.

원초적으로 의존성 주입하기

아래의 그림은 안드로이드 앱의 일반적인 로그인 흐름입니다. 각 구성 요소들은 단방향으로 다른 구성 요소에 종속되어 있습니다.

수동으로 의존성을 주입할 때는 로그인 흐름의 시작인 `LoginActivitiy`에서 의존성을 주입합니다.

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        
        val retrofit = Retrofit.Builder()
            .baseUrl("https://example.com")
            .build()
            .create(LoginService::class.java)

        val remoteDataSource = UserRemoteDataSource(retrofit)
        val localDataSource = UserLocalDataSource()

        val userRepository = UserRepository(localDataSource, remoteDataSource)

        loginViewModel = LoginViewModel(userRepository)
    }
}

위의 코드를 보면 2개의 DataSource에서 데이터를 각각 가져오고 이를 저장소에 주입합니다. 그리고 ViewModel에 저장소를 주입합니다.

❌ 다만 이런 방식에는 문제가 많습니다. 각 의존성 주입 과정은 순서대로 이루어져야하며, 재사용이 어렵습니다.

Container 사용

객체의 재사용 문제를 해결할 수 있는 방법은 컨테이너 클래스를 사용하는 것입니다. 아래의 코드에서는 저장소의 인스턴스만 공개됩니다.

class AppContainer {
    private val retrofit = Retrofit.Builder()
                            .baseUrl("https://example.com")
                            .build()
                            .create(LoginService::class.java)

    private val remoteDataSource = UserRemoteDataSource(retrofit)
    private val localDataSource = UserLocalDataSource()

    val userRepository = UserRepository(localDataSource, remoteDataSource)
}

이러한 컨테이너의 인스턴스는 전체 애플리케이션에서 사용됩니다. 그렇기에 모든 Activity에서 사용할 수 있는 `Application` 클래스에 배치합니다. 그럼 Activity에서 쉽게 사용할 수 있습니다.

class MyApplication : Application() {
    val appContainer = AppContainer()
}

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        
        val appContainer = (application as MyApplication).appContainer
        loginViewModel = LoginViewModel(appContainer.userRepository)
    }
}

Factory 사용

다만 이런 식으로는 저장소의 인스턴스가 계속해서 생겨납니다. 그렇기에 Factory 패턴을 사용해서 객체의 생성을 다른 곳에 위임하고 이를 싱글톤으로 관리하는것이 좋습니다.

interface Factory<T> {
    fun create(): T
}

class LoginViewModelFactory(private val userRepository: UserRepository) : Factory {
    override fun create(): LoginViewModel {
        return LoginViewModel(userRepository)
    }
}

class AppContainer {
    ...
    val userRepository = UserRepository(localDataSource, remoteDataSource)

    val loginViewModelFactory = LoginViewModelFactory(userRepository)
}

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
		
        val appContainer = (application as MyApplication).appContainer
        loginViewModel = appContainer.loginViewModelFactory.create()
    }
}

이걸로 모든 문제가 해결되어 모두가 행복하다면 좋았겠지만 여전히 모든 종속 항목의 인스턴스를 수동으로 만들고, 많은 상용구 코드로 인해 수동으로 팩토리나 매개변수를 만들어야 합니다.

Dagger에 대한 이해

Hilt에 대해 자세히 알아보기 위해서는 Dagger의 기본적인 개념 대해 아는 것이 필수일 것 같습니다. 단순하게 사용하는 것에 그친다면, Dagger에 대해서는 알 필요가 없습니다. 그렇지만 Hilt를 잘 사용하고 싶고, 그 원리를 알기 위해서는 Dagger를 알아야 합니다.

Dagger의 필수 개념

Dagger는 5가지의 개념을 가지고 의존성 주입을 하고 있습니다.

Inject
Component
SubComponent
Module
Scope

Component

Dagger에서 Component는 의존성 그래프를 생성하고 의존성을 주입하는 역할을 합니다. 이 한 줄의 설명으로 알 수 있듯이 Dagger에서 가장 중요한 역할을 담당하고 있습니다.

Dagger에서의 의존성 주입은 Component를 통해서 이뤄집니다.

이러한 Component를 생성하는 방법은 `@Component` 어노테이션을 사용하는 것입니다. `@Component` 어노테이션은 Interface나 추상 클래스에 붙어서 사용될 수 있습니다.

@Component
interface ApplicationGraph {
    fun repository(): UserRepository
}

Component에서는 사용될 Module, Scope Level, 주입받을 대상을 설정할 수 있습니다.

Module

Module에서는 `Provides` 또는 `Binds` 어노테이션을 사용해 주입될 클래스의 인스턴스를 직접 생성하거나 주입받아 연결합니다.

@Module
class MyModule {
    @Provides
    fun provideMyObject(): MyObject {
        return MyObject()
    }
}

Component에 Module을 설정해서 사용하려면 아래와 같이 설정할 수 있습니다.

@Component(modules = [MyModule::class])
interface MyComponent {
    fun getMyObject(): MyObject
}

Scope

`@Scope` 어노테이션을 통해 특정 범위 내에서 객체를 관리할 수 있습니다.

아래와 같이 Module과 Component에 `@Singleton`으로 Scope를 설정한다면 처음 요청시에만 객체를 생성하고 그 다음부터는 처음에 제공한 인스턴스를 제공받을 수 있게 됩니다.

@Module
class MyModule {
    @Provides
    @Singleton
    fun provideMyObject(): MyObject {
        return MyObject()
    }
}

@Component(modules = [MyModule::class])
@Singleton
interface MyComponent {
    fun getMyObject(): MyObject
}

물론 Custom한 Scope를 만들 수도 있습니다.

Inject

`@Inject` 어노테이션을 사용하면 Component로 부터 의존성 객체를 주입해 달라고 요청할 수 있습니다.

Component는 요청을 받으면 Module로 부터 객체를 생성하거 념겨주거나 직접 생성해서 넘겨줍니다.

class SomeClass @Inject constructor(val myObject: MyObject) {
    // 주입된 의존성 사용
}

SubComponent

정의한 Component에 자식 Component 즉 SubComponent를 정의할 수도 있습니다. 이렇게 되면 Component들로 계층 관계를 만들 수 있고, Inject로 의존성 주입을 요청받으면 SubComponent부터 의존성을 검색하게 됩니다.

Hilt를 사용해 의존성 주입하기

이제 수동으로 상용구 코드를 작성하고 이를 Container로 관리하는 것은 질렸습니다.

Hilt는 이 모든 과정을 알아서 제공해줍니다. 안드로이드의 모든 클래스에 컨테이너를 제공하고, 수명 주기를 자동으로 관리함으로써 애플리케이션에서 의존성 주입을 사용하는 표준 방법을 제공합니다.

애플리케이션 클래스

이전에 Container를 애플리케이션 클래스에 배치했던 것을 기억하시나요?? Hilt는 자동으로 `Application` 객체의 수명 주기에 연결되어 이와 관련된 종속 항목을 제공합니다.

이를 위해서는 `@HiltAndroidApp` 어노테이션을 지정하기만 하면 됩니다.

@HiltAndroidApp
class ExampleApplication : Application() { ... }

`@HiltAndroidApp` 어노테이션은 Container의 역할을 하는 애플리케이션의 기본 클래스를 비롯하여 Hilt의 코드 생성을 트리거합니다.

이 말은 Dagger에서는 Component들을 우리가 직접 정의해야 했지만, Hilt에서는 안드로이드에서 표준적으로 사용되는 Component들을 기본적으로 생성해 준다는 말입니다.

이렇게 생성되는 Component들은 전반적인 라이프 사이클 또한 자동으로 관리해주고 있기 때문에 사용자가 초기 DI 환경을 구축하는데 드는 시간을 매우 절약해 줬습니다.

Hilt는 아래와 같은 Component들을 계층 구조로 제공해 줍니다.

애플리케이션 클래스에 의존성 주입

Hilt는 아래와 같은 안드로이드 클래스에 `@AndroidEntryPoint` 주석으로 종속 항목을 제공합니다.

Application(@HiltAndroidApp을 사용하여)
ViewModel(@HiltViewModel을 사용하여)
Activity
Fragment
View
Service
BroadcastReceiver

@AndroidEntryPoint
class ExampleActivity : AppCompatActivity() { ... }

Injection (주입)

Hilt는 의존성 그래프를 만들어 필요한 곳에 의존성을 제공해 줍니다. 그래서 어떤 곳에서 의존성이 필요한지 이 의존성을 어떤 클래스에서 제공하는지 어노테이션을 통해 이를 연결합니다.

이러한 의존성이 필요하다고 말하는 방법은 `@Inject` 어노테이션을 사용하여 필드 주입을 하는 방법과 생성자 주입을 하는 방법이 있습니다.

Field Inject (필드 주입)

`@AndroidEntryPoint`는 프로젝트의 각 안드로이드 클래스에 관한 개별 Hilt 구성요소를 생성합니다. 그리고 이를 주입하려면 의존성을 제공하는 제공자와 이 의존성이 필요한 소비자를 연결해야 합니다.

`@Inject` 어노테이션을 사용해 필드 삽입을 실행합니다.

@AndroidEntryPoint
class ExampleActivity : AppCompatActivity() {

  @Inject lateinit var analytics: AnalyticsAdapter
  ...
}

Constuctor Inject (생성자 주입)

생성자 주입을 사용하면, 해당 클래스의 인스턴스를 생성할 때 어떤 객체가 필요한지 Hilt가 알 수 있게 됩니다.

class AnalyticsAdapter @Inject constructor(
  private val service: AnalyticsService
) { ... }

생성자 주입을 할 수 없는 경우

인터페이스 같은 경우에는 객체가 없기에 생성자 주입을 할 수 없습니다. 또한 외부 라이브러리의 클래스와 같이 가지고 있지 않는 유형도 생성자 주입을 할 수 없습니다. 이럴때는 Hilt 모듈을 사용해 Hilt에 결합 정보를 제공합니다.

Provides (제공)

Dagger에서와 마찬가지로 Hilt에서도 필요한 의존성 객체를 제공해주기 위해서 Module을 정의해야 합니다.

다만 Dagger에서는 Module을 생성한 다음 정의한 Component에 Module을 직접 정의해 줬습니다. 하지만 Hilt에서는 기본적으로 생성된 Component들이 존재합니다.

그래서 Hilt에서는 Component에서 Module을 정의하는것이 아닌 Module에서 해당 모듈이 정의될 Component를 정의해주는 방식을 채택했습니다.

그래서 Hilt에서는 Module을 정의할 때 반드시 `@InstallIn` 어노테이션을 사용해 어떤 Component에 정의할 것인지 정해주어야 합니다.

@Binds를 사용해 인터페이스 인스턴스 삽입

Hilt 모듈은 `@Module`로 주석이 지정된 클래스입니다. Hilt 모듈에서는 `@InstallIn` 어노테이션도 같이 지정해 각 모듈을 사용하거나 설치할 안드로이드 클래스를 Hilt에 알려야 합니다.

예를 들면 아래와 같은 인터페이스는 이대로는 인터페이스의 인스턴스를 제공할 수 없습니다.

interface AnalyticsService {
  fun analyticsMethods()
}

그렇기에 아까전에 말했던 2개의 어노테이션과 함께 `@Binds` 어노테이션을 사용해 인터페이스의 인스턴스를 제공해야 할 때 사용할 구현을 Hilt에게 알려주게 됩니다.

class AnalyticsServiceImpl @Inject constructor(
  ...
) : AnalyticsService { ... }

@Module
@InstallIn(ActivityComponent::class)
abstract class AnalyticsModule {

  @Binds
  abstract fun bindAnalyticsService(
    analyticsServiceImpl: AnalyticsServiceImpl
  ): AnalyticsService
}

@Provides를 사용해 인스턴스 삽입

클래스가 외부 라이브러리에서 제공되는 경우나(Retrofit, Room 등) 빌더 패턴으로 인스턴스를 생성해야 하는 경우에는 `@Provides` 어노테이션을 사용해 해당 유형의 인스턴스를 제공하는 방법을 Hilt에 알립니다.

@Module
@InstallIn(ActivityComponent::class)
object AnalyticsModule {

  @Provides
  fun provideAnalyticsService(
  ): AnalyticsService {
      return Retrofit.Builder()
               .baseUrl("https://example.com")
               .build()
               .create(AnalyticsService::class.java)
  }
}

@Binds와 @Provides의 사용

Hilt는 @Inject 어노테이션 만으로 클래스의 객체를 주입받을 수 있습니다. 그렇기 때문에 이 2가지의 어노테이션을 사용하는 경우는 해당 클래스의 객체 자체를 반환하는 경우가 아니라 특정한 작업을 해야 할 경우입니다.

예를 들면 위에서 예시를 들었던 Repository의 경우입니다. 이 경우에는 인터페이스를 통해 내부 동작을 추상화하고 있습니다. 그렇기 때문에 인터페이스를 반환하고 있지만, 실제로 내부에 전달되는 객체는 이를 구현한 클래스여야 합니다.

마무리 하며

기본적으로 의존성 주입을 하는 부분은 알아본것 같습니다. 의존성 주입이라는 말도 처음 들으면 무엇을 의미하는지 이해가 잘 되지 않지만, 안드로이드 개발을 위해서는 꼭 필요한 부분이기에 지속적으로 공부하는 것이 좋을것 같습니다.

'Android' 카테고리의 다른 글

클린 아키텍처와 안드로이드 권장 멀티 모듈 적용하기 (1) (0)	2023.10.04
Gradle의 동작원리 이해하기 (1)	2023.09.27
안드로이드에서 Context가 존재하는 이유 (0)	2023.09.10
Android 4대 컴포넌트 - ContentProvider (0)	2023.09.03
안드로이드의 메모리 관리 부시기 (0)	2023.08.28