Dalle sue origini, Android era basato su DalvikE per molto tempo questa è stata la macchina virtuale utilizzata dal sistema operativo, ma con Android è arrivato KitKat ARTE o Android Runtime in alternativa, e divenne il sostituto definitivo da Android LollipopMa di cosa si tratta esattamente? Si tratta di ambiente di runtime dell'applicazione del sistema operativo Android.
ART o runtime Android è la macchina virtuale Android, il tuo ambiente di esecuzione delle applicazioni. Con Dalvik, a partire da Android 2.2 Froyo, il sistema operativo utilizzava JIT (Appena in tempo) per la compilazione del codice in ogni esecuzione di un'applicazione. ARTE, tuttavia, ha sostituito questa tecnologia con l'uso di AOT (In anticipo). E la differenza è che questa tecnologia crea un crea file dopo aver installato un'applicazione. In questo modo, il file viene utilizzato quando l'applicazione è in esecuzione e non deve essere compilazione costante quando viene eseguito. Puoi leggere Come utilizzare la macchina virtuale ART sul tuo dispositivo.
ART o Android Runtime e i vantaggi sulle prestazioni del sistema operativo
Grazie a questo importante cambiamento, Android non esegue una quantità così grande di compilazioni per ogni applicazione. Il risultato è semplice come il uso della CPU è significativamente ridotto aumentando le prestazioni per lo stesso hardware, e il risparmio batteria è anche considerevole. Ma anche, rispetto alla precedente macchina virtuale Dalvik, ARTE Introduce altri miglioramenti delle prestazioni come debug e profilazione delle app e raccolta rifiuti più efficiente. L'utente non nota alcuna differenza tra un ambiente di runtime dell'applicazione e l'altro a livello visivo, ma le differenze interne sono davvero significative.
Il problema che Google ha affrontato, nel cambio da Dalvik ad ARTÈ nella compatibilità, qualcosa che ha interessato modelli come il Samsung Galaxy S5Per questo hanno progettato ART utilizzando l' stesso bytecode input di Dalvik, fornito da file .dex standard informazioni sugli APKCiò che è stato modificato sono stati i file .odex, che sono stati sostituiti da file ELF. Perché? Perché quando si compila un'app con ART sul dispositivo, questa viene eseguita da ELF compilato specificamente per l'architettura del dispositivo.
Sebbene tutto ciò implichi un tempo extra Per la compilazione durante l'installazione dell'applicazione, ciò rappresenta una significativa riduzione dei costi relativi alla compilazione JIT di Dalvik. Un altro 'danno collaterale' è che, a causa di questo cambiamento, le applicazioni installate hanno un peso superiore a quello che avevano con Dalvik. Ma, come è evidente, la maggior parte dei cambiamenti sono Vantaggi di ART o Android Runtime davanti alla macchina virtuale Dalvik.
Dalvik e ART nell'architettura Android
Per capire perché Dalvik e ART sono così rilevanti, è utile inserirli nel contesto di architettura Android completaSebbene l'utente veda solo lo strato di applicazioniAl di sotto di questo si trovano un gran numero di componenti e livelli che fanno funzionare il tutto.
In alto ci sono i Applicazioni AndroidQueste sono le app che l'utente utilizza quotidianamente (app di messaggistica, social media, giochi, ecc.). Di seguito è riportato il Framework AndroidQuesto livello espone le API con cui lavorano gli sviluppatori: gestione delle finestre, notifiche, sensori, fotocamera, ecc. Questo livello è responsabile dell'astrazione della complessità e della traduzione delle richieste delle app a livelli inferiori.
Al di sotto del quadro troviamo il librerie native in C/C++Implementano in modo efficiente funzioni critiche (grafica, audio, video, database, ecc.). Gli sviluppatori possono accedervi tramite NDK quando devono lavorare a basso livello, ma è più comune farlo tramite framework.
Allo stesso livello si trova il Runtime Androided è qui che Dalvik e ART entrano in gioco. Questo strato include sia il Librerie del linguaggio Java come la macchina virtuale o l'ambiente di runtime su cui viene eseguita ciascuna applicazione. Tutte le applicazioni si basano su questo runtime per tradurre il bytecode in istruzioni macchina che possono essere eseguite dall'hardware.
Al di sotto del runtime si trova il meccanismo di Binder IPC (Inter-Process Communication), che consente ai diversi processi e servizi del sistema di comunicare tra loro in modo sicuro e strutturato. Attraverso Binder, il framework può chiamare il Servizi di sistema Android, che gestiscono funzionalità quali finestre, notifiche, media o telefonia.
Sotto questi servizi appare il livello di astrazione hardware (HAL)che offre un'interfaccia standard per l'accesso ai driver di dispositivo. Infine, tutto si basa su un Kernel LinuxResponsabile della gestione della memoria, dei processi, della sicurezza, della rete e dei controller. A un livello inferiore si trovano l'assemblatore, il firmware e l'hardware fisico.
Bytecode, DEX, ODEX ed ELF: come funziona un'app
Nella programmazione, il codice a byte È il risultato dell'elaborazione e dell'ottimizzazione del codice sorgente prima che venga eseguito da una macchina virtuale. Questo bytecode è portabile su più architetture e la macchina virtuale è responsabile della sua traduzione in codice macchina specifico del dispositivo su cui è in esecuzione.
In Android, i programmi sono in genere scritti in Java e prima compilati in bytecode Java standard. Vengono poi convertiti in bytecode specifico per Android, impacchettati nel formato DEX (Formato eseguibile Dalvik). Ogni APK di solito contiene un file classi.dex con tutte le classi compilate. Questo file è indipendente dall'hardware e deve essere tradotto in codice macchina per essere eseguito.
Con Dalvik, quella traduzione si materializza in file ODEX (DEX ottimizzato). Ogni volta che un'applicazione viene eseguita, Dalvik traduce dinamicamente le parti necessarie del file DEX e le memorizza nell'ODEX. Man mano che viene utilizzato altro codice, il file ODEX viene popolato. Questa attività viene eseguita dallo strumento. Dexopt.
Con ART, l'approccio cambia. Invece di compilare a runtime, lo strumento dex2avena Prende il file DEX durante l'installazione dell'applicazione e lo traduce completamente in un eseguibile nel formato ELFO (Executable and Linkable Format), tipico dei sistemi Linux. L'ELF contiene il codice macchina già predisposto per l'hardware del dispositivo, quindi non è necessario continuare la compilazione durante l'esecuzione.
Questa differenza nel flusso di lavoro (ODEX vs ELF) è fondamentale: con Dalvik, la compilazione viene eseguita JIT durante l'esecuzione, mentre con ART viene fatto AOT durante l'installazione. In cambio, le app occupare più spazio in magazzino, ma offrono partenze più veloci e un consumo inferiore di CPU ed energia.
Dal codice sorgente all'APK: come creare un'applicazione Android
Il processo di creazione di un'app Android combina gli strumenti Java JDK e Android SDK, in genere orchestrati da Gradle Da Android Studio, il sistema compila il codice, elabora le risorse, firma l'applicazione e la prepara per la distribuzione come file. APK.
Questo flusso di lavoro coinvolge diversi strumenti specializzati. L'utilità apt Compila il file AndroidManifest.xml e le risorse XML, generando il file R.java che consente di fare riferimento a essi dal codice. Lo strumento aiuto trasforma le interfacce .aidl in codice Java per la comunicazione tra processi.
Dopo il compilatore Java Prende tutto il codice sorgente, inclusi R.java e le classi generate da aidl, e produce file .class. A questo punto entra in gioco lo strumento. dex, che converte i file .class (e le librerie associate) in un singolo file DEX ottimizzato, rimuovendo stringhe e costanti duplicate per risparmiare spazio.
In scenari specifici, in particolare con emulatori e versioni precedenti di Dalvik, lo strumento Dexopt È possibile pre-generare un file ODEX AOT per velocizzare l'esecuzione. Infine, costruttore di apk Confeziona il DEX insieme alle risorse compilate e non compilate nell'APK finale, che è firmato con jarsigner e si allinea con zipalign per migliorare le prestazioni di accesso alle risorse.
L'APK risultante contiene il file DEX, le risorse compilate (XML, manifest, layout), le risorse non compilate (immagini, audio, video) e la firma. Il file ELF utilizzato da ART non è incluso nell'APK; viene generato in un secondo momento sul dispositivo stesso utilizzando dex2avena quando l'utente installa l'applicazione.
Installazione, ottimizzazione e memorizzazione nella cache: cosa fa il sistema quando installa un'app
Quando un APK viene installato, il file DEX che contiene è in uno stato pre-dexoptA quel punto il sistema esegue varie ottimizzazioni sul bytecode: adatta il formato dei dati in base all'architettura del processore (endianness), crea Strutture dati più semplice, collega le funzioni della libreria in linea e applica anche scorciatoie come corto circuito per le aule vuote.
Se il dispositivo utilizza ARTEDurante l'installazione, lo strumento viene richiamato dex2avenache trasforma il DEX in un eseguibile ELF completamente compilato. Se il dispositivo è basato su Dalvikil sistema può creare un file ODEX iniziale, che verrà completato con l'esecuzione JIT.
Una cosa curiosa che molti utenti hanno notato è che, dopo alcuni aggiornamenti di sistema, Android visualizza un messaggio come questo: “ottimizzazione delle applicazioni”Quel processo corrisponde esattamente al compilazione o ottimizzazione dei bytecode DEX delle app installate, generando un nuovo ELF per ART o aggiornando l'ODEX in Dalvik.
Dalvik: la macchina virtuale Android originale e la sua build JIT
Dalvik è un macchina virtuale sviluppata da Google Specificamente per Android. Sebbene ispirato alla Java Virtual Machine, introduce modifiche per adattarsi ai dispositivi con risorse limitate: occupa meno spazio, utilizza set di istruzioni a 16 bit e semplifica la tabella delle costanti con indici a 32 bit.
La sua caratteristica distintiva è la Compilazione Just-In-Time (JIT)Ogni volta che viene eseguita un'applicazione, il compilatore Dalvik traduce il bytecode DEX in codice macchina in tempo reale con l'aiuto dello strumento DexoptIl risultato viene memorizzato in un file ODEX, solitamente all'interno della directory dalvik-cacheper evitare di ricompilare sempre le stesse parti.
Ogni applicazione funziona da sola propria istanza della macchina virtualeQuesto garantisce l'isolamento: se un'app fallisce, le altre non ne risentono. Quando Dalvik apre un APK, estrae il DEX, crea o aggiorna l'ODEX se i permessi lo consentono ed esegue il codice compilato da lì.
La compilazione just-in-time (JIT) presenta importanti vantaggi: consente di adattare il codice a... CPU e sistema operativo specificiRaccoglie statistiche di esecuzione per applicare ottimizzazioni dinamiche e beneficiare delle ottimizzazioni globali senza sacrificare il collegamento dinamico delle librerie condivise. Tuttavia, comporta anche Latenze e consumi della CPU compilando durante l'esecuzione, il che si traduce in una minore autonomia e in un aumento del calore in alcuni scenari.
Strumento Dexopt e ottimizzazioni interne Dalvik
Lo strumento Dexopt È responsabile della verifica e dell'ottimizzazione delle classi nel file DEX. Esegue un'inizializzazione abbreviata della macchina virtuale, carica i file DEX necessari dal percorso di classe bootstrap e analizza tutte le istruzioni per rilevare sequenze non valide. Solo le classi verificate vengono ottimizzate e viene impostato un flag. bandiera nell'ODEX per evitare controlli ripetuti.
Le ottimizzazioni di Dalvik includono la sostituzione degli indici del metodo virtuale con indici di tabella verticale, sostituire gli indici dei campi con offset di byte, unire più tipi in un formato a 32 bit, eseguire inlining Elimina le chiamate molto frequenti (ad esempio, String.length()) e i metodi vuoti. Aggiunge inoltre dati precalcolati per velocizzare le esecuzioni future.
Queste ottimizzazioni presentano alcune complicazioni. Gli indici e gli offset della vtable possono cambiare se la macchina virtuale o il file DEX di una superclasse in un altro pacchetto vengono aggiornati, richiedendo la rigenerazione di ODEX. Inoltre, la directory dalvik-cache e le loro autorizzazioni variano tra gli ambienti di sviluppo e di produzione, condizionando quando e come possono essere generati gli ODEX.
ART, compilazione AOT e miglioramenti rispetto a Dalvik
ART introduce il Compilazione anticipata (AOT)Ciò comporta la conversione del bytecode DEX in codice macchina prima dell'esecuzione del programma, in genere durante l'installazione dell'APK. Lo strumento dex2avena Ciò genera un eseguibile ELF completo.
Le ragioni per optare per AOT sui dispositivi mobili sono chiare: ridurre il numero di build di runtime, diminuire il uso della CPU, salva batteria e accelerare il avvio dell'applicazioneAvere il programma e le sue librerie già compilati riduce i tempi di avvio e consente un utilizzo più efficiente della RAM.
ART apporta anche miglioramenti al netturbinoche diventa più prevedibile e meno invasivo, riducendo le interruzioni di prestazioni evidenti in alcune app ad alta intensità di risorse. Offre inoltre strumenti migliorati per debug e analisi delle prestazioniCiò aiuta gli sviluppatori a individuare colli di bottiglia e bug in modo più accurato.
Un altro vantaggio significativo è che l'ART non necessita di un Cache del codice JIT in fase di esecuzione, il che semplifica la gestione della memoria e consente una migliore paginazione del codice, poiché si tratta di eseguibili ELF convenzionali caricati dal sistema. Inoltre, il runtime può preinizializzare i set di classi in fase di compilazione, migliorando ulteriormente l'efficienza nell'utilizzo della RAM.
Il costo di tutto questo è che lo strumento dex2oat impiega più tempo di dexopt per compilare DEX in ELF. Tuttavia, questo investimento viene effettuato una sola volta (per installazione o aggiornamento), rispetto alle molteplici compilazioni parziali di Dalvik. Si guadagna in prestazioni di esecuzione in cambio di... tempo di installazione y immagazzinamento extra.
Vantaggi e svantaggi di ART rispetto a Dalvik su Android
A livello pratico, la maggior parte degli utenti percepisce che con ART le applicazioni Si aprono più velocementeIl multitasking è più fluido e il sistema risponde meglio sotto carico. Molte testimonianze indicano un notevole miglioramento nell' fluidità dell'interfaccia e nella durata della batteria quando l'ambiente è ben ottimizzato e le app sono compatibili.
Tra i principali vantaggi dell'ART In contrasto con Dalvik, spiccano i seguenti:
- Migliori prestazioni generali del sistema e delle applicazioni, grazie alla compilazione AOT completa.
- Minore consumo energeticoriducendo il lavoro di compilazione in fase di esecuzione e l'utilizzo intensivo della CPU.
- Un garbage collector più efficiente, con meno pause evidenti nelle app più impegnative.
- Strumenti migliorati per il debug, la profilazione e l'analisi delle prestazioni durante lo sviluppo.
- Nessuna cache JIT in esecuzioneCiò semplifica la gestione della memoria e migliora la paginazione.
Como svantaggi dell'ART Di fronte a Dalvik troviamo:
- Tempi di installazione o aggiornamento più lunghi delle applicazioni, grazie alla compilazione completa da DEX a ELF.
- Maggiore capacità di archiviazione delle app installate, salvando l'eseguibile ELF insieme all'APK e alle sue risorse.
- Possibili incompatibilità versioni iniziali con alcune ROM modificate o app che dipendevano da comportamenti Dalvik molto specifici.
- Meno margine per alcuni ottimizzazioni dinamiche molto avanzato che in teoria potrebbe sfruttare un JIT puro, anche se in pratica i vantaggi dell'AOT sono solitamente maggiori nel mobile.
Nonostante questi svantaggi, Android mantiene la retrocompatibilità continuando a utilizzare il bytecode .dex come formato di input, in modo che un'app progettata per ART possa essere eseguita anche su Dalvik nelle versioni precedenti, a condizione che il sistema e l'app lo consentano.
ART, Dalvik e ROM personalizzate: deodex, odex e cucine
Nel mondo di ROM personalizzateConcetti come ODEX, deodex, cache Dalvik e ART hanno un impatto diretto. Dalvik genera ODEX in base all'immagine del sistema, BOOTCLASSPATH e altri APK o JAR del framework, quindi ogni file ODEX dipende in larga misura dalla combinazione esatta di file con cui è stato creato.
Per i "cuochi" di ROM, questo presenta una difficoltà: se modificano un APK già installato senza aggiornare il suo file ODEX, potrebbero comparire degli errori. errori e chiusure forzateEcco perché molti scelgono di “deodexing” ROM, ovvero l'integrazione del contenuto dell'ODEX nell'APK stesso per eliminare le dipendenze esterne e facilitare le modifiche.
In una ROM deodexata, la prima esecuzione di un'applicazione richiede solitamente più tempo perché Dalvik deve rigenerare l'ODEX nella cache, ma in seguito il comportamento si normalizza. Al contrario, nelle ROM odexate, l'avvio dell'applicazione può essere inizialmente leggermente più veloce, a scapito di una maggiore rigidità in caso di modifiche al sistema.
Con ART, il ruolo dell'ODEX scompare a favore dell' Eseguibili ELFCiò semplifica alcuni aspetti, ma introduce altre sfide per gli sviluppatori di ROM, poiché il processo di compilazione AOT, la gestione ELF e le relazioni del framework devono essere presi in considerazione durante la creazione o la modifica di immagini di sistema personalizzate.
Questa nuova funzionalità di KitKat è una delle più interessanti, eppure all'epoca ricevette pochissima attenzione. Molti utenti la provarono quando era ancora un'opzione sperimentale, notando maggiore fluidità e velocità nel multitaskingTuttavia, alcune app popolari, come i servizi di messaggistica, hanno impiegato del tempo per diventare completamente compatibili.
Oggi, ART si è affermato come l'ambiente di runtime standard, mentre Dalvik rimane la tecnologia di riferimento storica. Comprendere il differenze tecniche tra i dueComprendere i loro vantaggi, svantaggi e il modo in cui si inseriscono nell'architettura Android aiuta a comprendere meglio perché lo stesso hardware può offrire sensazioni così diverse a seconda del runtime utilizzato.
Grazie a questo cambio di paradigma da JIT ad AOT, Android è stato in grado di offrire Prestazioni più elevate, migliore gestione della memoria e maggiore durata della batteria, mantenendo la compatibilità con l'ecosistema applicativo esistente e consentendo sia agli utenti che agli sviluppatori di beneficiare di una base tecnica più solida.
