La nuova virtual machine ART, introdotta definitivamente con il rilascio di Android Lollipop ma già presente su Kitkat tra le opzioni sviluppatore, rappresenta certamente la novità più importante tra quelle presenti nel codice di Android 5.0.
Il funzionamento di ART e le sue differenze rispetto alla Dalvik Virtual Machine sono state spiegate in diverse occasioni ma quest’oggi torneremo sull’argomento ed introdurremo una grossa novità che nei prossimi mesi troverà posto all’interno dei nostri smartphone e tablet.
Le applicazioni Android sono scritte prevalentemente in codice Java. Java è un linguaggio che si colloca nel mezzo tra le due categorie che vengono definite con i termini “interpretato” e “compilato”. Sviluppando in Java non si produce codice nativo (linguaggio macchina) ma piuttosto un codice intermedio denominato Bytecode.
Per essere eseguito il Bytecode necessita di una macchina virtuale che si occupi di tradurre il codice intermedio in codice nativo. Android ha utilizzato la macchina virtuale Dalvik fino alla versione 4.4 Kitkat. La Dalvik era basata su un sistema di compilazione denominato JIT (Just In Time) che “traduceva” il codice pochi istanti prima che venisse eseguito dalla CPU.
Nonostante gli indubbi vantaggi apportati dal codice interpretato (primo fra tutti l’indipendenza dalla piattaforma) le prestazioni risentivano pesantemente del sistema JIT.
Per questo motivo Google decise di introdurre ART (Android Runtime). ART è una macchina virtuale, esattamente come Dalvik, e integra al suo interno un interprete. La maggior parte del codice delle applicazioni, tuttavia, non viene interpretato ma compilato in codice nativo al momento dell’installazione. Questo sistema prende il nome di AOT (Ahead Of Time) compiler.
In questo modo viene mantenuta l’indipendenza dalla piattaforma ma allo stesso tempo si incrementa notevolmente l’efficienza in fase di esecuzione poiché la”traduzione” del Bytecode avviene in fase di installazione e non durante l’esecuzione del codice.
Della compilazione si occupa un apposito compilatore, denominato Quick Compiler. Tutti gli smartphone basati su Lollipop sfruttano al momento questo compilatore.
Quick rappresenta un indubbio passo in avanti rispetto al passato ma non è affatto perfetto. A dire il vero, il compilatore Quick può essere considerato come una sorta di versione AOT del compilatore JIT presente nella Dalvik.
Google e ARM stanno lavorando duramente per andare oltre Quick ed hanno quasi approntato un nuovo compilatore denominato Optimizing. Quest’ultimo non rappresenta una evoluzione di Quick dal momento che è stato realizzato a partire da zero.
Le caratteristiche principali di Optimizing sono le seguenti:
- approccio “compiler-first” (in pratica si tratterà di un vero compilatore, a differenza di Quick);
- dotato di una migliore infrastruttura per le ottimizzazione complesse;
- pienamente ottimizzato per l’architettura ARM a 64-bit (le piattaforme a 32 e 64-bit godranno di una ottimizzazione separata);
- capace di generare codice di maggiore qualità;
- maggiore lentezza in fase di compilazione.
Le performance nei benchmark sono superiori fino al 40% rispetto a Quick ma Google sta ancora lavorando per ridurre le dimensioni dei file e velocizzare i tempi di compilazione.
Lo sviluppo del nuovo compilatore è attualmente in corso (sarete felici di sapere che Optimizing è già stato introdotto di default all’interno dell’AOSP). Non sappiamo ancora quando Google ne annuncerà l’effettiva disponibilità per tutti gli utenti ma siamo certi che maggiori informazioni verranno fornite nel corso del Google I/O che si terrà dal 28 al 29 Maggio.