Dalvik: nedir, sanal makine ve nasıl çalışır

Dalvik nedir?

Dalvik, özellikle Android platformu için oluşturulmuş, kayıt tabanlı mimariye sahip bir sanal makinedir. Geliştirme 2005 yılında Dan Bornstein'ın şirketi tarafından başlatıldı ve 2007'de proje Google tarafından satın alındı. Dalvik'in ilk ticari sürümü, 2008'de Android 1.0'ın piyasaya sürülmesiyle ortaya çıktı.

Standart Java Sanal Makinesi'nin (JVM) aksine Dalvik, Java bayt kodunu çalıştırmaz. Java derleyicisi kaynak kodu class dosyalarına dönüştürür ve ardından dx aracı bunları Dalvik Executable (DEX) formatına çevirir. Bu format, class dosyalarından daha derli topludur: class formatındaki 10 MB'lık bir uygulama, DEX'te yaklaşık 6–7 MB yer kaplar.

Oluşturulma geçmişi

Dan Bornstein, Dalvik'i sınırlı kaynaklara sahip işletim sistemleri için bir proje olarak yazdı. İsim, İzlanda köyü Dalvík'ten alınmıştır. Google, lisanslama kısıtlamaları ve ARM mimarisine sahip mobil işlemciler için derin optimizasyon ihtiyacı nedeniyle JVM yerine Dalvik'i seçti. Sistem hızla popülerlik kazandı: 2012'ye kadar 500 milyondan fazla Android cihazı Dalvik çalıştırıyordu.

Android ekosistemindeki rolü

Her Android uygulaması, kendi Dalvik VM örneğiyle ayrı bir süreçte çalışır. Bu, işletim sistemi düzeyinde veri yalıtımı ve kötü amaçlı koda karşı koruma sağlar. Bu yaklaşım, sanallaştırmanın avantajlarını Linux sanal alanıyla birleştirir — bir uygulamadaki kötü amaçlı yazılım, komşu süreçleri etkileyemez.

Dalvik Mimarisi: kayıt makinesi ve DEX

Dalvik'in kayıt tabanlı mimarisi, JVM'nin yığın tabanlı mimarisinden temelde farklıdır. Dalvik, yığın tepesindeki işlemler yerine, VM içindeki sanal hücreler olan kayıtlarla çalışır. Her talimat, işlen kayıtlarının adreslerini içerir ve bu da işlem başına talimat sayısını azaltır.

JVM yığın makinesi push, pop ve add gibi talimatlar kullanır — iki sayıyı toplamak için üç talimat gerekir. Dalvik aynı görevi üç kayıtlı tek bir add-int talimatıyla çözer. Android Open Source Project'e göre, kayıt tabanlı DEX mimarisi, yığın tabanlı class formatına kıyasla bayt kodu boyutunu ortalama %30 azaltır.

DEX formatı

Bir DEX dosyası (Dalvik Executable), uygulamanın tüm sınıflarının sıkıştırılmış bir temsilini içerir. Dosya başlığı bir sağlama toplamı, bölüm boyutları ve ofsetler içerir. Ana bölümler, dizeler, türler, yöntem prototipleri, alanlar ve bayt kodunun kendisinden oluşan havuzlardır. Tek bir DEX dosyası 65.536'ya kadar yöntem depolayabilir (Android 5.0'da multi-dex'in tanıtılmasıyla sınırlama kaldırılmıştır).

Android SDK Build Tools içinde bulunan dx aracı, class dosyalarını DEX'e dönüştürmek için kullanılır. Komut örneği: dx --dex --output=classes.dex myapp.jar. Modern projeler, gelişmiş optimizasyon ve Java 8+ özellikleri desteğiyle dx'in halefi olan D8'i kullanır.

# dx kullanarak JAR'yi DEX'e dönüştürme
dx --dex --output=classes.dex myapp.jar

# D8 ile modern sürüm
d8 --lib android.jar --output dex/ myapp.jar

Zygote: çerçeveyi önceden yükleme

Zygote süreci, Dalvik mimarisinin önemli bir unsurudur. Sistem başladığında Zygote, tüm Android SDK sınıflarını yükler, paylaşımlı kütüphaneleri açar ve önceden yüklenmiş kaynaklardan oluşan bir havuz oluşturur. Bir kullanıcı bir uygulama açtığında, sistem Zygote sürecini çatallar (fork) ve halihazırda başlatılmış bir çerçeveyle yeni bir Dalvik VM örneği oluşturur. Bu, uygulama başlatma süresini ~2–3 saniyeden 300–500 milisaniyeye düşürür.

Dalvik'te JIT derlemesi

JIT (Just-In-Time), uygulama yürütmesi sırasında bayt kodunu doğrudan makine talimatlarına derleme teknolojisidir. Dalvik'te JIT derleyicisi, çalışan DEX kodunu analiz eder, sık kullanılan (sıcak) yöntemleri belirler ve bunları CPU için yerel koda derler.

Erken Android sürümlerinde tam Ahead-Of-Time (AOT) derlemesi yerine JIT seçimi bilinçliydi. Mobil cihazlar sınırlı flash depolamaya sahipti (4–16 GB) — tüm uygulamaları önceden derlemek önemli yer kaplardı. Ayrıca, erken cihazlardaki ROM belleği RAM'den daha yavaştı ve önceden derlenmiş kodu okumak performansı düşürebilirdi.

JIT derleme süreci

Bir uygulama başlatıldığında, Dalvik DEX bayt kodunu yorumlamaya başlar. Özel bir profil oluşturucu, hangi yöntemlerin en sık çağrıldığını izler. Bir eşiği (genellikle ~200 çağrı) aştıktan sonra, JIT derleyicisi yöntemi makine koduna dönüştürür ve RAM'de önbelleğe alır. Sonraki çağrılar, yeniden derleme olmadan zaten derlenmiş sürümü kullanır.

// JIT'in derleyeceği sıcak bir yöntem örneği
public class Calculator {
    public int sumArray(int[] arr) {
        int total = 0;
        for (int i = 0; i < arr.length; i++) {
            total += arr[i];
        }
        return total;
    }
}

JIT performansı

Google I/O 2013'e göre, Android 2.2 Froyo'da JIT'in tanıtılması, saf yorumlamaya kıyasla uygulama yürütmesini ortalama 2–5 kat hızlandırdı. Ancak JIT, ilk başlatmada gecikme ekler: bir uygulamanın ısınması ve sıcak yöntemleri derlemesi için 3 ila 10 saniye gerekir. ısınmanın ardından performans, yerel koda yakın bir seviyede sabitlenir.

Dalvik vs JVM: temel farklar

Dalvik, birkaç temel açıdan JVM'den farklıdır. Birincisi — mimari: JVM yığın tabanlı, Dalvik kayıt tabanlıdır. İkincisi — bayt kodu formatı: JVM class dosyalarını kullanır, Dalvik DEX kullanır. Üçüncüsü — bellek yönetimi: Dalvik, mobil cihazların sınırlı RAMi için optimize edilmiştir.

Her iki yaklaşımın da güçlü yönleri vardır. Yığın tabanlı JVM, talimatları depolamak için daha az alan gerektirir — işlenenler yığından örtük olarak alındığı için her talimat daha kısadır. Kayıt tabanlı Dalvik, işlem başına daha az talimat yürütür ve bu da CPU zamanından tasarruf sağlar ve güç tüketimini azaltır. Pil ile çalışan mobil cihazlar için bu kritiktir.

Lisanslama yönleri

JVM yerine Dalvik seçimi aynı zamanda lisanslama tarafından da yönlendirildi. Oracle, Java SE ve JVM'nin haklarına sahiptir ve Google lisans ücretlerinden kaçınmak istiyordu. Alternatif bir bayt kodu formatına sahip kendi VM'ini oluşturmak, Android'in Oracle'dan bağımsız olarak gelişmesine izin verdi. Bu anlaşmazlık, Oracle'a karşı Google (2010–2021) uzun bir hukuk savaşına dönüştü ve Google lehine sonuçlandı.

DEX formatı ve dx aracı

DEX (Dalvik Executable), bir Android uygulamasının derlenmiş kodunu içeren ikili bir formattır. Her DEX dosyası bir başlıkla başlar, ardından bölümler gelir: dize sabitleri (string_ids), türler (type_ids), yöntem prototipleri (proto_ids), alanlar (field_ids), yöntemler (method_ids), sınıf tanımları (class_defs) ve bir veri alanı.

dx aracı, Java class dosyalarını bir veya daha fazla DEX dosyasına dönüştürür. Algoritma, sabitlerin yinelenmesini kaldırmayı içerir — aynı dizeler veya türler bir kez depolanır ve dizinle referans verilir. Bu, son boyutu önemli ölçüde azaltır. Modern projelerde dx'in yerini, 2–3 kat daha hızlı olan ve Java 8 desugaring'i destekleyen D8 (Android Studio 3.1'de tanıtıldı) almıştır.

// dexdump ile derlenmiş DEX bayt kodu örneği
// Kaynak kod: return a + b;
@Ldalvik/annotation/Code;
    registers: 3
    add-int v0, v1, v2
    return v0

Multi-dex: 65536 sınırını aşmak

65.536 yöntemlik DEX formatı sınırlaması (16 bitlik dizin sınırı), büyük uygulamalar için ciddi bir sorun haline geldi. Çözüm Android 5.0 ile geldi: multi-dex desteği, bir uygulamanın birden çok DEX dosyası içermesine izin verir. Ana classes.dex giriş noktalarını içerirken, ek classes2.dex, classes3.dex vb. dosyalar kodun geri kalanını içerir. Multi-dex yapılandırması, build.gradle dosyasında multiDexEnabled true satırıyla etkinleştirilir.

Bellek yönetimi ve çöp toplama

Dalvik'te çöp toplama, işaretle ve süpür (mark-and-sweep) ile nesilsel bir toplayıcı olarak uygulanır. Bellek iki ana alana ayrılır: nesneler için Heap (yığın) ve ilkeller ve referanslar için Stack (yığın). Heap dolduğunda, Dalvik tüm içerikleri askıya alır (STW — Stop-The-World), ulaşılabilir nesneleri işaretler ve ulaşılamayanları serbest bırakır.

Android 2.2'den önce, Dalvik 100–200 ms'ye kadar duraklama sürelerine sahip tek iş parçacıklı bir toplayıcı kullanıyordu. Android 2.3 Gingerbread, tipik duraklamaları 5–10 ms'ye düşüren eşzamanlı bir toplayıcı tanıttı. Ve Android 4.0 Ice Cream Sandwich, artımlı temizleme ile bir toplayıcı ekledi — Concurrent Mark and Sweep (CMS).

Bellek sızıntıları

Dalvik uygulamalarının tipik bir sorunu, Activity'ye statik referanslar yoluyla bellek sızıntılarıdır. Statik bir alan, Context veya View'a bir referans tutarsa, çöp toplayıcı ekran kapatıldıktan sonra bile Activity'yi serbest bırakamaz. Eclipse MAT ve LeakCanary gibi araçlar bu tür sızıntıları tespit etmeye yardımcı olur: bir Heap dökümünü analiz eder ve nesneyi tutan referans zincirlerini gösterir.

// Statik referans yoluyla bellek sızıntısı örneği
public class Utils {
    private static Context context;

    public static void init(Context ctx) {
        context = ctx; // finish()'ten sonra Activity'yi tutar
    }
}

Dalvik sınırlamaları ve ART'ye geçiş

Başarısına rağmen, Dalvik'in birkaç dezavantajı vardı. JIT derlemesi ısınma süresi gerektiriyordu — uygulama çalışmasının ilk saniyeleri daha yavaştı. Ayrıca JIT, derleme sırasında CPU gücü tüketerek pil ömrünü azaltıyordu. Mobil cihaz performansı arttıkça ve dahili depolama büyüdükçe, JIT ihtiyacı azaldı.

Android 4.4 KitKat'ta Google, Dalvik'in deneysel bir yedeği olarak ART'yı (Android Runtime) tanıttı. Android 5.0 Lollipop'tan itibaren ART tek çalışma ortamı haline geldi. Temel fark AOT derlemesidir: yürütme sırasında derlemek yerine, tüm uygulamalar kurulum sırasında makine koduna derlenir. Bu, ısınma gecikmelerini ortadan kaldırdı ve enerji verimliliğini artırdı.

Geriye dönük uyumluluk

Dalvik'ten ART'ye geçiş, geliştiriciler için şeffaftı: her iki çalışma ortamı da aynı DEX bayt kodunu yürütür. Dalvik için derlenmiş uygulamalar, yeniden derleme olmadan ART'de çalışır — system_server bunları kurulum sırasında yerel koda derler. İstisna, Dalvik VM'nin iç üyelerine erişmek için yansıma kullanan koddur: bu tür kod, iç mimarideki değişiklikler nedeniyle ART'de bozulabilir.