Runtime ART

A differenza di altre piattaforme mobile come iOS o Windows dove il software è compilato nativamente sull'architettura hardware, in Android il software si base su un linguaggio generico che viene trasformato in byte-code nativo per l'architettura hardware.

art.jpg

 

Android RunTime ART, è il successore del Dalvik runtime, la virtual machine che esegue il codice java per Android. Con la versione KitKat di Android abbiamo visto una prima apparizione di ART. Infatti si poteva scegliere se utilizzare il vecchio Dalvik oppure provare ART. ART e Dalvik sono compatibili ed entrabe eseguono il Dex Byte-code in modo da garantire la retro compatibilità delle App.

La sostanziale differenza fra le due virtual machine sta nel tempo di compilazione. Per Dalvik la compilazione avviene in just-in-time, quindi ogni volta che un app viene lanciata, mentre per ART la compilazione è ahead-of-time che sposta la fase di compilazione prima dell'esecuzione. Cioè durante l'installazione delle apps il codice in linguaggio intermedio (java) viene compilato in codice binario nativo per la piattaforma hardware. Tutto attraverso un tool, dex2oat, che accetta in input file DEX generando eseguibili per il device.

 


 

 

Questa nuova compilazione delle applicazioni occupa spazio, e questa nuova metodologia è stata adottata solo oggi grazie alle dimensioni di archiviazione disponibile sui dispositivi. Un grande cambiamento evidente solo nei dispositivi di fascia alta. Infatti bisogna ricordare che molti sono i marchi che producono con storage ancora limitato.

APK-lifetime.png

Grazie al runtime ART si ottengono una gran quantità di ottimizzazioni che  in passato non erano possibili. Il codice è ottimizzato e compilato solo una volta realizzando ottimizzazioni di livello superiore su tutto il codice base di un'applicazione. Il compilatore ART ha una visione totale del codice, a differenza del compilatore JIT che ottimizza solo pezzi locali. In generale, i controlli di eccezione sono in gran parte rimossi dal codice, e le chiamate a metodi ed interfacce sono notevolmente accelerate. Il processo che fa questo è il nuovo componente dex2oat, che sostituisce l'equivalente dexopt Dalvik. Il file ODEX (dex ottimizzato) viene sostituito dal file ELF.

Questo porta ai seguenti miglioramenti:

  • Le prestazioni risultano migliorate rispetto alla compilazione Dalvik. Questo porta anche a migliorare il consumo della batteria del device.
  • Non c'è cache di codice runtime. I file OAT (oppure ELF) sono mappati direttamente in memoria. L'occupazione di memoria RAM per i file OAT può sembrare più grande in proporzione al Set Size, ma l'impatto generale del sistema è migliorata in termini di memoria reale rispetto alla cache Dalvik JIT.
  • ART  pre-inizializza un insieme di classi in fase di compilazione. Questo crea un file 'boot.art' che comprende un'immagine delle classi pre-inizializzate e oggetti correlati. Questo file è mappato in memoria. Nonostante un consumo aggiuntivo (circa 10 MB) si evidenzia un avvio più rapido e l'opportunità per il sistema di scambiare alcune classi pre-caricate in memoria. Ciò contribuisce anche a migliorare le prestazioni di accesso alla RAM

L'unico lato negativo di tutto ciò è che questa compilazione richiede più tempo per essere completata (circa 2 o 3 cicli di istruzione in più). Il primo avvio del dispositivo, o il primo avvio di un'applicazione saranno più lenti rispetto ad un sistema di Dalvik equivalente. Google sostiene che questo non è troppo drammatico poichè ottimizzazioni future di ART porteranno a tempi di esecuzione pari o migliori rispetto al Dalvik.

 

Ben tornato