Per spiegare quali sono le reali differenze fra ART e Dalvik è necessario fare un passo indietro e spiegare cosa sono realmente gli APK, qual è la loro struttura e in che modo vengono “letti” dal sistema.
Ogni APK fondamentalmente è un archivio zip, all’interno del quale sono presenti:
- Firma del pacchetto ( Cartella META-INF)
- Resources ( cartella Res: contiene tutta la parte dell’applicazione inerente alla grafica, quindi layouts XML, PNG relativi a pulsanti, icone e background, stringhe, attributi e stili)
- Classes.dex ( l’eseguibile Dalvik, all’interno del quale è presente il codice Java vero e proprio)
Android utilizza la Dalvik Virtual Machine ( o Dalvik VM) per eseguire il suddetto Classes.dex.
Ogni volta che la DVM processa un .dex, questo viene convertito e “immagazzinato” nella cache Dalvik e successivamente eseguito. Per ottimizzare i tempi di esecuzione, la Dalvik VM utilizza anche file Odex. Questi file non sono altro che una versione “pre-processata” del Classes.dex presente nell’APK. Il vantaggio dell’utilizzo di file Odex è che non solo rende più rapida l’esecuzione dell’applicazione ma riduce sensibilmente anche la quantità di cache Dalvik generata.
E’ proprio dai file Odex che iniziamo a parlare di ART (Android RunTime). Con Android 4.4 KitKat, Google ha iniziato l’integrazione di questo nuovo sistema, probabilmente anche grazie al team di Flexycore, recentemente acquisito dalla società . Al momento le informazioni su questo nuovo sistema sono davvero minime purtroppo ma elencherò tutte le informazioni emerse fino ad ora.
ART è un nuovo Runtime che non analizzerà i file Odex, bensì file Oat. I primi benchmark hanno dimostrato che ART è in grado di dimezzare(quasi) i tempi di elaborazione dei dati, con conseguente incremento delle prestazioni del sistema.
Quelli che vedete sopra sono i risultati dell’analisi di Array di Integers (numeri interi), contenenti da 1000 sino a 100.000 elementi utilizzando Dalvik VM, ART e JNI. Va sottolineato che i test sono stati eseguiti in un emulatore, e questo ha portato ad alcuni picchi, mentre, come dimostrato Qui , su un dispositivo i risultati sono decisamente più costanti. Molti, guardando questo grafico si chiederanno perchè a questo punto, Android non utilizza JNI (Java Native Interface). Ebbene, JNI consente al codice Java di richiamare codice nativo, scritto in linguaggi diversi da Java ( C, C++, Assembly) specifico per ogni Sistema Operativo, e questo comporta anche l’alta probabilità che, su diversi dispositivi/OS, il metodo nativo dichiarato nel codice java non venga eseguito. In sostanza, JNI non è utilizzabile perchè porterebbe ad instabilità e incompatibilità .
Allo stato attuale, tramite le impostazioni per sviluppatori, è in grado di eseguire lo switch fra Dalvik e ART runtime. Quando si esegue lo switch fra questi 2 , Android eseguirà anche lo switch fra libdvm.so e libart.so. Stando ai sorgenti inoltre, in Android 4.4 è presente anche il binario dex2oat, il quale si occuperà di convertire tutti i file Odex in Oat.
I primi risultati di questo nuovo compiler sono molto promettenti. Non ci resta che attendere le prossime release Android per vederne il vero potenziale.