Налаштування Dependency Injection (Dagger 2) в Android-додатку

Ми стикаємося з проектами, де Dagger 2 додають в середині розробки. Результат — заплутаний граф, витоки пам'яті та баги, які неможливо відтворити локально. Dagger генерує код під час компіляції — жодної рефлексії, але за цю безпеку платимо архітектурною дисципліною. Наш досвід: налаштування з нуля займає 3–5 днів, а рефакторинг хаотичного впровадження — від тижня. За більш ніж 5 років роботи ми налаштували Dagger на 30+ проектах різного масштабу — від стартапів до enterprise-додатків. Гарантуємо чистий DI-код без сюрпризів у рантаймі. Отримайте консультацію по вашому проекту: замовте аналіз поточної архітектури.

Як правильно спроектувати граф компонентів?

Стандартна схема для великого додатка: AppComponent (Singleton) → ActivityComponent (PerActivity) → FragmentComponent (PerFragment). Кожен рівень — сабкомпонент або залежний компонент. Помилка архітектури — поміщати всі залежності в AppComponent, що збільшує час збірки та ускладнює тестування.

@Singleton
@Component(modules = [AppModule::class, NetworkModule::class, DatabaseModule::class])
interface AppComponent {
    fun inject(app: App)
    fun activityComponentBuilder(): ActivityComponent.Builder
}

@Module
class NetworkModule {
    @Provides
    @Singleton
    fun provideOkHttpClient(): OkHttpClient {
        return OkHttpClient.Builder()
            .addInterceptor(AuthInterceptor())
            .connectTimeout(30, TimeUnit.SECONDS)
            .build()
    }

    @Provides
    @Singleton
    fun provideRetrofit(client: OkHttpClient): Retrofit {
        return Retrofit.Builder()
            .baseUrl(BuildConfig.API_URL)
            .client(client)
            .addConverterFactory(GsonConverterFactory.create())
            .build()
    }
}

Чому скоупи — часта причина важковловимих багів?

Найчастіша помилка — неправильні скоупи. Якщо UserRepository оголошено @Singleton, а AuthToken всередині нього зберігається в пам'яті, то після logout без перестворення компонента старий токен залишається в живому об'єкті. Це призводить до запитів з чужим токеном — продакшн-баг, який відтворюється лише при конкретному сценарії. Рішення: @Singleton-компоненти не повинні містити змінного стану, що залежить від сесії користувача. Сесійні залежності виносяться в @UserScope:

@Scope
@Retention(AnnotationRetention.RUNTIME)
annotation class UserScope

@UserScope
@Subcomponent(modules = [UserModule::class])
interface UserComponent {
    @Subcomponent.Factory
    interface Factory {
        fun create(@BindsInstance userId: String): UserComponent
    }

    fun inject(profileFragment: ProfileFragment)
}

UserComponent створюється після логіну, знищується після logout. Всі залежності, прив'язані до користувача, живуть рівно стільки, скільки потрібно. Нижче таблиця типових помилок:

Додатково варто згадати, що неправильне використання скоупів може призвести до витоків пам'яті через випадкове захоплення Activity контексту в @Singleton. Ми завжди перевіряємо граф на такі сценарії.

Multibindings та плагінна архітектура

@IntoMap з @ViewModelKey — паттерн для інжекції ViewModels через ViewModelProvider.Factory. Dagger створює Map<Class<out ViewModel>, Provider<ViewModel>>, фабрика обирає потрібний клас. Без цього паттерна кожну ViewModel доводиться окремо оголошувати в компоненті.

@Module
abstract class ViewModelModule {
    @Binds
    @IntoMap
    @ViewModelKey(LoginViewModel::class)
    abstract fun bindLoginViewModel(vm: LoginViewModel): ViewModel

    @Binds
    @IntoMap
    @ViewModelKey(ProfileViewModel::class)
    abstract fun bindProfileViewModel(vm: ProfileViewModel): ViewModel
}

Цей же підхід застосовний для плагінної архітектури, де кожен модуль реєструє свої залежності через @IntoSet або @IntoMap. Ми використовували це в проекті з 10+ фіч-модулями — Dagger автоматично збирає всі надані реалізації.

Kapt та KSP: що обрати для збірки?

Dagger 2 традиційно працює з kapt. Починаючи з версії 2.50 доступна експериментальна підтримка KSP, яка прискорює інкрементальні збірки. На проекті з ~200 Dagger-аннотаціями перехід з kapt на KSP скоротив час clean build з 4.5 до 2.8 хвилин — економія часу розробки значна.

// build.gradle.kts
plugins {
    id("com.google.devtools.ksp")
}

dependencies {
    implementation("com.google.dagger:dagger:2.51")
    ksp("com.google.dagger:dagger-compiler:2.51")
}

Також варто пам'ятати про обфускацію: ProGuard/R8 можуть видалити класи, створені Dagger, якщо не додати правила keep. Ми включаємо це в конфігурацію.

Як тестувати додаток з Dagger?

Dagger і тести — окрема історія. Стандартний підхід: тестові модулі, які замінюють продакшн-залежності на фейки:

@Component(modules = [TestNetworkModule::class, DatabaseModule::class])
interface TestAppComponent : AppComponent

@Module
class TestNetworkModule {
    @Provides
    @Singleton
    fun provideApiService(): ApiService = FakeApiService()
}

В Espresso-тестах DaggerTestAppComponent підставляється замість основного в App.appComponent до запуску тесту. Без цієї заміни інтеграційні тести йдуть на реальний сервер. Ми також використовуємо TestCoroutineDispatcher для імітації затримок.

Коли обирати Dagger 2, а не Hilt

Hilt — обгортка над Dagger з попередньо заданою структурою компонентів. Якщо потрібні нестандартні скоупи, мультимодульний граф з незалежними компонентами або Dagger вже в проекті — Dagger 2 дає повний контроль. Hilt швидше стартує, але обмежує в складних архітектурах. У наших проектах ми часто комбінуємо Dagger з Hilt в різних модулях.

Що входить в налаштування Dagger 2 під ключ

• Аналіз архітектури та проектування графа компонентів
• Створення модулів для мережі, БД, shared preferences
• Налаштування скоупів (Singleton, PerActivity, UserScope)
• Інтеграція з ViewModel через мультибіндинг
• Конфігурація тестового компонента з фейками
• Перехід з kapt на KSP за потреби
• Документація по підтримці графа

Вартість розраховується індивідуально. Налаштування з нуля — 3–5 днів, рефакторинг — від тижня. Отримайте консультацію: напишіть нам, оцінимо ваш проект. Хочете впровадити Dagger 2 без головного болю? Зв'яжіться з нами, ми проведемо аудит вашого DI-коду.