Mobil geliştirmede Runtime: runtime sistemi nedir ve nasıl çalışır

Mobil geliştirmede Runtime nedir?

Runtime, programın başlatılmasından sonra çalışmasını sağlayan altyapıdır. Mobil geliştirme bağlamında, runtime sınıf yükleyici, bellek ayırıcı, çöp toplayıcı, metot dağıtıcı ve istisna işleyiciyi içerir. Bu ara katman olmadan, işletim sistemi Dalvik bayt kodunu veya Objective-C mesajlarını çalıştıramaz.

Mobil platformlar farklı runtime uygulamaları kullanır. Android, hibrit AOT/JIT derlemesi ile ART (Android Runtime) kullanır. iOS, mesaj iletimi ve SEL tanımlayıcılarına dayalı dinamik bir sistem olan Objective-C Runtime'ı kullanır. Her iki yaklaşım da aynı sorunu çözer: geliştiricinin kodunu belirli bir cihazda maksimum performansla çalıştırmak.

Google I/O 2024'e göre, Android Runtime dünya çapındaki cihazlarda günde 10 milyardan fazla metot işler. Runtime performansı, uygulama başlatma hızını, animasyonların akıcılığını ve pil tüketimini doğrudan etkiler. Her metot çağrısı, her bellek tahsisi ve her çöp toplama döngüsü runtime katmanından geçer.

Runtime sistemi: hangi bileşenlerden oluşur

Runtime sistemi beş temel bileşen içerir: sınıf yükleyici, bellek yöneticisi, yorumlayıcı veya derleyici, metot dağıtıcı ve güvenlik sistemi. Her bileşen, kod yürütme sürecinde kesin olarak tanımlanmış bir işlevi yerine getirir.

Sınıf yükleyici ve doğrulama

Bir kullanıcı uygulamayı başlattığında, ClassLoader DEX dosyalarını (Android) veya Mach-O ikili dosyalarını (iOS) RAM'e yükler. Android'de bu aşama bayt kodu doğrulamasını içerir: runtime, kodun güvensiz talimatlar içermediğini, dizi sınırlarını aşmadığını ve türlere uyduğunu kontrol eder. Doğrulama, kötü amaçlı kod çalıştırılmasını önleyen kritik bir güvenlik adımıdır.

Bellek yöneticisi ve çöp toplayıcı

Bellek yöneticisi nesneler için bellek tahsis eder ve serbest bırakır. Android ART'de, nesilsel toplama (generational collection) ile eşzamanlı bir çöp toplayıcı kullanılır: genç nesneler daha sık kontrol edilir, yaşlı nesneler daha az. Objective-C Runtime, derleyicinin otomatik olarak retain/release çağrıları eklediği Automatic Reference Counting (ARC) kullanır.

Metot dağıtıcı ve sanal tablo

Metot dağıtıcı, hangi metot uygulamasının çağrılacağını belirler. Statik dillerde (Kotlin, Swift), dağıtım vtable — sanal metot tablosu aracılığıyla yapılır. Dinamik dillerde (Objective-C), mesaj objc_msgSend aracılığıyla geçer ve uygulamayı sınıf ve onun üst sınıflarında arar. Sonuç, tekrarlanan çağrıları hızlandırmak için method cache'te önbelleğe alınır.

Android'te ART nasıl çalışır

Android Runtime (ART), Android uygulamalarının DEX bayt kodunu çalıştıran bir sanal makinedir. ART, Android 5.0 Lollipop'ta Dalvik'in yerini alarak AOT derlemesini getirdi: uygulama yükleme sırasında bir kez makine koduna derlenir. Bu, her başlatmada JIT derlemesinin yükünü ortadan kaldırdı.

Android 7.0 Nougat'tan itibaren ART hibrit bir yaklaşım kullanır. Yükleme sırasında, JIT derlemesi yalnızca sık kullanılan metotlar (hot methods) için gerçekleştirilir, kodun geri kalanı yorumlanır. Bir arka plan süreci (profile-guided optimization) hangi metotların en sık çağrıldığını analiz eder ve bunları cihazın boş zamanlarında AOT derler. Bu, yüksek performans sağlarken yükleme süresini azaltır.

ART ayrıca DEX dosyalarını ARM64 makine koduyla ELF ikili dosyalarına dönüştüren bir AOT derleyicisi (dex2oat) içerir. Derleme üç optimizasyon seviyesiyle gerçekleştirilir: quicken (hızlı), optimize (orta) ve everything (tam). Varsayılan olarak Android, derleme hızı ve kod performansı arasında denge kuran optimize kullanır.

class RuntimeExample {
    fun measureExecutionTime() {
        val start = System.nanoTime()
        // ART tarafından derlenen metot çağrısı
        processData()
        val end = System.nanoTime()
        println("Yürütme süresi: ${end - start} ns")
    }
}

Yukarıdaki örnekte, System.nanoTime(), çağrısı ART runtime aracılığıyla Linux çekirdeğine dağıtılan yerel bir metottur. ART, Kotlin bayt kodunu cihazın işlemcisi tarafından çalıştırılan ARM64 talimatlarına dönüştürür. Bu süreç geliştirici için şeffaftır, ancak optimizasyonu Android Platform ekibinin önemli bir görevidir.

Profile-Guided Optimization (PGO)

Profile-guided optimization, metot kullanım profillerini toplayan bir ART mekanizmasıdır. profiles/.primary.prof dosyası, AOT derlenen hot metotların bir listesini içerir. Android Performance Team'e göre PGO, profil biriktiğinde birkaç günlük kullanımdan sonra uygulama başlatmayı %15–30 oranında hızlandırır.

Geliştirici, Gradle projesinde baseline profiles özelliğini etkinleştirebilir. Bunlar, ART'ye yüklemeden hemen sonra hangi metotların AOT derleneceğini belirten manuel ek açıklamalardır. Baseline profiller, arka plan profillemesini beklemeden ilk başlatmayı %40 oranında azaltır.

iOS'ta Objective-C Runtime nasıl çalışır

Objective-C Runtime, iOS ve macOS'ta Objective-C kodunun çalıştırılmasını sağlayan dinamik bir kütüphanedir. Çekirdeği, mesaj iletimini uygulayan objc_msgSend işlevidir: doğrudan bir metot çağrısı yerine, nesne bir seçici (selector) ile bir mesaj gönderir ve runtime hangi uygulamanın çalıştırılacağını belirler.

Her Objective-C nesnesi, sınıfına bir isa işaretçisi içerir ve sınıf, seçicileri (SEL) uygulamalarla (IMP) eşleyen bir dispatch table'a sahiptir. Bir metot çağrıldığında, objc_msgSend zinciri (sınıf → üst sınıf → NSObject) IMP'yi bulana kadar izler. Hiçbir uygulama bulunamazsa, runtime, mesajı durdurabilen veya bir istisna oluşturabilen forwarding mechanism'i çağırır.

Objective-C Runtime ayrıca method swizzling'i de destekler — çalışma zamanında mevcut bir seçicinin IMP'sini değiştirme. Bu, AOP kütüphanelerinde ve izleme araçlarında kullanılan güçlü bir mekanizmadır, ancak tüm uygulama üzerindeki etkisi nedeniyle dikkat gerektirir.

@interface RuntimeDemo : NSObject
- (void)printClassInfo;
@end

@implementation RuntimeDemo
- (void)printClassInfo {
    // objc_getClass — runtime işlevi
    Class cls = objc_getClass("RuntimeDemo");
    unsigned int count;
    Method *methods = class_copyMethodList(cls, &count);
    NSLog("Metot sayısı: %d", count);
}
@end

Kod, Objective-C Runtime API'sine doğrudan erişimi gösterir: objc_getClass ada göre sınıf nesnesini alır, class_copyMethodList tüm metotların listesini alır. Bu, eylem halindeki yansımadır (reflection) — çalışma zamanında sınıf meta verilerine erişim. Bu yaklaşım, XCTest'te dinamik test kaydı için kullanılır.

isa işaretçisi ve etiketli işaretçiler

isa işaretçisi, her nesnenin ilk 8 baytında saklanan nesnenin sınıfına bir işaretçidir. iOS 12'den itibaren Apple, optimizasyon için isa-swizzling'i getirdi: isa'nın alt bitleri, nesnenin durumu hakkında ek bilgi kodlar. Etiketli işaretçiler (tagged pointers), 60 bit'e kadar olan değerlerin (NSNumber, NSDate) yığında bir nesne tahsis edilmeden doğrudan işaretçide saklandığı başka bir optimizasyondur. Bu, bellek yöneticisi yükünü %30 azaltır.

JIT ve AOT derlemesi: yaklaşımların karşılaştırılması

JIT (Just-In-Time) ve AOT (Ahead-Of-Time), bayt kodunu makine koduna derlemek için iki yaklaşımdır. JIT, uygulama çalışması sırasında kodu derler, sıcak noktaları analiz eder ve anında optimize eder. AOT, tüm kodu önceden derler — uygulama yüklemesi sırasında veya geliştirici tarafında.

ART hibrit yaklaşımı (Android 7+) optimal kabul edilir: uygulama nadiren çağrılan metotlar için yorumlayıcı, hot metotlar için JIT ve profile-guided optimization'dan metotlar için AOT kullanır. iOS, bunun aksine, LLVM aracılığıyla katı AOT kullanır: Swift ve Objective-C, Xcode'da derleme aşamasında makine koduna derlenir.

Apple Developer Documentation, 2024'e göre, Swift runtime uygulama boyutuna yaklaşık 15 MB ekler. Flutter, JIT derlemesinin sıcak yeniden yükleme (hot reload) için hata ayıklama modunda ve AOT'un maksimum performans için sürüm modunda çalıştığı kendi Dart VM'sini kullanır. React Native, başlatma süresini %50 azaltan AOT derlemeli bir JavaScript motoru olan Hermes'i kullanır.

ARM64 Runtime ve makine kodu

ARM64 Runtime, makine kodunun cihazın işlemcisiyle etkileşime girdiği seviyedir. Modern mobil cihazların çoğu ARM64 (aarch64) işlemcilerinde çalışır. Runtime, bayt kodunu veya yerel çağrıları CPU'nun çalıştırdığı ARM64 talimatlarına çevirir.

Runtime tarafından kullanılan temel ARM64 yazmaçları: x0–x7 (işlev parametreleri), x8 (dolaylı sonuç), x30 (dönüş adresi), sp (yığın işaretçisi), fp (çerçeve işaretçisi). ART, ARM64 Procedure Call Standard'ına uyan kod üretir: tüm metot çağrıları, işlemci mimarisi tarafından tanımlanan protokolden geçer.

ARM64 ABI'yi anlamak, performans optimizasyonu için önemlidir: satır içi önbellekleme, dal tahmini ve bellekte kod hizalaması runtime hızını doğrudan etkiler. Profil oluşturma araçları (Android Studio Profiler, Instruments), hangi kod bölümlerinin runtime'da en fazla zaman harcadığını gösterir — bunları optimize etmek en büyük iyileştirmeyi sağlar.

// ART tarafından oluşturulan ARM64 assembly örneği
// İki parametreli metot çağrısı

mov    x0, x23            // self (this)
mov    x1, x24            // param1
mov    x2, x25            // param2
bl     methodEntryPoint   // runtime aracılığıyla çağrı
str    x0, [sp, #8]      // sonucu kaydet

Bu örnekte, ARM64 talimatları mov, argümanları x0–x2 yazmaçlarına geçirir, bl metot giriş noktasını çağırır ve str dönüş değerini kaydeder. Runtime, her metot çağrısı için bu tür talimatlar üretir ve devirtualization ile inlining aracılığıyla sırayı optimize eder.

Runtime'ın performans üzerindeki etkisi

Runtime yükü, dinamik dağıtımın kaçınılmaz maliyetidir. Runtime aracılığıyla her metot çağrısı şunları gerektirir: dispatch table'da uygulama arama, tür kontrolü, IMP çağırma ve sonucu döndürme. Ölçümler, runtime'ın Objective-C'de çağrı başına 10–50 ns ve ART'de 5–20 ns eklediğini göstermektedir.

Yükü azaltmak için geliştiriciler monomorphic inlining (ART) ve method caching (Objective-C) kullanır. Kotlin/Native ve Swift doğrudan ARM64'e derlenir, runtime katmanını tamamen ortadan kaldırır, ancak yansıma, swizzling, dinamik sınıf yükleme gibi dinamik yetenekleri kaybeder.