Uygulama geliştirmede Reflection — nedir, yansıma mekanizmaları ve nasıl uygulanır

Reflection nedir?

Reflection, bir programın çalışma sırasında kendi yapısını ve davranışını gözlemleme ve değiştirme yeteneğidir. Nesne yönelimli dillerde bu, program öğelerini okuma ve çağırma için kullanılabilir veriler olarak temsil eden Class, Method, Field ve Constructor nesnelerini elde etmek anlamına gelir.

“reflection” terimi 1982'de yapay zekâ topluluğunda (Brian Cantwell Smith) tanıtıldı ve Smalltalk dilinde uygulandı. Mobil geliştirmede reflection ilk olarak Java ME ve Objective-C'de (1986, NextStep) ortaya çıktı. Bugün her büyük mobil platformun kendi reflection API'si vardır: Android için Java/Kotlin, iOS için Objective-C Runtime, Swift için Swift Mirror API.

Reflection mekanizması, derleyicinin bayt kodu veya ikili dosyada sakladığı meta verilere dayanır. Android, sınıflar hakkındaki tam bilgiyi DEX dosyalarında saklar; iOS ise Mach-O segmentinin __objc_classlist bölümünde saklar. Çalışma zamanı bu meta verileri belleğe yükler ve bunları gezinmek için bir API sağlar.

Java ve Kotlin'de Reflection nasıl çalışır

Java Reflection API, java.lang.Class sınıfı etrafında inşa edilmiştir. Java'daki herhangi bir nesne, .getClass() veya Class.forName() aracılığıyla Class'a dönüştürülebilir. Class'tan tüm metotlar, alanlar, yapıcılar, ek açıklamalar ve üst sınıflar çıkarılır. Kotlin, Java reflection'ını miras alır ve kotlin.reflect paketinden kendi KClass, KFunction, KProperty öğelerini ekler.

import kotlin.reflect.full.declaredMemberFunctions

data class User(
    val name: String,
    val email: String
)

fun inspectClass() {
    val kClass = User::class
    val properties = kClass.declaredMemberProperties
    val functions = kClass.declaredMemberFunctions

    properties.forEach { prop ->
        println("Özellik: ${prop.name}, tür: ${prop.returnType}")
    }
}

Bu örnekte KClass, data class User için meta verileri sağlar. declaredMemberProperties, türleri ve getter'larıyla birlikte özelliklerin listesini döndürür. Kotlin yansıması coroutine'lerle yakından entegredir: KFunction, suspend değiştiricisini destekler; bu da reflection aracılığıyla zaman uyumsuz metotların çağrılmasını sağlar.

Java Reflection: Class, Method, Field

Java reflection'ı, Class<?>, Method.setAccessible() ve Field.get() ile çalışır. setAccessible(true), özel öğeler için Java dili erişim kontrolü kontrollerini devre dışı bırakır. Bu güçlü ancak tehlikeli bir mekanizmadır: Android'de API 28'den itibaren gizli sistem metotlarında setAccessible çağrısı InaccessibleObjectException'a neden olabilir.

// Java reflection: özel bir metot çağrısı
Class clazz = Class.forName("com.example.MyClass");
Object instance = clazz.getDeclaredConstructor().newInstance();
Method method = clazz.getDeclaredMethod("privateMethod", String.class);
method.setAccessible(true);
method.invoke(instance, "reflection test");

Kod, Class.forName() öğesini gösterir — bir sınıfın dize adıyla dinamik olarak yüklenmesi. Bu, eklenti mimarilerinin temelidir: bir sınıf derleme zamanında bilinmeyebilir, ancak çalışma zamanında reflection aracılığıyla yüklenip yürütülebilir. getDeclaredMethod(“privateMethod”, ...) bir metodu adına ve parametre türlerine göre bulur, invoke ise onu yürütür.

Objective-C Runtime: alternatif bir yansıma modeli

Objective-C çalışma zamanı, class_copyMethodList, class_copyPropertyList, objc_getAssociatedObject işlevlerini sağlar. Java'dan farklı olarak Objective-C, özel metotları varsayılan olarak gizlemez — çalışma zamanı sınıfın tüm metotlarını görür. Bu, method swizzling'in neden setAccessible olmadan çalıştığını açıklar: çalışma zamanında meta veri düzeyinde kapsülleme yoktur.

Mobil geliştirmede Reflection'ın kullanımı

Reflection, mobil geliştirmenin önemli kütüphanelerinde kullanılır. JSON serileştirme (Gson, Moshi, Kotlinx.serialization), reflection aracılığıyla nesnenin özelliklerini elde eder ve JSON anahtarlarıyla eşleştirir. Bağımlılık enjeksiyonu (Dagger, Koin, Swinject), otomatik bağımlılık enjeksiyonu için yapıcıları ve alanları analiz eder. ORM kütüphaneleri (Room, Realm), sınıfları veritabanı tablolarına eşlemek için reflection kullanır.

• Serileştirme — Gson, Field.get() aracılığıyla bir nesnenin bildirilen alanlarını okur ve @SerializedName ek açıklamalarına göre JSON oluşturur.
• Bağımlılık enjeksiyonu — Dagger, ek açıklama işleme yoluyla kod üretir; Koin, çalışma zamanı çözümleme için Kotlin reflection'ını kullanır.
• Test — JUnit, reflection ile @Test içeren metotları bulur ve çağırır; Mockito, dinamik proxy aracılığıyla mock oluşturur.
• Veritabanı — Room, Entity alanlarını Class.getDeclaredFields() aracılığıyla derleme zamanında kontrol eder (KAPT/KSP ile).
• Analitik ve izleme — Firebase Crashlytics, reflection'a dayanan Throwable.getStackTrace() aracılığıyla yığın izini elde eder.

Bu kullanımların her biri tam olarak çalışma zamanında çalışır — kod hangi sınıflarla karşılaşacağını önceden bilmez. Reflection, bu belirsizliği aşmak için performans ve güvenlik pahasına evrensel bir mekanizma sağlar.

Reflection performansı: dinamik erişimin maliyeti

Reflection, doğrudan metot çağrılarından 10–100 kat daha yavaştır. Neden, JIT optimizasyonlarının (devirtualization, inlining) olmaması, her çağrıda tür kontrolü ve parametrelerin Object[]/varargs içine paketlenmesidir. Android 14'teki ART, hedef metot yürütme anına kadar bilinmediği için reflection çağrılarını satır içi optimize edemez.

Veriler bir Google Pixel 8'de (Android 14, ART) elde edilmiştir. Reflection performansı her Android sürümüyle iyileşir: Android 9'da Method.invoke() aracılığıyla çağrı, doğrudan çağrıdan 150 kat daha yavaştı; Android 14'te 40 kat. ART, optimizasyon için yerleşik method handle mekanizmalarını kullanır.

Performans açısından kritik bölümlerde geliştiriciler reflection'ı kod üretimiyle değiştirir: Dagger, çalışma zamanı araması yerine ek açıklama işlemeyi kullanır; Kotlinx.serialization, KSP aracılığıyla serileştiricileri üretir; Moshi, derleme zamanı codegen için @JsonClass(generateAdapter = true) değerini uyarlar.

Reflection alternatifleri: ek açıklamalar ve kod üretimi

Ek açıklama işleme (KAPT, KSP) ve kod üretimi, mobil geliştirmede reflection'ın ana alternatifleridir. Bunlar meta veri analizini çalışma zamanından derleme zamanına taşır: kod, uygulama başlatılmadan önce üretilir; bu da reflection yükünü ortadan kaldırır ve performansı artırır.

// KSP: reflection yerine kod üretimi
@Serializable
data class Config(
    val apiUrl: String,
    val timeout: Int
)

// KSP, reflection olmadan ConfigSerializer üretir
fun loadConfig(json: String): Config {
    return Config.serializer().decodeFromString(json)
}

Bu örnekte @Serializable, Kotlinx.serialization ek açıklamasıdır. KSP (Kotlin Symbol Processing), kaynak kodu derleme zamanında analiz eder, tüm @Serializable sınıflarını bulur ve serileştiricileri üretir. Uygulama çalışması sırasında reflection kullanılmaz — serileştirici zaten makine koduna derlenmiştir.

Yaklaşımların karşılaştırılması

Kod üretimi daha iyi performans, tür güvenliği ve daha küçük ikili dosya boyutu sağlar (ölü kod temizleme, kullanılmayan reflection bağımlılıklarını kaldırır). Reflection, türlerin derleme zamanında bilinmediği görevler için gerekli kalır: dinamik eklenti yükleme, çalışma zamanı proxy'leri, test enstrümantasyonu. Kotlin'e göre, KSP ile Kotlinx.serialization, reflection'a dayanan Gson'dan 3–5 kat daha hızlıdır.

Android ve iOS'ta Reflection sınırlamaları

Mobil platformlarda Reflection'ın güvenlik ve performans sınırlamaları vardır. Android, API 28'den (Pie) itibaren SDK dışı arayüzler için setAccessible'ı kısıtlar — gizli bir sistem metodunu açma girişimi bir istisna veya uyarıya neden olur. Swift ile iOS, klasik anlamda reflection'ı desteklemez: Swift Mirror API yalnızca özelliklerin (name, value) okunmasını sağlar; değiştirme veya metot çağrısı olmadan.

Google Play, platform kısıtlamalarını aşmak için reflection kullanan uygulamaları reddeder: sistem hizmetlerini değiştirme, SELinux politikalarını değiştirme, korumalı izinleri okuma. Apple da reflection aracılığıyla özel API'leri çağıran uygulamaları engeller — App Review denetimi, bilinen özel seçicilere sahip objc_msgSend dize imzalarını ikili dosyada tarar.

ProGuard/R8 başka bir sınırlamadır. Karartma ve kod küçültme, sınıfları ve metotları kısa adlara (a, b, c) yeniden adlandırır. Kod Class.forName(“com.example.MyClass”) kullanıyorsa, karartmadan sonra bozulur. Çözüm, proguard-rules.pro içindeki keep kurallarıdır:

// reflection için ProGuard keep kuralları
-keep class com.example.** { *; }
-keep class * implements java.io.Serializable { *; }
-keepclassmembers class * {
    @com.google.gson.annotations.SerializedName ;
}
-keepattributes Signature, InnerClasses, EnclosingMethod

-keep kuralları, R8'e reflection aracılığıyla kullanılan sınıfları yeniden adlandırmamasını söyler. Bu kurallar olmadan, karartılmış bir uygulama ClassNotFoundException ile çöker — çalışma zamanı, değişen dize adıyla sınıfı bulamaz.