Gun.log

[DI] Hilt를 사용한 의존성 주입

Fri, 03 Mar 2023 12:00:22 GMT

이전 글에서 의존성 주입의 전반적인 개념에 대해 알아보았다. 구글에서 권장하는 의존성 주입 라이브러리 Hilt에 대해 알아보도록 하자.

[의존성 주입 되짚어 보기]

의존성 주입이란? 의존성 주입이란 외부에서 인스턴스를 생성하여 주입하는 것이다.
의존성 주입이 없을 경우 문제점 의존성 주입 없이 자체적으로 인스턴스를 생성하고 관리하게 되면 본연의 역할 이상을 수행 하므로 코드가 점점 거대해지며 변경에 민감하여 기존 작성된 코드에 영향을 미칠 수 있고 테스트를 어렵게 만든다.
수동 의존성 주입 시 문제점 의존성 주입을 수동으로 작업하게 되면 보일러플레이트 코드가 많아지고, 객체 생성에 대한 순서를 고려해야 하며, 컨테이너를 사용하여 재사용하고 관리해야 하고 객체의 수명주기 또한 고려해야 하는 번거로움이 동반된다.
라이브러리를 이용한 자동 의존성 주입의 이점 수동 의존성 주입과 서비스 로케이터를 통한 방법보다 셋업시간이 꽤 걸려 초기 비용이 많이 들지만, 앱이 커질수록 비용 곡선이 어느 정도의 선까지만 상승한다. 앱이 중간 정도의 크기로 갈수록 유지관리 비용이 다른 방법들과 큰 차이가 나지 않으며 일정 수준을 넘어설 경우 오히려 비용이 적게 든다.

[Hilt의 등장]

Hilt가 등장하기 전 구글에서는 Dagger 사용을 권장하였다. 하지만 Dagger는 러닝 커브가 높아 개발자들이 선뜻 적용하기엔 부담이 큰 문제가 있었다.

구글은 지속적으로 안드로이드 커뮤니티를 통해 Dagger에 대한 개선사항을 수용하였고,
Dagger 라이브러리의 장점을 살리고 추가적인 기능과 추상화를 통해 Dagger의 프로세스를 단순화하여 사용법을 간편화시킨 Hilt라는 라이브러리를 발표하였으며 이에 대한 사용을 권장하였다.
Hilt는 Android 앱을 위한 Jetpack의 권장 DI 솔루션으로, 좋은 아키텍처 설계에 도움이 되는 일부 Jetpack 라이브러리와 함께 사용할 수 있도록 지원한다. Hilt는 Dagger 라이브러리 기반으로 빌드되었으며, 이는 Hilt 코드를 컴파일할 때 Dagger 코드로 변환됨을 의미한다.

Dagger와 Hilt를 번역하면 단검과 손잡이다. Hilt(손잡이)는 Dagger(단검)를 쉽게 사용하기 위해 만들어진 것이다.

[Hilt의 이점]

단순화된 사용 Dagger의 어려운 사용법을 개선한 것이 Hilt이다. 개발자는 서술형으로 의존관계를 설정하지 않고 코드를 단순화하는 Annotation을 통해 작성해야 하는 코드의 양을 줄여줌으로써 의존성 주입 과정을 간소화해준다. Annotation을 명시하면 Annotation Processor에 의해 자동으로 컴파일 타임에 Dagger 라이브러리 코드를 생성하며 보일러플레이트 코드를 감소시킨다.

낮은 러닝 커브 Dagger에 비해 상대적으로 러닝 커브가 낮아 쉽고 편리한 환경을 제공한다.

테스트 지원 Hilt는 코드를 더 쉽게 테스트할 수 있도록 테스트 코드에서 유용한 어노테이션을 제공한다. 이를 통해 안드로이드 앱에 대한 테스트를 더 쉽게 작성할 수 있다. 이는 버그를 더 일찍 발견하고 앱이 더 안정적이고 신뢰할 수 있도록 보장할 수 있다는 것을 의미한다.

Jetpack 라이브러리 호환 Hilt는 Jetpack 라이브러리 중 ViewModel, Navigation, Compose, WorkManager를 지원하며 잘 호환되어 의존성을 쉽게 주입하고 관리할 수 있다.

컴파일 타임에 생성되는 코드 Hilt는 컴파일 시 의존성 관련 코드를 생성하기 때문에, 런타임에 리플렉션을 사용하는 일부 라이브러리보다 런타임 포퍼먼스가 향상된다.

[예제를 통한 Hilt 사용 방법]

사용자 정보를 화면에 표시하는 간단한 예제를 통해 Hilt를 어떻게 사용하는지 알아보자.

1. Gradle 환경 설정

build.gradle (Project Level)

plugins {
  ...
  id("com.google.dagger.hilt.android") version "2.45" apply false
}

build.gradle (App Level)


plugins {
  // // Hilt는 KAPT(Kotlin Annotation Processing Tool)의 도움을 받아 컴파일 시 코드를 생성한다.
  kotlin("kapt") 
  id("com.google.dagger.hilt.android")
}

android {
  ...
}

compileOptions {
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
  }


dependencies {
  ...
  implementation("com.google.dagger:hilt-android:2.45")
  kapt("com.google.dagger:hilt-android-compiler:2.45")
}

kapt {
  // correctErrorTypes을 true로 설정할 경우 런타임에서 발생할 수 있는 에러에 대한 검사를 컴파일 시점에 체크한다.
  correctErrorTypes = true

}

아래 내용에서 이해를 돕고자 사용한 코루틴이나 Room DB 같은 라이브러리 의존성은 추가하지 않았다.

2. Application 클래스 설정

@HiltAndroidApp 어노테이션을 통해 Hilt를 활성화 시켜보자. Application을 상속받는 클래스에 해당 어노테이션을 명시하면 Hilt를 활성화 시키며 의존관계를 설정하기 위한 Hilt 코드가 생성된다.

@HiltAndroidApp
class MyApplication: Application() {
    override fun onCreate() {
        super.onCreate()
        appContext = applicationContext    
    }

    // 이후 내용에서 Hilt에서 제공하는 Context 어노테이션으로 변경 예정
    companion object {
        lateinit  var appContext: Context
    }
}

3. Activity에 의존성 주입

화면에 사용자 정보 리스트를 화면에 표시해보자. 먼저 MainActivity 클래스 상단에 @AndroidEntryPoint 어노테이션을 선언하여 해당 클래스에 의존성 주입이 필요하다는 것을 알려주도록 하자. MainActivity 클래스의 UserRecyclerAdapter 변수 선언부에 @Inject 어노테이션을 선언하여 필드주입이 필요함을 알리고, Hilt가 UserRecyclerAdapter를 인스턴스화 하는 방법을 알 수 있도록 UserRecyclerAdapter 클래스의 생성자 앞에 @Inject 어노테이션을 선언하여 생성자 주입을 설정하자.

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
    @Inject lateinit var adapter: UserRecyclerAdapter // 필드주입

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val recyclerView = findViewById(R.id.recycler_view_user)
        recyclerView.adapter = adapter

        adapter.submitList(arrayListOf(User("홍길동")))
    }
}

class UserRecyclerAdapter @Inject constructor() : // 생성자 주입
    ListAdapter(diffUtil) {  
    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): UserViewHolder { ... }

    override fun onBindViewHolder(holder: UserViewHolder, position: Int) { ... }

    override fun getItemCount() { ... }
}

4. Module을 통한 Room 의존성 주입 (with @Provides)

위에서 Hilt에게 UserRecyclerAdapter 를 알려주기 위해 생성자 주입을 하였다. Room Database를 통해 데이터를 읽어 화면에 표시해보자.

하지만 Room DB는 라이브러리이므로 직접 코드 수정을 통한 생성자 주입을 할 수 없다. @Module을 통해 Hilt에게 Room DB를 인스턴스화 하는 방법을 알려줄 수 있다. Hilt는 모듈을 통해 의존성을 주입할 때 기본적으로 모듈 내 반환 타입과 일치하는 메서드를 사용하며, 해당 메서드에는 @Provides 어노테이션을 명시해주어야 한다.

먼저 최상단에 @Module을 선언하고, 이와 함께 @InstallIn 어노테이션을 필수적으로 선언해주어야 한다. Database는 앱 전반적으로 사용되므로 싱글톤으로 사용하기 위해 SingletonComponent를 지정해 주었다. 마찬가지로 DB를 반환하는 메서드에도 @Singleton Scope를 명시하였는데 이는 @InstallIn에 명시한 컴포넌트의 범위와 일치해야 한다.


@Entity
data class User @Inject constructor(
    @PrimaryKey(autoGenerate = true)
    val userId: Int = 0,
    @ColumnInfo(name = "name") val name: String?
)

@Dao
interface UserDao {
    @Query("SELECT * FROM user")
    suspend fun getUserList(): MutableList

    ...
}

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    companion object {
        const val TABLE_NAME = "user"
        const val COL_USER_ID = "userId"
        const val COL_USER_NAME= "name"
    }

    abstract fun userDao(): UserDao
}

@Module
@InstallIn(SingletonComponent::class)
object DataModule {
    @Provides
    @Singleton
    fun provideDB(): AppDatabase {
        return Room.databaseBuilder(
            MyApplication.appContext,
            AppDatabase::class.java, "User"
        ).build()
    }
}


@AndroidEntryPoint
class MainActivity : AppCompatActivity() {

    @Inject
    lateinit var adapter: UserRecyclerAdapter

    @Inject
    lateinit var appDatabase: AppDatabase

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
           ...
        queryUser()
    }

    private fun queryUser() {
        lifecycleScope.launch {
            val userList = appDatabase.userDao().getUserList()

            launch(Dispatchers.Main) {
                adapter.submitList(userList.toMutableList())
            }
        }
    }
}

5. Module을 통한 Room 의존성 주입 (with @Binds)

현재 Local DB를 통해 데이터를 조회하고 있지만, 추후 다른 Repository를 통해 데이터를 조회할 수 있도록 확장될 수 있기 때문에 Local DB를 Repository에서 관리되도록 수정해보자.

class UserRepository @Inject constructor(private val dataSource: UserDataSource) {
    suspend fun getUserList(): MutableList {
        return dataSource.getUserList()
    }
}

interface UserDataSource {
    suspend fun getUserList(): MutableList
}

class UserLocalDataSource @Inject constructor(private val appDatabase: AppDatabase) : UserDataSource {
    override suspend fun getUserList(): MutableList {
        return appDatabase.userDao().getUserList()
    }
}

UserRepository는 생성자 주입을 통해 MainActivity에서 사용할 예정이다. 생성자 파라미터에 UserDataSource는 인터페이스로 정의되어 있어 생성자 주입이 불가능하다. 이에 따라 Module에서 Hilt가 UserDataSource의 구현 클래스를 인스턴스화 하기위한 절차를 명시해주어야 한다. 코드를 간결하게 하기 위해 @Provides가 아닌 @Binds 어노테이션을 사용해보자.

@Module
@InstallIn(SingletonComponent::class)
abstract class DataModule {
    @Binds
    abstract fun bindUserLocalDataSource(userLocalDataSource: UserLocalDataSource): UserDataSource

    companion object {
        @Provides
        @Singleton
        fun provideDB(): AppDatabase {
            return Room.databaseBuilder(
                MyApplication.appContext,
                AppDatabase::class.java, "User"
            ).build()
        }
    }

}

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {

    ...

    @Inject
    lateinit var userRepository: UserRepository

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
           ...
        queryUser()
    }

    private fun queryUser() {
        lifecycleScope.launch {
            val userList = userRepository.getUserList()
            adapter.submitList(userList.toMutableList())
        }
    }
}

@Binds를 사용하기 위해선 Module의 선언을 interface나 abstract class로 선언해야 한다. Module의 abstract 메서드 반환타입 또한 abstract class 혹은 interface로 명시되어야 한다. 또한 메서드는 필수적으로 한 개의 파라미터가 요구되는데, Hilt에 의해 파라미터의 클래스가 반환타입의 구현 클래스로 매핑되며 반환된다. abstract class로 선언할 경우 @Provides 어노테이션을 사용할 수 없으므로, 필요시 companion object를 통해 사용하도록 하자.

6. Hilt에서 제공하는 Context 어노테이션 사용

위에서 DataModule 클래스에서 Room 데이터베이스 생성을 위해 Application Context가 필요해 MyApplication 클래스에서 Context 세팅하여 제공하는 작업을 했었다. Hilt에서는 Application, Activity 각각 상황에 맞는 Context 어노테이션을 제공하며 이를 통해 간편하게 Context를 주입할 수 있으므로 이를 활용해보자.


@HiltAndroidApp
class MyApplication: Application() {
    override fun onCreate() {
        super.onCreate()
        // appContext = applicationContext    
    }

    /* companion object {
        lateinit  var appContext: Context
    } */
}


@Module
@InstallIn(SingletonComponent::class)
abstract class DataModule {
    ...
    companion object {
        @Provides
        @Singleton
        fun provideDB(@ApplicationContext context: Context): AppDatabase {
            return Room.databaseBuilder(
                context,
                AppDatabase::class.java, "User"
            ).build()
        }
    }
}

7. 동일한 반환 타입을 가지는 클래스에 대한 여러 유형의 인스턴스 제공

위에서 Room 데이터베이스를 통해 데이터를 표시하였지만, DB를 조작하지 않고 Mock 객체를 생성하여 테스트용 데이터를 반환하는 코드를 작성한다고 가정해 보자.

먼저 UserDataSource 인터페이스를 확장하는 UserMockDataSource를 작성해보자.

class UserMockDataSource @Inject constructor(): UserDataSource {
    override suspend fun getUserList(): MutableList {
        return arrayListOf(User(1,"홍길동(Mock)"), User(2, "김길동(Mock)"))
    }
}

이에 따라 DataModule 클래스에도 위에서 작성한 UserLocalDataSource와 같이 UserMockDataSource 또한 인스턴스 생성 방법을 명시해야 한다. 하지만 Module은 기본적으로 동일한 반환타입을 가지는 메서드를 작성할 수 없기 때문에 Qualifier 어노테이션을 통해 Hilt가 어떤 메서드를 사용해야 하는지 식별할 수 있게 만들어주어야 한다.

@Module
@InstallIn(SingletonComponent::class)
abstract class RepositoryModule {
    @Qualifier
    @Retention(AnnotationRetention.BINARY)
    annotation class UserLocalDataSourceQualifier

    @Qualifier
    @Retention(AnnotationRetention.BINARY)
    annotation class UserMockDataSourceQualifier

    @Binds
    @UserLocalDataSourceQualifier
    abstract fun bindUserLocalDataSource(userLocalDataSource: UserLocalDataSource): UserDataSource

    @Binds
    @UserMockDataSourceQualifier
    abstract fun bindUserMockDataSource(userMockDataSource: UserMockDataSource): UserDataSource

    companion object {
        @Provides
        @Singleton
        fun provideDB(@ActivityContext context: Context): AppDatabase {
            return Room.databaseBuilder(
                context,
                AppDatabase::class.java, "User"
            ).build()
        }
    }

}

이제 아래와 같이 코드의 큰 수정 없이 UserRepository에서 주입 받을 UserDataSource에 대한 Qualifier 어노테이션 변경만으로 필요에 따른 각 유형에 해당하는 UserDataSource를 사용할 수 있다.

class UserRepository @Inject constructor(
    // @DataModule.UserLocalDataSourceQualifier
    @DataModule.UserMockDataSourceQualifier
    private val userDataSource: UserDataSource
) {
    suspend fun getUserList(): MutableList {
        return userDataSource.getUserList()
    }
}

8. Hilt가 지원하지 않는 클래스(ContentProvider)에 의존성 주입

Hilt 의존성 주입은 @HiltAndroidApp 어노테이션을 Application 클래스에 명시를 하면, Application onCreate() 가 호출되어 앱이 활성화되는 시점에 Hilt의 Component 클래스들이 자동으로 생성되어 의존성 주입을 관리하는 Hilt 코드에 의해 이루어진다.

하지만 ContentProvider는 Application보다 먼저 실행될 수 있으며 위에서 다루었던 생성자, 필드를 통한 주입이 불가능하다. 이에 따라 Hilt는 ContentProvider를 직접적으로 지원하지 않는다.

Hilt는 이러한 상황에서도 의존성 주입을 사용할 수 있도록 @EntryPoint를 제공한다.

[ContentProvider를 통한 데이터를 제공하는 앱]

class ExampleContentProvider : ContentProvider() {

    @EntryPoint
    @InstallIn(SingletonComponent::class)
    interface ExampleContentProviderEntryPoint {
        fun getAppDatabase(): AppDatabase
    }

    override fun query(uri: Uri,
                       projection: Array?,
                       selection: String?,
                       selectionArgs: Array?,
                       sortOrder: String?): Cursor? {
        ...

        return getAppDatabase().userDao().getUserList()
    }

    fun getAppDatabase(): AppDatabase {
        val appContext = context?.applicationContext ?: throw IllegalStateException()
        val hiltEntryPoint = EntryPointAccessors.fromApplication(
                appContext,
                ExampleContentProviderEntryPoint::class.java
            )

        return hiltEntryPoint.getAppDatabase()
    }
}

외부 앱에서 query 요청이 왔을 시 DB를 통해 Cursor를 반환하는 코드에서, AppDatabase를 주입 받기 위해 EntryPoint를 작성해야 한다. ExampleContentProviderEntryPoint와 같이 인터페이스로 선언 되어야 하며, @EntryPoint 어노테이션을 명시해야 한다. 작성한 EntryPoint는 EntryPointAccessors를 통해 접근이 가능하다.

query를 요청하는 앱으로 돌아가, 위 앱에서 제공하는 데이터를 읽어오는 코드를 작성해보자.

[ContentProvider를 통한 데이터를 제공받는 앱]

class UserProviderDataSource @Inject constructor(
    private val contentResolver: ContentResolver
) : UserDataSource {

    override suspend fun getUserList(): MutableList {
        val cursor = contentResolver.query(
            Constants.URI_EXAMPLE,
            arrayOf(AppDatabase.COL_USER_ID, AppDatabase.COL_USER_NAME),
            null,
            null,
            AppDatabase.COL_USER_ID)

        val userList = arrayListOf()

        cursor?.let {
            while (cursor.moveToNext()) {
                val id = cursor.getInt(cursor.getColumnIndex(AppDatabase.COL_USER_ID))
                val name = cursor.getString(cursor.getColumnIndex(AppDatabase.COL_USER_NAME))
                userList.add(User(id, name))
            }

            cursor.close()
        }

        return userList
    }
}


@Module
@InstallIn(SingletonComponent::class)
abstract class DataModule {

    ...

    @Qualifier
    @Retention(AnnotationRetention.BINARY)
    annotation class UserProviderDataSourceQualifier

    ...

    @Binds
    @UserProviderDataSourceQualifier
    abstract fun bindUserProviderDataSource(userProviderDataSource: UserProviderDataSource): UserDataSource

    companion object {

        ...

        @Provides
        fun provideContentResolver(@ApplicationContext context: Context): ContentResolver {
            return context.contentResolver
        }
    }

}

class UserRepository @Inject constructor(
//    @DataModule.UserLocalDataSourceQualifier
//    @DataModule.UserMockDataSourceQualifier
    @DataModule.UserProviderDataSourceQualifier
    private val userDataSource: UserDataSource
) {
    suspend fun getUserList(): MutableList {
        return userDataSource.getUserList()
    }
}

이제 위와 같이 UserRepository에서 주입 받을 UserDataSource Qualifier 어노테이션을 @UserProviderDataSourceQualifier로 변경하면 ContentProvider를 통한 데이터 조회가 이뤄진다.

9.ViewModel 의존성 주입

Hilt는 ViewModel을 포함한 Jetpack 라이브러리를 지원한다. MainActivity에서 Repository를 통해 데이터를 요청하는 비즈니스 로직을 ViewModel로 옮겨보자.

@HiltViewModel
class UserViewModel @Inject constructor(private val userRepository: UserRepository) : ViewModel() {
    val userLiveData = MutableLiveData>()
    val insertResultLiveData = MutableLiveData()

    fun getUserList() = viewModelScope.launch {
        userLiveData.value = userRepository.getUserList()
    }
}

ViewModel 클래스 상단에 @HiltViewModel 어노테이션을 명시하여 Hilt에게 ViewModel임을 알려주면, Hilt는 ViewModel임을 인식하고 ViewModel Factory를 자동으로 생성해 준다. 이와 함께 @Inject 어노테이션을 통해 생성자 주입이 가능하도록 설정해 주어야 한다. 이렇게 작성된 ViewModel은 @AndroidEntryPoint 어노테이션이 명시된 클래스에서 간단하게 사용할 수 있다.


@AndroidEntryPoint
class MainActivity : AppCompatActivity() {

    ...

    private val viewModel: UserViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
           ...

        viewModel.userLiveData.observe(this) {
            adapter.submitList(it.toMutableList())
        }

        viewModel.getUserList()
    }
}

Activity 또는 Fragment에서 ViewModelProvider를 통하지 않고 간단하게 by viewModels() 와 같은 형태로 간단하게 위임 지정이 가능하다.

[Annotation]

Hilt는 Annotation Processor를 통해 코드를 컴파일할 때 자동으로 생성하여 개발자가 수작업해야 하는 보일러 플레이트 코드를 줄여준다.

개발자는 어노테이션을 이용해 Hilt에게 아래와 같은 정보를 알려줄 수 있다.

의존성 주입을 사용할 안드로이드 클래스

의존성 주입이 필요한 변수
의존성 주입이 이뤄질 클래스를 인스턴스화 하는 방법
라이브러리에서 제공되는 클래스를 인스턴스화 하는 방법
추상 클래스나 인터페이스의 구현클래스를 인스턴스화 하는 방법
동일한 반환타입을 가지는 메서드에 대한 식별 방법
의존성 주입 인스턴스의 생성/소멸에 대한 생명주기

@HiltAndroidApp

Hilt를 활성화 시키는 기본 설정 어노테이션 최상위 계층인 Application을 상속받는 클래스에 @HiltAndroidApp 어노테이션을 선언 함으로써, Hilt가 의존성을 관리하는 데 사용되는 Hilt 컴포넌트들을 생성한다.

@AndroidEntryPoint

의존성 주입이 필요한 안드로이드 클래스에 선언하는 어노테이션 Hilt가 지원하는 Android 클래스를 상속받는 클래스에 @AndroidEntryPoint 어노테이션을 명시하면 Hilt의 관리 대상이 되며 명시한 클래스 내에서 의존성 주입을 사용할 수 있다. @AndroidEntryPoint어노테이션을 명시하면 해당 클래스가 의존하는 Android 클래스, 예로 Fragment에 해당 어노테이션을 명시할 경우 Fragment를 사용하는 Activity에도 어노테이션을 명시해야 한다.

Hilt가 지원하는 Android 클래스

Activity

Fragment

View

Service

BroadcastReceiver

💡 Android 클래스에 대한 Hilt 지원 예외 사항

Hilt는 AppCompatActivity와 같은 ComponentActivity를 확장하는 액티비티만 지원한다.

[DI] 의존성 주입의 이해와 필요성

Sun, 05 Feb 2023 09:46:10 GMT

의존성 주입(DI) = Dependency Injection

라이브러리를 사용하지 않고 의존성을 수동으로 주입하는 것을 "수동 의존성 주입"으로 명시하였으며, 의존성 주입 라이브러리를 통해 의존성을 자동으로 주입하는 것을 "자동 의존성 주입"으로 명시하였다.

[의존관계]

class Car {
    private val engine = Engine()

    fun wearSeatBelt() {
        println("안전벨트 착용")
    }

    fun start() {
        println("시동걸기")
        engine.start()
    }
}

fun main() {
    val car = Car()
    car.wearSeatBelt()
    car.start()
}

위 코드는 의존성 주입 없이 Car 내부에서 직접 Engine을 생성한다.
Car는 Egine을 사용하며, Car는 Egine에 의존한다. 라고 표현한다.

[의존성 주입이란?]

프로그램은 객체 간의 의존관계에 의해 동작하게 된다. 개발하면서 의존성은 필수적으로 작용하며 의존성 그 자체가 나쁜 것이 아니다. 다만 의존성이 높아지면 가독성, 재사용성, 확장성 등 유지보수함에 있어 어려움을 겪게 된다. 우리의 목표는 코드를 관리하기 쉽도록 객체 간의 의존성을 낮추고 최소화하는 것이다. 이를 돕기 위해 의존성 주입이라는 개념이 등장한다.

Car 클래스가 실행되기 위해서는 Engine 클래스의 인스턴스가 있어야 한다. Car 내부에서 직접 Engine을 생성하지 않고 외부에서 Engine을 생성하여 Car로 주입하는 것.

의존성 주입이란 이와같이 외부에서 인스턴스를 생성하여 주입하는 것이다.

[의존성 주입의 필요성]

프로젝트 규모가 커지게 되면, 위의 코드에서 세 가지 문제가 발생한다.

첫 번째. 본연의 역할 이상을 수행한다. 사실 Car는 부품을 사용하여 동작하는 역할만 하면 된다. 하지만 위 코드에서는 불필요하게 부품을 생성하고 관리하는 역할까지 맡고 있다. 자동차에는 엔진뿐만 아니라 여러 부품이 존재하며 부품들이 추가되면서 Car 클래스 내의 코드는 점점 거대해진다. SRP(Single Responsibility Principle)를 위반했기 때문이다.

두 번째. 변경에 민감하다 휘발유를 연료로 하는 가솔린 엔진 기준으로 엔진을 사용하였지만, 가스와 전기를 연료로 하는 엔진이 추가되었다고 하자. GasEngine, ElectricEngin만 추가하면 될 거로 생각하였지만, Car는 Engine에 대한 종속성이 높아 Car를 재사용할 수 없고 각 유형에 맞게 추가되고 변경되어야 한다.(GasCar, ElectricCar) OCP(Open Closed Principle)를 위반한 대가이다.

세 번째. 테스트가 어려워진다. 안전벨트 착용에 대한 테스트 코드를 작성해야 하는 상황에서 안전벨트는 엔진과 무관하다. 하지만 위 코드 구조에 의해 안전벨트 테스트를 위해 엔진을 신경 써야 하는 투머치한 상황이 발생한다. (실제 상황에서는 엔진을 생성하기 위해선 많은 과정이 필요할 것이다) 테스트 더블을 사용하여 Dummy 테스트가 불가한 것이다.

테스트 더블이란? 영화나 드라마에서 실제 배우가 연출하기 힘든 위험한 역할을 하는 'Stunt double'에서 유래된 말로, 실제 객체의 의도와 비슷해 보이게 동작하지만, 복잡성을 줄여 특정 상황에 대해 필요로 하는 부분에만 초점을 맞춘 단순화된 버전이며 다섯 가지 유형으로 나뉜다.

Dummy object
Test stub
Test spy
Mock object
Fake object

[수동 의존성 주입 방법]

아래 주요 두 가지 방법을 통해 간단하게 의존성 주입이 가능하다.

1. 생성자를 통한 의존성 주입 Car 객체 생성 시 생성자를 통해 Engine 객체를 전달받는다.

class Car(private val engine: Engine) {    
    fun wearSeatBelt() {
        println("안전벨트 착용")
    }

    fun start() {
        println("시동걸기")
        engine.start()
    }
}

fun main(args: Array) {
    val engine = Engine()
    val car = Car(engine)
    car.wearSeatBelt()
    car.start()
}

2. 필드 혹은 setter를 통한 의존성 주입 Car 객체 생성 후 필드나 Setter로 바로 접근하여 Engine을 주입한다.

class Car {
    lateinit var engine: Engine

    fun wearSeatBelt() {
        println("안전벨트 착용")
    }

    fun start() {
        println("시동걸기")
        engine.start()
    }
}

fun main(args: Array) {
    val car = Car()
    car.engine = Engine()
    car.wearSeatBelt()
    car.start()
}

이제 가스와 전기를 연료로 하는 엔진이 추가되어도 GasEngine, ElectricEngin 인스턴스를 생성하여 Car에 전달하여 Car를 재사용 할 수 있게 되었다. 또한 DummyEngine을 생성하여 안전벨트 테스트의 사전작업 환경을 손쉽게 만들 수 있다.

하지만 여전히 문제가 남아있다.

[수동 의존성 주입의 문제점]

무기를 사용하는 군인을 예시로 살펴보자.

fun main() {
    val bullet = Bullet()
    val gun = Gun(bullet)
    val knife = Knife()

    val weapon = Weapon(gun, knife)

    val soldier = Soldier(weapon)
}

첫 번째. 보일러플레이트 코드가 많아진다.

Soldier 객체를 생성하기 위해 무기 세팅하여 Soldier 객체를 생성하고 있다. 다른 곳에서 Soldier 객체를 생성하기 위해서 위와 같은 코드들을 중복으로 생성해야 한다.

두 번째. 객체 생성 순서에 영향을 받는다.

Weapon은 Soldier 객체를 생성하기 전에 생성해야 한다.
Gun, Knife는 Weapon 객체를 생성하기 전에 생성해야 한다.
Bullet은 Gun 객체를 생성하기 전에 생성해야 한다.

세 번째. 객체를 재사용하기 어렵다.

여러 곳에서 Soldier 객체를 재사용하려면 싱글톤 패턴을 따르게 해야 한다. 그렇게 되면 모든 테스트가 동일한 싱글톤 인스턴스를 공유하므로 테스트가 더 어려워진다.

수동 의존성 주입의 대안으로 서비스 로케이터패턴이 존재하지만, 테스트를 더 어렵게 만들고, 사용하는 서비스의 모든 사용자가 서비스 로케이터에 종속되어 의존관계를 파악하기 힘들게 된다.

서비스 로케이터란? 서비스 로케이터란 마틴 파울러가 제시한 디자인 패턴으로, 복잡성 및 객체 생성을 추상화하고 클라이언트에게 간단한 인터페이스를 제공하여 인스턴스를 반환한다. 이에 따라 클라이언트의 복잡성이 줄어들고 재사용할 수 있다는 장점이 있다. Mark Seemann 블로그에서는 Anti-Pattern이라는 비판을 받는 패턴이기도 하다.

[실제 앱 시나리오에 수동 의존성 주입]

실제 안드로이드 프로젝트는 일반적으로 구글에서 권장하는 위 아키텍처 그래프 모델과 비슷한 형태로 설계하게 된다. 실제와 비슷한 환경을 가정하여 수동 의존성 주입을 적용해보자.

위와 같은 로그인 비즈니스 플로우를 예시로 알아보자.

1. Repository 및 DataSource UserLocalDataSource와 UserRemoteDataSource에 의존하는 UserRepository 구현


class UserRepository(
    private val localDataSource: UserLocalDataSource,
    private val remoteDataSource: UserRemoteDataSource
) {
    ...
  }

class UserLocalDataSource { 
    ...
}

class UserRemoteDataSource(
    private val loginService: LoginRetrofitService
) {
    ...
  }

2. LoginViewModel 및 LoginData 로그인 시 사용되는 로그인 관련 Data와 로그인에 대한 비즈니스 로직을 담당하는 ViewModel 구현


class LoginData(private val userId: String,) {
    ...
}

class LoginViewModel(private val loginRepository: LoginRepository) {
    ...
}

3. Factory LoginViewModel이 많은 위치에 필요할 수 있으며, 다른 유형의 ViewModel이 생성될 것을 고려하여 추상 팩토리 디자인 패턴을 적용하여 ViewModel을 생성하는 Factory 구현


interface Factory {
    fun create(): T
}

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

4. LoginContainer

여러 곳에 파편화된 로그인 관련된 인스턴스 생성을 이 Container에 담아두고 관리
작업 유형별 Container의 수명관리를 위해 로그인 관련된 Container 구현


class LoginContainer(val userRepository: UserRepository) {

    val loginData = LoginUserData()

    val loginViewModelFactory = LoginViewModelFactory(userRepository)
}

5. AppContainer 여러 곳에 파편화된 앱 전반적인 인스턴스 생성을 이 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)

    val loginViewModelFactory = LoginViewModelFactory(userRepository)

    var loginContainer: LoginContainer? = null

}

6. Application AppContainer가 모든 Activity, Fragment 등 앱 전반에 걸쳐 사용할 수 있도록 Application 클래스에서 AppContainer 인스턴스를 생성한다.


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

7. LoginActivity

Application 인스턴스를 통해 AppContainer를 가져와 LoginViewModel 인스턴스 생성한다.
로그인 흐름이 시작될 때 LoginContainer를 생성하고, 흐름이 종료될 때 소멸시킨다.


class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel
    private lateinit var loginData: LoginUserData
    private lateinit var appContainer: AppContainer

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        appContainer = (application as MyApplication).appContainer

        appContainer.loginContainer = LoginContainer(appContainer.userRepository)

        loginViewModel = appContainer.loginContainer.loginViewModelFactory.create()
        loginData = appContainer.loginContainer.loginData
    }

    override fun onDestroy() {
        appContainer.loginContainer = null
        super.onDestroy()
    }
}

수동 의존성 주입에 대해 알아보았다. 위에서 언급한 문제점들과 인스턴스에 대한 수명주기를 수동으로 관리해야 하는 점으로 인해 다소 복잡해 지는 경향이 있다. 의존성 주입 라이브러리를 사용함으로써 문제점을 해결할 수 있다.

[자동 의존성 주입]

라이브러리를 통한 자동 의존성 주입은 적은 양의 코드로 클래스 간의 관계를 선언하고 의존관계와 수명주기를 설정하는 방법을 제공하여 의존성을 쉽게 관리할 수 있도록 도와준다.

아래 앱 크기에 따라 증가하는 비용 그래프를 통해 의존성 주입의 유형별 특성을 알아보자.

의존성 주입 유형 별 비교

수동 의존성 주입

수동 의존성 주입은 러닝 커브가 낮은 장점이 있다.
초기 비용이 들어가지 않지만, 앱 크기가 커질수록 수많은 보일러 플레이트 코드와 직접 관리 해야 할 작업이 늘어나 비용이 기하급수적으로 증가한다.
앱 규모가 작다면 서비스 로케이터나 자동 의존성 주입에 들이는 비용이 적기 때문에 오히려 적합한 방법이 될 수 있다.

서비스 로케이터

서비스 로케이터는 자동 의존성 주입에 비해 초기 비용이 적지만 앱이 커질수록 비용 곡선이 가파르게 상승하고 결국 수동 의존성 주입과 같은 문제에 직면하게 된다.

자동 의존성 주입 (Library)

자동 의존성 주입은 셋업시간이 꽤 걸려 초기 비용이 많이 든다.
하지만 앱이 커질수록 비용 곡선이 어느 정도의 선까지만 상승한다.
앱이 중간 정도의 크기로 갈수록 유지관리 비용이 다른 방법들과 큰 차이가 나지 않으며 일정 수준을 넘어설 경우 오히려 비용이 적게 드는 모습을 볼 수 있다.

의존성 주입 라이브러리 비교

안드로이드에서 의존성 주입의 인기가 증가함에 따라 의존성 주입 프로세스를 단순화하는 것을 목표로 하는 여러 라이브러리가 등장했다.

의존성 주입 라이브러리들 중 Koin, Hilt, Dagger에 대해 알아보자.

Dagger (2012)

컴파일 타임에 의존성을 관리해줄 코드를 검사하고 생성하여 런타임 예외가 발생하지 않아 정확성을 제공한다.
컴파일 타임에 오버헤드가 발생하나 런타임 시 빠르고 안정적으로 작동한다.
러닝 커브가 높다.

Dagger2의 등장 (2016) Dagger1은 부분적으로 리플렉션을 사용해 런타임 시 오버헤드가 발생하고 디버깅이 어려운 단점이 있었으며, 이러한 문제점을 보완하기 위해 4년 뒤 Dagger2가 공개되었다. Dagger2는 코드에 대한 추적을 쉽게 만들고 리플렉션을 사용하지 않고 어노테이션 프로세스를 적용하여 오버헤드를 런타임이 아닌 컴파일 타임으로 옮겨 런타임의 포퍼먼스를 향상 시켰다.

Koin(2017)

Kotlin DSL(Domain Specific Language)을 지원하여 직관적인 사용이 가능하다.
서비스 로케이터 패턴 기반으로 만들어져 요청이 들어왔을 때 인스턴스를 동적으로 반환하여 런타임에 의존성을 해결하며 컴파일 타임에 코드가 생성되지 않는다.
런타임에서 의존성을 해결하기 때문에 런타임 시 에러가 발생할 수 있으며 런타임 성능이 떨어진다.
다른 의존성 주입 라이브러리들에 비해 가볍고 가장 러닝 커브가 낮다.

Hilt(2020)

2019년 Google I/O에서 2020년부터 Android용 Dagger를 더 잘 만들 계획이라는 입장을 내놓았고, 2020년 Hilt를 공식적으로 발표하였다.
Dagger2를 기반으로 만들어졌기 때문에 Dagger의 장점을 모두 가지고 있다.
Dagger에서의 중복코드 발생과 복잡성을 개선하였으며, 최대 단점인 초기 셋업 비용을 감소시켰다.
Koin에 비해 러닝 커브가 높으나 Dagger에 비해 러닝 커브가 낮다.

Dagger와 Hilt를 번역하면 단검과 손잡이다. Hilt(손잡이)는 Dagger(단검)를 쉽게 사용하기 위해 만들어진 것이다.

의존성 주입을 잘 활용하면 느슨한 결합을 촉진하여 객체간 결합도를 줄이는데 도움이 되며 모듈성, 확장성, 가독성, 유지보수성을 향상시키는데 도움을 주는 등 여러 이점을 얻을 수 있다.

하지만 무조건적인 사용은 오버엔지니어링이 될 수 있으므로, 프로젝트 규모와 상황의 적합성을 잘 따져 배보다 배꼽이 더 큰 상황을 피하도록 하자.

참고자료

[Build - Error] Installed Build Tools revision 31.0.0 is corrupted. Remove and install again using the SDK Manager

Mon, 16 Jan 2023 10:44:34 GMT

Installed Build Tools revision 31.0.0 is corrupted. Remove and install again using the SDK Manager.

안드로이드스튜디오 1.4.3 버전 사용 중이었고 새로운 프로젝트를 생성할 때 해당 툴 버전에 의해 자동으로 TargetSDK가 31로 설정되었으며 빌드 시 위와 같은 에러가 발생하였다.

간단한 소스를 테스트하는 목적으로 사용하던 PC라 평소에는 TargetSDK를 다운그레이드시켜 작업하였으나, 원천적인 문제를 해결하고자 다른 방식으로 접근하였다.

Build Tool (31.0.0) 재설치

에러 메시지에서 가이드한 바와 같이 API Level 31에 해당하는 Build Tool Version을 제거 후 다시 설치해 보았으나 현상은 마찬가지였다.

AndroidStudio 업데이트

공식 사이트에 Android 12 사용 시 스튜디오 이전 버전과 호환되지 않는 사항이 존재한다고 명시되어있다.

이에 따라 안드로이드 스튜디오 버전을 '4.1.3' 버전에서 최신 버전인 'Dolphin'으로 업데이트해 보았지만 동일한 문제가 발생하였다.

안드로이드 스튜디오 버전명이 번호 지정 체계 업데이트 로 인해 영문으로 바뀌었다.

dx 파일 생성

에러 관련하여 검색해 볼 시 아래와 같은 절차로 수행하라고 나온다.

1) ".../Android/sdk/build-tools/" 진입 (Android SDK 폴더) 2) 31.0.0 폴더 진입 (에러가 발생하는 버전의 폴더) 3) d8.bat 파일을 복사하여 dx.bat 파일명으로 수정 4) lib 폴더에도 마찬가지로 d8.jar 파일을 복사하여 dx.jar 파일명으로 수정

위 절차대로 수행 한 이후 빌드 시 정상적으로 동작하는 것을 확인할 수 있었다.

Build-tool 31.0.0 is missing DX at /Users/gun/Developement/Android/build-tools/31.0.0/dx

실제 빌드 과정에서 위와 같은 메시지가 출력된다.

dx와 d8은 ".class" 바이트코드를 안드로이드 가상머신(ART or DVM) 용 ".dex" 바이트코드로 변환하는 프로세스 도구이며 dex 컴파일러라고 부른다. d8은 dx보다 더 빠르고 더 작은 크기로 dex 파일을 생성하는 더 우수한 성능을 보인다.
Android 측에서 이전부터 dx를 지원 중단할 예정이라 공식적으로 발표하였고, Android 스튜디오 3.1 버전부터 기본 dex 컴파일러로 D8이 적용되었다. 또한 Android 스튜디오 3.4 버전부터 기본 dex 컴파일러로 R8이 적용되었지만, 그리고 Android 12 (API Level 31) 버전부터 Android SDK 빌드 툴에 dx를 포함 시키지 않게 되었다.
[D8 dexer로 전환하는 Android Studio] (https://android-developers.googleblog.com/2018/04/android-studio-switching-to-d8-dexer.html)

.
.
.
그런데 다른 PC 환경에서는 이러한 별도의 세팅 없이 왜 동작하는 것일까?
.
.
.

Gradle 버전 업데이트

Google Issue Tracker에 동일한 이슈가 올라와 있다. Android 12 이상을 Target 할 경우 AGP 4.x 이하와 호환되지 않으니 AGP를 7.0 이상으로 업그레이드하라는 내용이다.

현재 Gradle 버전은 6.5, AGP 버전은 4.1.3으로 설정되어있음을 확인 후 Gradle 버전을 7.x 버전으로 업그레이드하였고 이후 빌드 시 정상적으로 동작하는 것을 확인할 수 있었다.

Android 스튜디오 Fox 버전으로 업데이트 되면 Gradle을 7.0 이상으로 설정하도록 가이드 해준다.

Gradle과 AGP(Android Gradle Plugin)

Gradle은 범용 빌드 자동화 도구이며 Android를 포함한 다양한 유형의 소프트웨어를 빌드하는데 사용되는 범용 빌드 자동화 도구이다.
AGP(Android Gradle Plugin)는 Android용으로 지원되는 빌드 시스템이다.
자세히 보기

[안드로이드 스튜디오 / Gradle / AGP 상호 호환 버전]