Android Runtime (ART) Nedir, Neden Var?
Kodunuz Cihaza Nasıl Ulaşır?
Kotlin ile bir Android uygulaması yazıyorsunuz. Kodu derliyorsunuz, cihaza yüklüyorsunuz ve uygulama çalışıyor. Ama bu süreçte tam olarak ne oluyor? Yazdığınız kod doğrudan işlemci tarafından mı çalıştırılıyor? Cevap hayır — ve bu "hayır"ın ardında Android'in en ilginç bileşenlerinden biri yatıyor: Android Runtime.
Sorunun Kökü: Binlerce Farklı Cihaz
Android'in en büyük gücü aynı zamanda en büyük mühendislik sorunudur: parçalanma.
Dünya genelinde yüzlerce farklı üretici, binlerce farklı model Android cihaz üretmektedir. Bu cihazlarda ARM, ARM64, x86 gibi farklı işlemci mimarileri çalışmaktadır. Her işlemci mimarisinin anlayabildiği makine kodu birbirinden farklıdır.
Eğer Android uygulamaları doğrudan makine koduna derlenip dağıtılsaydı, her uygulama her işlemci mimarisi için ayrı ayrı derlenmek zorunda kalırdı. Bu hem geliştiriciler için kabusa dönüşürdü hem de uygulama dağıtımını son derece karmaşık hale getirirdi.
ART bu problemi zarif bir şekilde çözer.
ART Nasıl Çalışır?
Süreci adım adım izleyelim.
Kotlin ya da Java ile yazdığınız kod derleme aşamasında DEX (Dalvik Executable) bytecode'una çevrilir. Bu bytecode herhangi bir işlemci mimarisine özgü değildir — platform bağımsız bir ara formattır.
Bu DEX bytecode'u APK dosyasının içine paketlenir ve cihaza yüklenir. Cihaza yüklenme anında ya da ilk çalıştırma sırasında ART devreye girer ve bu bytecode'u cihazın işlemcisine özgü native koda çevirir.
Bu dönüşüm sayesinde aynı APK dosyası ARM işlemcili bir Samsung'da da, x86 işlemcili bir emülatörde de sorunsuz çalışır. Geliştirici olarak bu farkı düşünmek zorunda kalmazsınız.
ART'ın Öncülü: Dalvik
ART, Android'in başından beri var olan bileşen değildir. Onun yerini 2014'e kadar Dalvik sanal makinesi tutuyordu.
Dalvik, her uygulama başlatıldığında bytecode'u anlık olarak yorumlayan bir yapıya sahipti. Bu yaklaşıma JIT (Just-In-Time) derleme denir. Uygulama çalışırken kod parça parça yorumlanır ve çalıştırılır.
JIT'in dezavantajları zamanla belirginleşti. Uygulama başlangıçları yavaştı çünkü her seferinde derleme işlemi tekrarlanıyordu. Çalışma zamanında ek işlemci yükü oluşuyordu. Ve bu durum pil tüketimini olumsuz etkiliyordu.
ART'ın Getirdiği: AOT Derleme
Android 5.0 ile birlikte ART, Dalvik'in yerini aldı ve beraberinde AOT (Ahead-Of-Time) derleme yaklaşımını getirdi.
AOT'ta derleme işlemi uygulama yüklenirken yapılır ve sonuç cihaza kaydedilir. Uygulama her çalıştırıldığında yorumlama yerine önceden derlenmiş native kod doğrudan çalıştırılır. Bu sayede uygulama başlangıç süreleri önemli ölçüde kısaldı ve çalışma zamanı performansı yükseldi.
Ancak AOT'un da dezavantajları vardı. Uygulama yükleme süresi uzadı. Ve derleme sonuçları depolandığı için depolama alanı kullanımı arttı.
Hibrit Çözüm: AOT + JIT + Profil Tabanlı Derleme
Android 7.0 ile birlikte ART daha da olgunlaştı ve hibrit bir yaklaşım benimsendi.
Uygulama ilk yüklendiğinde yalnızca temel bileşenler AOT ile derlenir. Uygulama çalışmaya başladığında JIT devreye girer ve hangi kod parçalarının sık kullanıldığını takip eden profil verileri toplanır. Cihaz boştayken bu profil verilerine göre en çok kullanılan kodlar arka planda AOT ile derlenir.
Bu yaklaşım hem hızlı kurulum hem de zamanla artan çalışma performansını bir arada sunar. Bir uygulamayı ilk açtığınızda hissedilen küçük yavaşlığın, ilerleyen kullanımlarda yerini akıcılığa bırakması tam olarak bu mekanizmanın sonucudur.
Garbage Collection: Belleği Kim Temizler?
ART'ın bir diğer kritik sorumluluğu çöp toplama (Garbage Collection) yönetimidir.
Kotlin ya da Java ile kod yazarken belleği manuel olarak yönetmezsiniz. Nesne oluşturursunuz, işiniz bitince bırakırsınız — geri kalanı ART'ın işidir. ART artık kullanılmayan nesneleri tespit eder ve bellekten temizler.
Bu mekanizma geliştirmeyi kolaylaştırır ama dikkatli olunmaması durumunda sorunlara da yol açabilir. Gereksiz nesne yaratımı, bellek sızıntıları (memory leaks) ve fazla büyük nesnelerin yanlış yönetimi GC'nin aşırı çalışmasına neden olarak uygulamanızda takılmalar yaratabilir.
Geliştirici Perspektifinden Bakış
ART'ı anlamak birkaç önemli pratik sonuç doğurur.
Uygulama başlangıç sürenizi optimize etmek istiyorsanız ilk çalıştırmada ne kadar iş yapıldığını bilmeniz gerekir — bu doğrudan ART'ın derleme davranışıyla ilgilidir. Bellek yönetimi sorunlarını teşhis etmek için GC'nin nasıl çalıştığını anlamanız gerekir. NDK kullanarak native kod yazdığınızda ART'ın bytecode çalıştırma ortamının dışına çıktığınızı ve belleği kendiniz yönetmek zorunda olduğunuzu bilmeniz gerekir.
Yazdığınız her satır Kotlin kodu nihayetinde ART üzerinde çalışır. Bu ortamı tanımak, kodunuzun nasıl hayat bulduğunu anlamak demektir.