Bölüm 1: Bu Nedir ve Neden Hayati Önem Taşır?
Bu inceleme, Android ekosisteminin evrimsel dönüşüm noktalarından biri olan çalışma zamanı (runtime) mimarisinin, Dalvik Sanal Makinesi’nden (DVM) Android Runtime (ART)’a geçişini, derleme stratejileri (JIT vs AOT) açısından ontolojik ve metodolojik bir çerçeve içinde ele alır. Konu, mobil işletim sistemlerinde kaynak kısıtlı donanımlarda (bellek, CPU döngüleri, pil) yüksek performanslı, deterministik ve güvenli uygulama yürütme problemini merkezine alır. Temel yaklaşim, “yorumlayıcı tabanlı, çalışma anında derleme (JIT)” paradigmasından, “kurulum anında derleme (AOT)” ve “profil yönlendirli derleme (Profile-Guided Compilation)” hibrit modellerine geçişin sistem yazılımı, derleyici teorisi ve kullanıcı deneyimi (UX) üzerindeki etkilerini sistematik olarak haritalamaktır. Analiz, bytecode (DEX) doğrulama, makine kodu (OAT/ELF) üretimi, garbage collection (GC) etkileşimi ve depolama maliyeti gibi kritik parametreleri kapsayacak şekilde tanımlanmıştır.
Bölüm 2: Perde Arkası: Sistem Nasıl Çalışıyor?
Dalvik, register tabanlı bir sanal makine olarak, Java bytecode’ını .dex (Dalvik Executable) formatına dönüştürür ve çalışma anında JIT derleyici (Android 2.2+ ile eklenen trace-based JIT) aracılığıyla sıcak kod yollarını (hot paths) yerel makine koduna (ARM/MIPS/x86) çevirir. Bu model, başlatma gecikmesini azaltır ancak çalışma anında derleme maliyeti (CPU/Pil) ve kod önbelleği (code cache) yönetimi yükü getirir. ART ise (Android 4.4 KitKat’te deneysel, 5.0 Lollipop’ta varsayılan), dex2oat aracı ile uygulama kurulum/güncelleme aşamasında .dex dosyalarını tamamen ELF formatındaki .oat (ART Ahead-of-Time) dosyalarına derler. Bu AOT yaklaşımı, yürütme motorunu yorumlayıcıdan (interpreter) doğrudan yerel kod yürütmeye taşır. Android 7.0 (Nougat) ile gelen “Profile-Guided Compilation” (PGC), Play Store’un curated profiles mekanizmasıyla, sadece sık kullanılan yöntemleri AOT derleyip nadir kullanılanları yorumlayıcıya/JIT’e bırakarak hibrit bir denge kurar. GC tarafında ART, moving/collecting GC (CMS, Genel GC) ile bellek fragmentasyonunu minimize ederken, Dalvik’in non-moving GC’si uzun ömürlü süreçlerde performans düşüşüne yol açardı.
Bölüm 3: Bilim Dünyası ve Uzmanlar Nasıl İnceliyor?
Teknik değerlendirme metodolojisi; derleyici optimizasyon seviyeleri (O0-O3, OS), bytecode doğrulama kuralları (JVM Spec vs Android Verifier), ve sistem çağrısı (syscall) gecikme analizi üzerine kuruludur. Standart referanslar: Android Compatibility Definition Document (CDD), Android Compatibility Test Suite (CTS) ve ART Source Code (AOSP – art/runtime/) kod tabanıdır. Performans ölçümleri için perfetto/systrace araçlarıyla CPU scheduler latency, dumpsys gfxinfo ile frame rendering stats (Jank/Frame Time), dumpsys meminfo ile PSS/USS bellek metrikleri kullanılır. Derleme süresi ve depolama maliyeti analizi dex2oat --compiler-filter bayrakları (speed, speed-profile, verify, interpret-only) ile parametrik olarak test edilir. Güvenlik doğrulaması için Control Flow Integrity (CFI) ve Shadow Call Stack (SCS) entegrasyonu, derleme zamanında (AOT) veya yükleme zamanında (JIT) uygulanan hardening protokollerini belirler.
Bölüm 4: Önemli Parametreler ve Karşılaştırma Rehberi
| Parametre | Olcut / Deger (Dalvik) | Olcut / Deger (ART) | Metrik | Stratejik Etki |
|---|---|---|---|---|
| Derleme Stratejisi | JIT (Trace-based, Runtime) | AOT (Install-time) + PGC (Hybrid) | Derleme Zamanı / Yürütme Hızı | ART: Kurulum süresi artışı, Çalışma anında %0 derleme maliyeti |
| Kod Depolama Formatı | .dex (Optimize Edilmemiş) |
.oat (ELF, Native Machine Code) |
Disk Alanı (Byte) | ART: %10-20 daha fazla disk alanı (OAT overhead) |
| Başlatma Gecikmesi | Yüksek (Yorumlayıcı + JIT Isınma) | Düşük (Hazır Native Kod) | ms (Time to Initial Display) | ART: Soğuk başlatma (Cold Start) %30-50 hızlanma |
| Çalışma Anı Performansı | Isınma sonrası iyi, başlangıçta düşük | Deterministik, Yüksek (Optimize Edilmiş) | CPU Cycles / Instruction | ART: Sürekli yüksek throughput, JIT “warm-up” yok |
| Bellek Yönetimi (GC) | Non-moving, Mark-Sweep | Moving/Compacting (CMS, Genel, Homogeneous Space) | Pause Time (ms) / Fragmentasyon | ART: Düşük pause, fragmentasyon önleme, büyük heap desteği |
| Hata Ayiklama / Profiling | JDWP, hprof (Sınırlı) |
JDWP, perfetto, simpleperf, Sampling Profiler |
Gözlemlenebilirlik | ART: Üretim ortamında düşük maliyetli sampling profiling |
| Güvenlik (Hardening) | Minimal (Stack Canary) | CFI, SCS, PAC (Pointer Auth), Hardened Allocator | Exploit Mitigasyon Etkinliği | ART: Derleme zamanında kontrol akışı bütünlüğü garanti |
| Arşivişlem Desteği | Yok | apex (ART Module), Mainline Updates |
Sistem Güncelleme Hızı | ART: OS yükseltmesiz runtime güvenlik/performans yaması |
| Talimat Seti Mimarisi | ARMv5/7, x86, MIPS (Yazılımsal) | ARM64 (AArch64), x86_64, RISC-V (Donanımsal Optimizasyon) | ISA Özel Optimizasyon | ART: Vektörizasyon (NEON/SVE), Branch Prediction Hintleri |
| Uygulama Kurulum Süresi | Hızlı (Sadece Dexopt Verify) | Yavaş (dex2oat AOT Derleme) |
Saniye / Dakika | ART: Kullanıcı bekleme süresi artışı, Play Store dtm ile azaltılır |
| Dinamik Kod Yükleme | DexClassLoader (Kolay) |
InMemoryDexClassLoader, VMRuntime kısıtlamaları |
Esneklik / Güvenlik | ART: Güvenlik için kısıtlı, performans için derleme maliyeti |
| Pil Verimliliği | Orta (JIT CPU kullanımı) | Yüksek (CPU Idle süresi artışı) | mAh / Saat | ART: Derleme enerjisi kurulumda (şarjda) ödenir |
Bölüm 5: Günlük Hayatta ve Doğada Nerede Karşımıza Çıkar?
Gerçek dünya senaryolarında ART’nin üstünlüğü belirginleşir. Senaryo 1: Oyun Motorları (Unity/Unreal/Godot). Dalvik’te JIT ısınması sırasında frame drop (jank) yaşanırken, ART AOT ile shader derleme ve physics loop’ları native kod olarak başlar. Senaryo 2: Kurumsal Uygulamalar (MDM/EMM). Büyük codebase’li (multi-dex) uygulamalarda ART’nin ClassLoader iyileştirmeleri ve Image (boot.art, core.art) paylaşımlı bellek haritalama (mmap) sayesinde süreç başına (per-process) RSS (Resident Set Size) %15-25 azalır. Senaryo 3: Düşük Seviyeli Donanım (Android Go / IoT). ART’nin compiler-filter=interpret-only veya speed-profile modları, depolama ve RAM kısıtlı cihazlarda AOT maliyetini esnekleştirir. Senaryo 4: Güvenlik Hassas Uygulamalar (Banking/Health). ART’nin CFI ve Shadow Call Stack desteği, ROP/JOP saldırı vektörlerini derleme zamanında kırar; Dalvik’te bu sadece runtime sanitizers (ASan/MSan) ile mümkündü. Senaryo 5: OTA Güncellemeleri. Project Mainline (Android 10+) sayesinde ART modülü (com.android.art) Play Store üzerinden güncellenebilir; bu, zero-day runtime exploit’lerin (örn. CVE-2019-2215 binder use-after-free) OS yükseltmesi bekmeden yamalanmasını sağlar.
Bölüm 6: Karşılaşılan Zorluklar ve Pratik Çözümler
Zorluk 1: Kurulum Süresi ve Depolama Baskısı. dex2oat çok çekirdekli (multi-threaded) olsa bile, büyük uygulamalarda (örn. 200MB+ DEX) kurulum dakikalara uzayabilir. Çözüm: Play Store Dynamic Delivery ve Profile-Guided Compilation (cloud profiles) ile sadece kritik yollar AOT derlenir, geri kalanı speed-profile filtresiyle ertelenir. Zorluk 2: OAT Dosyalarının Geçersizliği (Staleness). Sistem güncellemesinde (OTA) veya ART sürüm yükseltmesinde oat dosyaları dex2oat --runtime-arg -Xrelocate ile yeniden derlenmelidir (boot-class-path değişimi). Çözüm: otapreopt scriptleri ve fsverity ile doğrulanmış, artık (idempotent) yeniden derleme pipeline’ları. Zorluk 3: Dinamik Kod Yükleme Performansı. InMemoryDexClassLoader ile çalışma anında yüklenen DEX’ler JIT/Interpreter modunda çalışır, AOT optimizasyonsuz. Çözüm: VMRuntime.setJitCompilationEnabled(true) ve ProfileInstaller (Jetpack) ile çalışma anı profilleri toplayıp bir sonraki güncellemede cloud profile entegre etmek. Zorluk 4: Hata Ayıklama Karmaşıklığı. Optimize edilmiş OAT kodu (inlining, dead code elimination) stack trace’leri karmaşıklaştırır. Çözüm: dex2oat --generate-debug-info=true ve proguard mapping dosyalarının R8/ProGuard ile senkronize edilmesi.
Bölüm 7: Gelecek Perspektifi ve Yeni Gelişmeler
Android 13/14 (Tiramisu/UpsideDownCake) ve 15 (VanillaIceCream) sürümlerinde ART, RISC-V vektör uzantıları (RVV) ve ARM SVE2/SME desteğiyle heterojen hesaplama (ML/NPU) için vektörizasyon yetenekleri kazandı. Baseline Profiles (Jetpack) standartlaşması, geliştiricilerin BaselineProfileRule ile kritik kullanıcı yollarını (startup, scroll, navigation) derleme öncesi tanımlamasını sağlayarak PGC’yi demokratikleştirdi. ART Module Updating (Mainline) sayesinde GC algoritmaları (Genel GC -> Generational/Concurrent), derleyici optimizasyonları (Global Value Numbering, Loop Unrolling heuristics) ve güvenlik yamaları (PAC, BTI, MTE entegrasyonu) OS major sürümünden bağımsız dağıtılabiliyor. Gelecek 5-10 yıl projeksiyonunda: Cloud Compilation (Play Store sunucularında cihaz spesifik ISA için AOT derleme, cihaza sadece OAT indirme), Wasm/WASI Desteği (ART içinde WebAssembly runtime entegrasyonu için deneysel çalışmalar), ve AI-Assisted Compilation (Makine öğrenmesi ile branch prediction ve inlining kararlarının runtime profillerine göre dinamik optimize edilmesi) bekleniyor. Rust tabanlı sistem bileşenleri (bionic, ART runtime kısımları) ile memory safety teminatı artırılacak.
Bölüm 8: Merak Edilen Sorular ve Cevaplar
Soru 1: ART tamamen JIT’i ortadan kaldırdı mı?
Cevap: Hayır. Android 7.0 (Nougat) ile birlikte ART, Hibrit Bir Model (Tiered Compilation) benimsedi. Uygulama kurulumunda compiler-filter=speed-profile ile sadece profil verilerine dayalı olarak “sıcak” metotlar AOT derlenir. “Soğuk” metotlar yorumlayıcı (interpreter) modunda başlar ve çalışma anında yeterli çağrı sayısına ulaştıklarında JIT derleyici (art_jit_compile) tarafından native koda çevrilir. Bu, depolama maliyeti ve başlatma performansı arasında optimal denge kurar.
Soru 2: dex2oat aracı ne işe yarar ve neden kurulumu yavaşlatır?
Cevap: dex2oat (DEX to OAT), ART’nin statik derleyicisidir. Uygulama paketindeki classes.dex dosyalarını okur, doğrular (verifier), SSA (Static Single Assignment) tabanlı ara temsile (HIR/LIR) düşürür, optimizasyon geçişlerini (inlining, dead code elimination, register allocation) uygular ve sonucu paylaşılabilir .oat (ELF) dosyası olarak yazar. Bu işlem CPU-bound ve I/O yoğundur; çoklu dex dosyaları ve büyük metot sayısı (65k limiti sonrası multi-dex) süreçleri uzatır.
Soru 3: Dalvik’ten ART’e geçişte “OAT” dosyası nedir ve neden .dex yerine kullanılır?
Cevap: .oat (ART Ahead-of-Time) dosyası, birden fazla .dex dosyasını, derlenmiş makine kodunu (text section), meta verileri (rodata, GC map, debug info) ve çözülmüş referansları (vtable, itable) içeren bir ELF paylaşılan kütüphanesidir (shared library). Dalvik .dex dosyalarını her süreç için belleğe eşler (mmap) ve yorumlar; ART ise .oat dosyasını mmap eder ve text segmentini (kod) işlemler arası Copy-on-Write (CoW) mekanizmasıyla paylaşır. Bu, RAM kullanımını drastik olarak azaltır.
Soru 4: “Profile-Guided Compilation” (PGC) nasıl çalışır ve geliştirici nasıl etki edebilir?
Cevap: PGC iki aşamalıdır. 1. Profil Toplama: Uygulama çalışırken ProfileInstaller (Jetpack) veya sistem curated_profile servisi, metot çağrı sıklığını ve başlatma sırasını prof dosyasında (protobuf formatında) kaydeder. 2. Bulut/İstemci Derleme: Play Store bu profilleri toplayıp anonimleştirerek “Cloud Profile” oluşturur. Yeni kullanıcılar uygulamayı indirirken bu profili alır ve dex2oat --profile=cloud.prof ile sadece profildeki metotları AOT derler. Geliştirici BaselineProfileRule (Macrobenchmark) ile kritik yolları (startup, scroll) manuel tanımlayarak “Baseline Profile” üretir ve APK/AAB içine gömer.
Soru 5: ART’nin Garbage Collector (GC) mimarisi Dalvik’ten nasıl farklıdır ve “Moving GC” ne kazandırdı?
Cevap: Dalvik Non-Moving (Mark-Sweep) GC kullanırdı; bellek fragmentasyonu zamanla artar, büyük nesneler için LargeObjectSpace zorunlu olurdu. ART Moving/Compacting GC (CMS – Concurrent Mark Sweep, Genel GC, Homogeneous Space) kullanır. Nesneleri taşıyıp sıkıştırarak (compaction) fragmentasyonu önler, bump-pointer allocation ile ayrımını O(1) yapar. Bu, özellikle uzun süre çalışan sistem sunucuları (system_server) ve büyük heap’li uygulamalarda OOM (OutOfMemory) riskini ve allocation latency’yi minimize eder.
Soru 6: Android 12+ (S) sürümlerinde ART modülü (Mainline) güncellemeleri geliştiriciyi nasıl etkiler?
Cevap: Android 10+ ile ART apex (Android Pony EXpress) modülü haline getirildi. Bu, Google’ın ART runtime’ını (derleyici, GC, yorumlayıcı, sınıf kütüphaneleri) Play Store / Play Services aracılığıyla OTA’sız güncelleyebileceği anlamına gelir. Geliştirici için: Uygulama derleme hedefi (targetSdkVersion) değişse bile, kullanıcının cihazındaki ART sürümü daha yeni olabilir. Bu, yeni API’ler (örn. java.lang.ForeignFunctionMemory preview) veya performans iyileştirmelerinin (örn. yeni JIT heuristics) cihazda hemen etkin olmasını sağlar; ancak nadir de olsa runtime davranış değişiklikleri (GC timing, class loading sırası) test edilmesi gerekebilir.
Bölüm 9: Bilmeniz Gereken Temel Terimler
DEX (Dalvik Executable): Android’in özel bytecode formatı. Java .class dosyalarından dx veya d8/r8 araçlarıyla üretilir. Register tabanlı talimat seti, sabit havuzu (constant pool) ve veri yapılarını içeren kompakt bir formattır.
OAT (ART Ahead-of-Time): ART tarafından dex2oat ile üretilen, ELF (Executable and Linkable Format) standardında, makine kodunu (text), meta verileri ve çözülmüş sembolleri içeren paylaşılabilir kütüphane dosyası. .odex (Optimized DEX) terminolojisinin ART karşılığıdır.
JIT (Just-In-Time Compilation): Program çalışma sırasında (runtime), yorumlayıcı tarafından tespit edilen “sıcak” (hot) kod yollarının (trace/method) anında makine koduna derlenmesi süreci. Derleme maliyeti kullanıcı oturumuna eklenir.
AOT (Ahead-Of-Time Compilation): Program kurulum veya derleme aşamasında (install/build time), tüm veya kritik kodun makine koduna önceden derlenmesi. Çalışma anında derleme maliyeti sıfırdır, ancak depolama ve kurulum süresi maliyeti vardır.
PGC (Profile-Guided Compilation): Çalışma anından toplanan profil verilerinin (hangı metotlar ne sıklıkla çağrılıyor), sonraki derleme turlarında (cloud veya local) optimizasyon kararları (inlining, AOT vs JIT) için girdi olarak kullanılması tekniği.
GC Map / Stack Map: GC’nin, bir thread’in stack frame’inde veya register’larında hangi slotların nesne referansı (pointer) tuttuğunu, hangılarının skaler (int/float) olduğunu bilmesini sağlayan meta veri tablosu. Moving GC için referans güncellemesi (update roots) zorunludur.
Zygote / App Specialization: Android’in süreç başlatma modeli. Zygote süreci (pre-warmed ART heap, loaded classes) fork() ile kopyalanır. ART, AppImage (uygulama özel heap snapshot) ile bu forklanmış sürecin başlatma süresini daha da kısaltır.
CFI (Control Flow Integrity): Derleyicinin (LLVM/ART backend), dolaylı çağrılar (virtual calls, function pointers) için hedef adreslerin geçerli bir kontrol akışı grafiğine (CFG) uyup uymadığını çalışma anında kontrol eden (veya statik olarak kısıtlayan) güvenlik mekanizması.
Bölüm 10: Özet ve Çıkarılması Gereken Dersler
Android Runtime (ART), Dalvik’in yorumlayıcı/JIT tabanlı esnek ama kaynak tüketen mimarisinden, modern derleyici teorisi (SSA, Global Optimization), gelişmiş bellek yönetimi (Generational/Concurrent Moving GC) ve donanım yakını güvenlik (CFI, PAC, MTE) prensipleri üzerine kurulu, modüler ve güncellenebilir bir sistem yazılımı katmanına evrildi. Bu geçiş, “Write Once, Run Anywhere” felsefesini “Compile Once, Run Optimally on Target Hardware” paradigmasına taşıdı. Stratejik çıkarımlar şunlardır: 1. Performans Determinizmi: AOT/PGC hibrit modeli, kullanıcı deneyimini (jank-free frames, cold start) donanım parçacığına (fragmentation) bağlamadan garanti altına alır. 2. Güvenlik Yerleşimi: Runtime exploit yüzey alanı, derleme zamanında sertleştirme (hardening) ile minimize edilmiştir. 3. Operasyonel Çeviklik: Mainline (APEX) modülü sayesinde, ekosistem geneli runtime yamaları (zero-day, perf regressions) haftalar içinde dağıtılabilir. 4. Geliştirici Yükümlülüğü: Baseline Profiles ve R8/d8 toolchain entegrasyonu, performans optimizasyonunu derleme hattına (CI/CD) entegre etmeyi zorunlu kıldı. Karar vericiler için yol haritası: Uygulama dağıtım stratejisinde App Bundle + Baseline Profile + Play Asset Delivery üçlüsünü standartlaştırın; düşük seviyeli performans analizi için Perfetto/simpleperf yetkinliğini ekibe kazandırın; ART sürüm notlarını (AOSP art/CHANGES.md) takip ederek GC/Compiler davranış değişikliklerini proaktif test edin. ART artık sadece bir runtime değil, Android’in performans, güvenlik ve güncellenebilirlik stratejisinin çekirdek mühendislik varlığıdır.
