[ad#ad-cesco]
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.
VOGLIAMO ANDREA GALEAZZI!!!
[…] (…)Continua a leggere Abdroid 4.4 KitKat: il nuovo Runtime Compiler ART su Androidiani.Com […]
grazie per questo articolo. l’ho trovato molto interessante.
Finalmente un bell’articolo! Complimenti!
ho letto l’articolo sul forum ufficiale google, ho delle buone conoscenze ma vorrei capirne un po di più per comprendere bene cosa tutto accade li sotto…
comunque, articolo interessante, quoto.
sicuramente ci voleva una svolta, ho sempre trovato la dalvik pesante, è il problema principale di android rispetto alla concorrenza…
Azz per me e arabo :( non ne capisco quasi nulla di ste cose …. sti termini cmq ok tanto il note 2 verrà lasciato nel cassetto e nn aggiornato da samsung a quanto pare …….
Ma che cacchio dici LOL
‘A quanto pare’ cosa, hanno fatto un bel po di articoli sull’aggiornamento del Note 2, e si è sicuri che sarà aggiornato.
[…] (…)Continua a leggere Abdroid 4.4 KitKat: il nuovo Runtime Compiler ART su Androidiani.Com […]
Esaustivi…bravi e speriamo ART diventi operativo quanto prima.
Avreste dovuto precisare che JNI viene usato eccome in Android a livello di singole apps (soprattutto giochi) tramite librerie che richiamano funzioni native e non scritte in Java, che vanno quindi compilate per ogni OS/processore che si vuole supportare: quello che invece fa ART è ricompilare al volo tutto (o quasi) il codice Java delle applicazioni (infatti è un JIT basato su LLVM) per rendere più veloce l’esecuzione di Java stesso senza costringere lo sviluppatore ad appoggiarsi a linguaggi esterni e a basso livello come C/C++ per le porzioni di codice più pesanti dal punto di vista delle prestazioni…
Non c’è solo LLVM in ART. Lavora in due modalità: portable e quick.
La modalità portable sfrutta LLVM come linguaggio intermedio (poi compilato in linguaggio macchina con mclinker), la modalità quick invece lavora direttamente nel linguaggio macchina ospite (sono supportati x86, ARM e mips, tutti a 32 bit).
Secondo me in entrambe le modalità non si può parlare di JIT perché non c’è più una macchina virtuale che inizia ad eseguire il codice, ma il codice viene compilato prima di essere eseguito.
I file OAT sembrano essere un contenitore per le APK che rende più agevole il lavoro di analisi. Non escludo che alla fine dei giochi questo possa anche contenere codice LLVM o nativo, senza bisogno di compilazione on the fly.
Il runtime contiene una implementazione JNI delle API Java. Probabilmente l’uso di JNI rende più semplice il lavoro di traduzione.
Avevo letto altrove che, abilitando ART, il sistema va totalmente in crash e non potrebbe neppure essere avviato. Onestamente, mi pareva una cosa un po’ esagerata, ma non so.
alsune applicazioni vanno in crash abilitando ART, ne sono un esempio le gapps AOSP, whatsapp e titanium backup, per ovviare alle gapps #Gn0me di xda è riuscito a modificare le gapps portandole dalla rom leakata del nexus 5 ed è possibile effettivamente abilitare ART anche sulle rom AOSP…però è ancora tutto troppo sperimentale e molte applicazioni di terze parti neanche si instalano :)
Mmmh io sono su CM11 temasek con art attivato e tutte le 200+ app che ho funzionano, in particolare whatsapp e titanium pro. Alcune gapps *talvolta* vanno in fc, è capitato 3-4 volte in due settimane. Quello che ho notato è la durata della batteria a mio avviso migliorata nettamente, arrivo a 36 ore di contro le 20 precedenti (90% in standby ma con connettività sempre attiva).
Molto interessante e chiaro. Bell’articolo.
In realtà Android utilizza il JNI… le parti scritte con l’NDK infatti non girano sotto la Dalvik.
Comunque quel grafico non rappresenta l’analisi di array di interi, bensì la performance, in millisecondi, dell’algoritmo quick sort (uno dei più semplici e famosi) per riordinare (in questo caso) i numeri. Da lì si può effettuare un’analisi, ma non è un’analisi di per sé.
Ultimo commento: Art non è un compilatore, ma una nuova virtual machine. Il “compilatore” semplicemente converte i file dex (compilati per la Dalvik) in file oat (compilati per Art).
http://source.android.com/devices/tech/dalvik/art.html
“ART is a new Android runtime being introduced experimentally in the 4.4 release.”
http://www.xda-developers.com/android/new-runtime-compiler-in-android-4-4/
“BREAKING: New Runtime Compiler in Android 4.4 to Possibly Bring Better Performance in Future Releases”
Non aggiungo altro B)
Le virtual machine eseguono in real time (JIT) codice parzialmente compilato e quindi prima devono pre-compilarselo. Ma Art non è un compilatore, ma una VM, quindi non è tecnicamente un compiler. Al suo interno è presente un compiler, ma è riduttivo chiamarlo tale. Tra l’altro non credo neanche che tutte le VM abbiano un compilatore integrato (non vorrei dire una fesseria, ma dubito che la VM .NET ce l’abbia).
Art è un compilatore, non ha una virtual machine.
Il codice LLVM della modalità portable viene tradotto in linguaggio macchina da mclinker.
E sì, .Net, almeno su Windows, ha il JIT ;-)
Quindi Art compila completamente le applicazioni in linguaggio macchina e le fa eseguire in modo nativo sotto forma di file OAT? Così fosse dovrebbe girare meglio o come JNI, ti pare?
Mi manca ancora qualche tassello sinceramente, ho guardato il sorgente per pochi minuti. L’OAT non dovrebbe essere eseguito direttamente, ma dovrebbe venire preso, spacchettato, eventualmente compilato e linkato per essere eseguito direttamente in linguaggio macchina. Nella cache di ART ci dovrebbe essere solo codice in linguaggio macchina.
[…] (…)Continua a leggere Android 4.4 KitKat: il nuovo Runtime Compiler ART su Androidiani.Com […]
[…] Da KitKat, Google ha dato la possibilità agli sviluppatori di testare il nuovo runtime compiler ART, che andrebbe a sostituire quello di default, Dalvik. Perchè ART dovrebbe essere meglio di Dalvik? ART precompila (procedimento AOT, Ahead-Of-Time) in precedenza le applicazioni, portando, almeno in teoria, una serie di vantaggi, come una migliore durata della batteria e una maggiore velocità di tutto il sistema operativo. Per ulteriori informazioni su Dalvik e ART, leggete questo nostro precedente articolo. […]
Ciao,
ad oggi di Voi chi utilizza ART, ne avete giovato non solo sulla carta?