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.57.1) ile saf Kotlin DSL yaklasimini benimseyen Koin (surum 4.2.1). 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))
    }
}

@InstallIn(SingletonComponent::class) ifadesi, bu moduldeki tum baglama tanimlarinin uygulama yasam dongusu boyunca gecerli olacagini belirtir. @Provides metodlari, Hilt'e her bir bagimlilik icin somut orneklerin nasil olusturulacagini bildirir.

@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()) }
}

single blogu singleton kapsami, viewModel blogu ise Android ViewModel kapsaminda ornek olusturma saglar. get() fonksiyonu, kayit defterinden ilgili bagimliliga ait ornegi ceker.

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.

| Metrik | Hilt 2.57 (KSP) | Koin 4.2 | |--------|-----------------|----------| | Temiz derleme ek yuku | +8-15s (KSP kod uretimi) | ~0s (kod uretimi yok) | | Artimli derleme ek yuku | +2-4s | ~0s | | Uygulama baslatma (50 baglama) | ~0ms (onceden uretilmis kod) | ~5-15ms (graf cozumleme) | | Uygulama baslatma (500 baglama) | ~0ms | ~30-80ms | | APK boyut etkisi | +200-400 KB (uretilmis kod) | +100 KB (runtime kutuphanesi) | | Eksik baglama tespiti | Derleme hatasi | Runtime cokmesi |

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()
    }
}

Hilt'te test modulu hatali yapilandirildiginda, sorun derleme asamasinda tespit edilir. Uretim koduna sahte bir bagimlilik sizmasinin onune tip sistemi duzeyde gecilmis olur.

// 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()
    }
}

Koin testleri, startKoin/stopKoin yasam dongusu yonetimi gerektirir; ancak kismi modul gecersiz kilma konusunda daha fazla esneklik sunar. Her iki yaklasimdaki avantaj ve sinirliliklar, projenin test stratejisi belirlenirken dikkate alinmalidir.

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.

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 tanimlarinsa erisebilir. Bu durum esneklik saglamakla birlikte, ozellikle buyuk ekiplerde ortuk baglantilara (implicit coupling) yol acabilir.

Kotlin Multiplatform ve Platform Destegi

Koin, Kotlin Multiplatform (KMP) destegini doganin bir parcasi 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.

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 girislerin kapsamina alir.

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?

| Faktor | Hilt | Koin | |--------|------|------| | Graf dogrulama | Derleme zamani | Calisma zamani | | Derleme suresine etkisi | Yuksek (KSP codegen) | Yok | | Baslatma maliyeti | Sifira yakin | Graf boyutuyla orantili | | Ogrenme egrisi | Dik (Dagger kavramlari) | Yumusak (saf Kotlin DSL) | | KMP destegi | Yok | Tam destek | | Jetpack entegrasyonu | Derin (resmi Google destegi) | Iyi (topluluk destegi) | | Ekip olceklenebilirligi | Guclu (zorunlu kapsamlar) | Esnek (konvansiyon tabanli) | | Test altyapisi | @TestInstallIn (derleme guvenli) | loadKoinModules (runtime) |

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

Sonuc

• Hilt 2.57, KSP ile birlikte derleme zamani graf dogrulamasi ve sifira yakin baslatma maliyeti sunarak buyuk olcekli, tek platformlu Android projelerinde guvenilirlik oncelikli secim olma konumunu surdurmektedir
• Koin 4.2, lazy moduller ve CoreResolverV2 motoru ile baslatma performansi farkini kapatirken, sifir derleme ek yuku ve tam KMP uyumlulugu saglamaya devam etmektedir
• 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
• Framework'lar arasi gecis basit bir islem degildir; bu nedenle ilk tercih, projenin uzun vadeli platform stratejisi ve olceklenme plani goz onunde bulundurularak yapilmalidir