- Dalvik lavorava utilizzando la compilazione JIT, traducendo il codice mentre l'applicazione era in esecuzione.
- ART ottimizza il sistema utilizzando la compilazione AOT, eseguendo il processo durante l'installazione.
- Entrambi gli ambienti utilizzano il formato di file DEX, garantendo la compatibilità tra le versioni.
- Il passaggio alla tecnologia ART ha permesso di ridurre il consumo di batteria e di migliorare la fluidità del sistema.
Se vi siete mai chiesti cosa succede realmente "dietro le quinte" del vostro telefono quando aprite un'app, la risposta si trova nell'ambiente di runtime. Nell'ecosistema Android, siamo passati da un'architettura basata sulla macchina virtuale Dalvik a un sistema molto più robusto chiamato Android Runtime, meglio noto come ART. In sostanza, ART è responsabile della traduzione del codice scritto dai programmatori in istruzioni che l'hardware del dispositivo può comprendere senza bloccarsi.
Per comprendere questo concetto, è importante sapere che Android non esegue Java in modo nativo; utilizza invece un adattamento personalizzato . Tutto inizia con il codice sorgente, che viene trasformato in bytecode e infine convertito in un formato specifico chiamato DEX. A seconda che la versione di Android in uso sia vecchia o nuova, il percorso di esecuzione di questo codice cambia drasticamente, influenzando aspetti quotidiani come la durata della batteria e la velocità di caricamento delle app.
L'eredità di Dalvik: l'era del Just-In-Time
Dalvik è stato un pilastro fondamentale fin dagli albori di Android. Il suo obiettivo era chiaro: consentire alle applicazioni scritte in Java di funzionare su dispositivi con risorse molto limitate . A differenza di una macchina virtuale Java standard, Dalvik era ottimizzato per utilizzare meno memoria ed eseguire più istanze simultaneamente, delegando la gestione dei thread al kernel Linux.
La caratteristica principale di Dalvik era la compilazione Just-In-Time (JIT) . Ciò significava che il codice veniva tradotto in linguaggio macchina precisamente quando l'utente interagiva con l'applicazione. Per evitare di ripetere questa operazione noiosa ogni volta, Dalvik creava file chiamati ODEX (Optimized DEX) , che memorizzavano le parti già tradotte in una cache. Il problema era che questo processo di compilazione costante consumava cicli della CPU e, di conseguenza, consumava più energia.
Android Runtime (ART): il salto verso l'Ahead-Of-Time
A partire da Android 5.0 Lollipop, ART ha preso completamente il sopravvento. La grande differenza sta nell'implementazione della compilazione Ahead-Of-Time (AOT) . Invece di attendere l'apertura dell'applicazione, ART si occupa del lavoro più gravoso durante l'installazione. Utilizza uno strumento chiamato dex2oat per convertire i file DEX in eseguibili ELF (Executable and Linkable Format), che sono nativi di Linux.
Grazie a questo approccio, quando si tocca l'icona di un'app, il sistema non deve compilare nulla; si limita a leggere il file ELF e ad eseguirlo. Ciò significa che il processore lavora meno, la batteria dura più a lungo e le app risultano molto più fluide. Tuttavia, c'è un piccolo compromesso: l'installazione delle app richiede un po' più di tempo e queste occupano più spazio di archiviazione rispetto a Dalvik.
Confronto tecnico e principali miglioramenti
Sebbene entrambi gli ambienti siano compatibili e utilizzino lo stesso bytecode DEX, ART ha introdotto miglioramenti che rendono il sistema incredibilmente veloce. Uno dei più significativi è la gestione della memoria (garbage collection, GC) . In Dalvik, il garbage collector causava quelle fastidiose pause o "scatti" nell'interfaccia (il famigerato lag). ART ha riprogettato questo sistema con un approccio prevalentemente concorrente , rendendo le pause indipendenti dalla quantità di memoria utilizzata.
- Debug avanzato: ART consente agli sviluppatori di visualizzare quali blocchi sono detenuti dai thread e di tracciare le istanze delle classi con una precisione molto maggiore.
- Diagnosi accurata: Ora, quando un'app si arresta in modo anomalo, i report degli errori sono molto più dettagliati, soprattutto nei casi di NullPointerException.
- Gestione della memoria: A differenza di Dalvik, che utilizzava una cache non paginabile, ART utilizza la memoria RAM che è possibile la paginazione, ottimizzando l'utilizzo dell'hardware.
Il processo di creazione del pacchetto: dal codice all'APK
Affinché uno qualsiasi di questi ambienti funzioni, il codice deve passare attraverso una catena di montaggio. Innanzitutto, il compilatore Java crea i file .class, che lo strumento dex converte poi in un singolo file classes.dex. Questo file è il nucleo dell'APK ed è ciò che ART o Dalvik elaboreranno.
Strumenti come aapt vengono utilizzati per impacchettare le risorse, mentre zipalign ottimizza l'allineamento dei dati, garantendo che il processore acceda alla memoria nel modo più efficiente possibile. Una volta che l'APK raggiunge il dispositivo, avviene la magia: se è presente ART, viene generato il file ELF ; se è presente Dalvik, il file ODEX inizia a essere generato al volo.
Curiosità sulle ROM e sul processo di deodexing
Nel mondo delle ROM personalizzate, i termini odex e deodex sono comunemente usati . Poiché il file ODEX è dipendente dall'hardware e dal sistema specifico su cui è stato creato, non può essere facilmente trasferito da un telefono all'altro. Per modificare un'app senza mandare in crash il sistema, gli sviluppatori eseguono un processo di deodexing , che consiste nell'integrare il file ottimizzato all'interno dell'APK per facilitarne la manipolazione.
L'ecosistema Android si è evoluto da una macchina virtuale flessibile ma ad alto consumo energetico a un ambiente di runtime ottimizzato che privilegia l'esperienza utente. Mentre Dalvik si concentrava sulla versatilità della traduzione del codice in tempo reale, ART ha massimizzato l'utilizzo dell'hardware attraverso la precompilazione , garantendo che il software sia più stabile, veloce ed efficiente dal punto di vista energetico.
Indice