Android Dependency Injection: Hilt vs Koin - Kapsamli Rehber ve Mulakat Sorulari 2026

Android uygulamalarinda siniflar arasi bagimliliklarin nasil yonetildigi, projenin test edilebilirligini, bakimini ve olceklenmesini dogrudan belirleyen kritik bir mimari karardir. 2026 yilinda Android ekosisteminde iki framework bu alanda hakim konumdadir: Google tarafindan resmi olarak desteklenen ve Dagger altyapisina dayanan Hilt (surum 2.60.1) ile saf Kotlin DSL yaklasimini benimseyen Koin (surum 4.2.2). Her iki arac da bagimlilik enjeksiyonu sorununu cozmekle birlikte, derleme zamani guvenligi, calisma zamani performansi, ogrenme egrisi ve platform destegi acisindan temelden farkli tasarim tercihleri yapmaktadir. Bu rehber, her iki framework'u pratik kod ornekleri, performans olcumleri ve teknik mulakat sorulari esliginde derinlemesine incelemektedir.

Hilt Nasil Calisir: Derleme Zamani Kod Uretimi

Hilt, Dagger 2 uzerine insa edilmis ve Android yasam dongusu bilesenlerine eslenmis Dagger bilesenleri ureten bir DI framework'udur. @HiltAndroidApp anotasyonu, KSP (Kotlin Symbol Processing) araciligyla derleme zamaninda fabrikalar ve saglayicilar uretilmesini tetikler. Hilt 2.48 surumunden itibaren KSP, anotasyon islemcisi olarak KAPT'nin yerini almis ve isleme suresini yaklasik yariya indirmistir.

Tipik bir Hilt kurulumu uc temel bilesenden olusur: baglama tanimlarini iceren bir modul, bir giris noktasi (Activity, Fragment veya ViewModel) ve @HiltAndroidApp anotasyonuyla isaretlenmis Application sinifi.

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

    @Provides
    @Singleton
    fun provideRetrofit(): Retrofit {
        return Retrofit.Builder()
            .baseUrl("https://api.example.com/")
            .addConverterFactory(GsonConverterFactory.create())
            .build()
    }

    @Provides
    @Singleton
    fun provideUserRepository(
        retrofit: Retrofit
    ): UserRepository {
        return UserRepositoryImpl(retrofit.create(UserApi::class.java))
    }
}

@HiltViewModel
class UserViewModel @Inject constructor(
    private val userRepository: UserRepository
) : ViewModel() {

    private val _users = MutableStateFlow<List<User>>(emptyList())
    val users: StateFlow<List<User>> = _users.asStateFlow()

    fun loadUsers() {
        viewModelScope.launch {
            _users.value = userRepository.getUsers()
        }
    }
}

Derleyici, UserRepository icin gecerli bir saglayicinin mevcut olup olmadigini uygulama calistirilmadan once dogrular. Eksik baglamalar runtime cokmesi olarak degil, derleme hatasi olarak ortaya cikar.

Koin Kurulumu: Kotlin DSL ile Pragmatik Yaklasim

Koin, tam tersi bir felsefe izlemektedir: sifir kod uretimi, sifir anotasyon isleme. Bagimliliklar saf Kotlin DSL kullanilarak tanimlanir ve framework bunlari calisma zamaninda global bir servis kayit defteri uzerinden cozumler. Koin 4.2, baslatma sirasinda paralel yukleme icin lazy moduller ve kapsam cozumlemeyi optimize eden yeni CoreResolverV2 motorunu sunmaktadir.

val appModule = module {
    single<Retrofit> {
        Retrofit.Builder()
            .baseUrl("https://api.example.com/")
            .addConverterFactory(GsonConverterFactory.create())
            .build()
    }

    single<UserRepository> {
        UserRepositoryImpl(get<Retrofit>().create(UserApi::class.java))
    }

    viewModel { UserViewModel(get()) }
}

class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        startKoin {
            androidContext(this@MyApplication)
            modules(appModule)
        }
    }
}

DSL yapilandirmasi dogal bir Kotlin soz dizimi sunar ve Gradle yapilandirmasinda herhangi bir anotasyon isleme eklentisi gerektirmez. Odunlesim ise aciktir: get() cozumlemesindeki bir yazim hatasi, ancak ilgili enjeksiyon noktasi calistirildiginda ortaya cikar.

Performans Karsilastirmasi: Derleme Suresi ve Calisma Zamani Maliyeti

Performans sorusu, hemen her Android teknik mulakatinda gundeme gelmektedir. Somut rakamlar, subjektif degerlendirmelerden cok daha degerlidir.

100'den az baglama iceren projelerde Koin'in calisma zamani ek yuku algilanamaz duzeydedir. 300 baglama esigini asan projelerde ise baslatma maliyeti olculebilir hale gelir; ancak Koin 4.2'nin lazy modulleri, modul yuklemesini paralellestirerek bu etkiyi hafifletmektedir.

Test Stratejileri: Her Iki Framework'te Bagimlilik Degistirme

Test edilebilirlik, mimari farklarin pratik sonuclarinin en net goruldugu alandir. Hilt, uretim modullerinin test ikizleriyle derleme zamaninda degistirilmesi icin @TestInstallIn anotasyonu sunar. Koin ise loadKoinModules() ile tanimlarin calisma zamaninda gecersiz kilinmasina olanak tanir.

// Hilt test module
@Module
@TestInstallIn(
    components = [SingletonComponent::class],
    replaces = [AppModule::class]
)
object FakeAppModule {

    @Provides
    @Singleton
    fun provideUserRepository(): UserRepository {
        return FakeUserRepository()
    }
}

// Koin test
class UserViewModelTest : KoinTest {

    @Before
    fun setUp() {
        startKoin {
            modules(
                module {
                    single<UserRepository> { FakeUserRepository() }
                    viewModel { UserViewModel(get()) }
                }
            )
        }
    }

    @Test
    fun `loads users from repository`() {
        val viewModel: UserViewModel = get()
        viewModel.loadUsers()
        assertEquals(3, viewModel.users.value.size)
    }

    @After
    fun tearDown() {
        stopKoin()
    }
}

Hilt testleri, test modulleri hatali yapilandirildiginda sorunu derleme asamasinda tespit eder. Koin testleri, startKoin/stopKoin yasam dongusu yonetimi gerektirir; ancak kismi modul gecersiz kilma konusunda daha fazla esneklik sunar.

Coklu Modul Mimari: DI'nin Feature Modulleri Arasinda Olceklenmesi

Buyuk Android projeleri, ozellikleri bagimsiz Gradle modullerine ayirmaktadir. Kullanilan DI framework'unun modul sinirlarini temiz bir sekilde desteklemesi gerekmektedir. Her iki framework de modern Android modulerizasyonu kaliplariyla dogal bir uyum icerisindedir.

Hilt'te her feature modulu, @InstallIn ile uygun bilesene baglanan kendi @Module sinifini tanimlar. Hilt, derleme zamaninda tum modulleri tek bir bilesen hiyerarsisinde birlestirir. MVVM mimarisi, Hilt'in kapsamli bilesenleriyle dogal bir uyum gosterir.

@Module
@InstallIn(ViewModelComponent::class)
object PaymentModule {

    @Provides
    fun providePaymentGateway(
        retrofit: Retrofit
    ): PaymentGateway {
        return StripePaymentGateway(retrofit.create(PaymentApi::class.java))
    }
}

Koin'de feature modulleri, kendi module {} tanimlarini disar aktarir ve uygulama modulu bunlarin tumunu baslatma sirasinda yukler. Koin 4.2'nin lazy modulleri, feature modullerinin ilk erisime kadar ertelenmis yuklemesine olanak tanir.

val paymentModule = module {
    factory<PaymentGateway> {
        StripePaymentGateway(get<Retrofit>().create(PaymentApi::class.java))
    }
}

// app/MyApplication.kt
startKoin {
    modules(appModule, paymentModule, analyticsModule)
}

Hilt, bilesen kapsam mekanizmasi araciligiyla bagimlilik gorunurlugunu zorunlu kilar. Koin ise konvansiyona dayanir; herhangi bir modul, diger modullerin tanimlarina erisebilir. Bu durum esneklik saglamakla birlikte, ozellikle buyuk ekiplerde ortuk baglantilara yol acabilir.

Kotlin Multiplatform ve Platform Destegi

Koin, Kotlin Multiplatform (KMP) destegini dogal olarak sunmaktadir. Ayni module {} DSL yapisi Android, iOS, masaustu ve web hedeflerinde calismaktadir. Hilt ise yalnizca Android platformuna baglidir; Android'e ozgu yasam dongusu bilesenleri ve Dagger anotasyon islemcisine ihtiyac duyar.

Birden fazla platformu hedefleyen projelerde, bu iki framework arasinda Koin tek uygulanabilir secenektir. Paylasilan is mantigi modulleri, bagimlilik tanimlarini bir kez yaparak tum hedeflerde ayni enjeksiyon altyapisini kullanabilir.

Frameworklar Arasi Gecis

Koin 4.2, Dagger kopru modulu sunarak kademeli gecise olanak tanir. Hilt'ten Koin'e gecis yapan ekipler, gecis doneminde mevcut Dagger modullerini Koin'in servis bulucusu uzerinden kullanabilir. Bu artimsal yaklasim, buyuk capli bir yeniden yazimi onler ancak gecici mimari karmasiklik ekler.

Sikca Sorulan Mulakat Sorulari ve Yanitlari

Android teknik mulakatlarinda bagimlilik enjeksiyonu konusu duzgun sekilde ele alindiginda, adayin mimari bilgisinin derinligini gosterir. Asagida 2026 yilinda en sik karsilasilan sorular ve beklenen yanit cerceveleri yer almaktadir.

S: Derleme zamani ve calisma zamani bagimlilik enjeksiyonu arasindaki temel fark nedir?

Derleme zamani DI (Hilt/Dagger), derleme sirasinda enjeksiyon kodu uretir. Derleyici, bagimlilik grafinin tamamini dogrulayarak eksik baglama tanimlarini runtime'dan once yakalar. Calisma zamani DI (Koin), bagimliliklari ilk talep edildiklerinde bir servis kayit defteri uzerinden cozumler. Derleme zamani DI daha hizli baslatma saglar ancak derleme suresini arttirir; calisma zamani DI sifir derleme ek yuku getirir fakat hata tespitini ertelemis olur.

S: Hilt'te @InstallIn anotasyonu ne ise yarar ve hangi bilesenlere baglama yapilabilir?

@InstallIn, bir Hilt modulunun hangi Dagger bilesenine ait oldugunu belirler. SingletonComponent uygulama yasam dongusu boyunca, ActivityRetainedComponent yapilandirma degisikliklerinde hayatta kalir, ViewModelComponent bir ViewModel'in yasam dongusune baglidir. ActivityComponent, FragmentComponent ve ViewComponent ise ilgili Android yasam dongusu sahiplerine eslenir. Ozel kapsamlar bu hiyerarsiyi genisletebilir.

S: Koin'de ViewModel enjeksiyonu Jetpack Compose'da nasil gerceklesir?

Koin, en yakin ViewModelStoreOwner kapsaminda bir ViewModel olusturan veya mevcut ornegi getiren koinViewModel() Composable fonksiyonunu saglar. Koin 4.2 surumundan itibaren koinNavViewModel(), Jetpack Compose navigasyonu kullanildiginda ViewModel'leri navigasyon grafi girislerine kapsamlar. Koin 4.2 ayrica Jetpack Navigation 3 icin birinci sinif destek ekledi.

S: Koin'in Hilt'e gore avantajli oldugu senaryolar hangileridir?

Koin, KMP projelerinde (Hilt yalnizca Android destekler), derleme suresinin baslatma suresinden daha kritik oldugu kucuk-orta olcekli uygulamalarda ve anotasyon tabanli yapilandirma yerine acik Kotlin DSL tercih eden ekiplerde daha uygun bir secenektir. Prototipleme ve kavram kanitlama projeleri de Koin'in minimal kurulum gereksiniminden faydalanir.

Karar Matrisi: Hilt mi Koin mi?

Hicbir framework evrensel olarak ustun degildir. Dogru secim, projenin olcegine, ekibin deneyim duzeyine ve hedeflenen platformlara baglidir.

Kaynaklar

• Dagger 2.60 Surum Notlari - minSDK 23 gereksinimi, parametresiz @Binds, AGP 9 destegi
• Koin 4.2 Surum Notlari - CoreResolverV2, Dagger koprusu, Navigation 3 destegi
• Koin Dagger Entegrasyon Dokumantasyonu - Kademeli gecis icin kopru modulu

Hilt vs Koin Icin Temel Cikarimlar

• Hilt 2.60 ile KSP, derleme zamani graf dogrulamasi ve sifira yakin baslatma maliyeti sunarak, siki guvenilirlik gereksinimleri olan buyuk, tek platformlu Android projeleri icin guclu bir tercih olmaya devam etmektedir, ancak artik minSDK 23 ve AGP 9+ gerektirmektedir
• Koin 4.2, lazy moduller, CoreResolverV2 ve yeni Dagger koprusu ile baslatma performansi farkini kapatirken sifir derleme ek yuku ve tam KMP uyumlulugu saglamaktadir
• Her iki framework de coklu modul mimarileri desteklemektedir; ancak Hilt kapsam sinirlarini derleme zamaninda zorunlu kilarken, Koin ekip konvansiyonlarina dayanmaktadir
• Android mulakat hazirliginda derleme zamani ve calisma zamani DI arasindaki odunlesimi anlamak ve her bir framework'un hangi senaryoda daha uygun oldugunu ifade edebilmek, beklenen temel yetkinlik duzeyi olarak kabul edilmektedir
• Frameworklar arasi gecis basit bir islem degildir, ancak Koin'in Dagger koprusu artik Hilt'ten uzaklasan ekipler icin kademeli bir yol sunmaktadir