Какие знаешь аналоги Hilt?

Аналоги Dagger Hilt для внедрения зависимостей в Android

Dagger Hilt — это официальная библиотека от Google, построенная поверх Dagger 2, которая значительно упрощает настройку и использование dependency injection (DI) в Android-приложениях. Однако экосистема Android предлагает и другие достойные альтернативы, каждая со своей философией, синтаксисом и компромиссами. Вот основные аналоги, которые я знаю и использовал в своей практике.

1. Dagger 2 (Core)

Это основа, на которой построен Hilt. Hilt — это essentially "обёртка" с предопределёнными компонентами и скоупами для Android.

• Отличие: Требует ручного создания графа зависимостей (Component, Subcomponent) и его управления в Android-классах (Activity, Fragment).
• Когда выбирать: Для максимального контроля и сложных кастомизаций DI графа, которые могут выходить за рамки стандартных сценариев Android.
• Пример настройки компонента (без Hilt):

@Component(modules = [NetworkModule::class])
interface AppComponent {
    fun inject(activity: MainActivity)
}

@Module
class NetworkModule {
    @Provides
    fun provideRetrofit(): Retrofit { /* ... */ }
}

// В Activity
class MainActivity : AppCompatActivity() {
    @Inject lateinit var viewModel: MainViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        (application as MyApp).appComponent.inject(this)
        super.onCreate(savedInstanceState)
    }
}

2. Koin

Пожалуй, самый популярный "лёгкий" аналог Hilt, написанный чисто на Kotlin с использованием функциональных возможностей языка.

• Философия: Прагматичный, DSL-ориентированный подход. Вместо генерации кода (как Dagger) использует runtime-резолвинг зависимостей с помощью паттерна Service Locator.
• Преимущества: Прост в изучении, минимальный boilerplate, отлично интегрируется с Kotlin Coroutines и Flow.
• Недостатки: Нет статической проверки графа зависимостей на этапе компиляции (это главный аргумент сторонников Dagger). Может влиять на время старта приложения при огромном графе.
• Пример модуля и инъекции:

// Объявление модуля
val appModule = module {
    single { Retrofit.Builder().baseUrl("https://api.example.com/").build() }
    factory { (id: Int) -> DetailViewModel(id, get()) }
    viewModel { MainViewModel(get()) }
}

// Старт в Application
class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        startKoin {
            androidContext(this@MyApp)
            modules(appModule)
        }
    }
}

// Инъекция во ViewModel (автоматическая)
class MainViewModel(private val apiService: ApiService) : ViewModel()

3. Kodein (Kodein-DI)

Ещё одна популярная Kotlin-first библиотека. Имеет очень выразительный и гибкий DSL.

• Особенность: Предлагает различные "привязки" (binding) с разным контекстом и скоупингом. Может работать в мультиплатформенных проектах (KMM).
• Синтаксис: Часто более краткий, чем Koin, но с немного иной концепцией "контейнеров".
• Пример:

val di = DI {
    bind<Retrofit>() with singleton { Retrofit.Builder().build() }
    bind<ApiService>() with provider { instance<Retrofit>().create(ApiService::class.java) }
}

class MyRepository(di: DI) {
    private val apiService: ApiService by di.instance()
}

4. Toothpick

Библиотека, которая была довольно популярна до появления Hilt. Использует reflection, но активно применяет скоупы.

• Ключевая фича: Позволяет легко создавать и уничтожать подграфы зависимостей (scopes), что удобно для Flow-архитектур.
• Статус: В настоящее время её разработка замедлилась, так как сообщество сместилось в сторону Hilt и Koin.

5. Service Locator (Кастомная реализация)

Паттерн, который иногда используется как упрощённая альтернатива полноценному DI-фреймворку, особенно в небольших проектах или для конкретных задач.

• Суть: Создание центрального реестра (контейнера), который хранит и предоставляет зависимости по запросу.
• Минус: Скрывает зависимости класса, усложняет тестирование (нужно мокировать весь локатор).
• Простой пример:

object ServiceLocator {
    private val services = mutableMapOf<String, Any>()

    fun <T : Any> register(name: String, service: T) {
        services[name] = service
    }

    fun <T> get(name: String): T {
        return services[name] as T
    }
}

Сравнительная таблица и рекомендации по выбору

Мои рекомендации по выбору:

1. Для новых проектов и команд, стремящихся к стандарту — берите Hilt. Это будущее DI в Android от Google, отличная интеграция с ViewModel, WorkManager, тестами. Статическая проверка зависимостей предотвращает множество runtime-ошибок.
2. Для быстрого прототипирования, небольших проектов или команд, глубоко погружённых в Kotlin — Koin будет отличным, менее вербозным выбором.
3. Для сложных мультимодульных проектов с кастомными требованиями к графам — стоит рассмотреть чистый Dagger 2 или, возможно, Kodein.
4. Для поддержки legacy кода — если в проекте уже используется Dagger 2, миграция на Hilt будет наиболее гладкой.

В конечном счёте, выбор между Hilt и его аналогами — это компромисс между строгостью и безопасностью на этапе компиляции (Dagger/Hilt) и простотой и скоростью разработки (Koin/Kodein). В современной Android-разработке Hilt становится де-факто стандартом благодаря официальной поддержке и глубокой интеграции с компонентами Jetpack.