La differenza tra ODEX, DEODEX e ZIPALIGN

Si leggono spesso termini del tipo ROM odexed, deodexed, zipaligned, ma altrettanto spesso non si conosce il significato di questi termini e cosa li differenzia l’uno dall’altro. Con questo articolo vogliamo quindi fare chiarezza spiegandovi tutte le differenze tra odex, deodex e zipalign.


ODEX

Dobbiamo sapere che i file APK (ovvero file di applicazioni) contenuti nelle ROM stock sono sostanzialmente dei file ZIP, al cui interno vi sono contenuti informativi. Il codice Java che è quello che dovrà essere eseguito per il lancio di un’applicazione viene memorizzato in un file che si chiama classes.dex che risiede all’interno del file APK. Classes.dex viene quindi inviato alla Dalvik JVM e poi elaborato. Successivamente una cache di questo file viene inviata alla Dalvik cache che si occuperà di eseguire alcune istruzioni. Giusto per completare il discorso, per non andare troppo nel dettaglio basta sapere che la Dalvik JVM è una macchina virtuale che si occupa di far girare le applicazioni su Android. L’utilità di avere un file classes.dex è molto importante, in quanto si occupa di pre-caricare all’avvio del sistema operativo alcuni file dell’applicazione, in modo da garantirle tempi di avvio rapidi.

Da qui scaturisce il termine ROM ODEXED, ovvero una ROM in cui sono presenti file classes.dex di ogni applicazione. Solitamente queste non sono delle ROM che si prestano molto al theming, ovvero alla personalizzazione grafica, in quanto quest’ultima risulta di difficile realizzazione.


DEODEX

Un’applicazione DEODEXED è invece un’applicazione il cui file classes.dex non viene pre-caricato nella Dalvik cache. In poche parole, il contenuto informativo del classes.dex viene accorpato nell’intero file APK dell’applicazione e la Dalvik cache non avrà nessun file da eseguire, in quanto la cache del file classes.dex le sarà inviata al momento dell’avvio dell’applicazione. Questo comporta una conseguente riduzione del tempo di avvio del sistema operativo (non si hanno file da pre-caricare) ma anche una conseguente leggera lentezza in più durante l’avvio di un’applicazione.

Dunque, effettuare il DEODEXING di una ROM significa eliminare dalla Dalvik cache i file classes.dex delle applicazioni e fare in modo che tutto il contenuto informativo rimanga all’interno del solo file APK. Questo può essere utile soprattutto agli sviluppatori per poter realizzare delle ROM contenenti diversi file APK presi in prestito da altre ROM, ed anche per poter applicare dei temi all’interfaccia in maniera molto più rapida e semplice.


ZIPALIGN

Esistono alcune istruzioni nei linguaggi di programmazione (assembly, Java, C…) che richiedono che i dati siano allineati. Cosa significa questo? Immaginiamo di avere una libreria con 10 mensole su cui voglio sistemare delle collezioni di fumetti. La mia collezione di Paperinik occupa 2 mensole, quella di Spider Man ne occupa una e mezzo, Topolino occupa 4 mensole e mezzo e quella di Thor una sola mensola. Come posso fare per mantenerle separate e facilmente distinguibili?

La risposta più semplice è che metta ogni collezione separata, per cui se anche occupa mezza mensola rimane da sola. Mezza mensola rimarrà quindi vuota. In questo modo riesco a tenere separati e facilmente indicizzabili i miei fumetti.

Lo stesso meccanismo si può applicare anche ai dati: posso stabilire che un numero n di byte corrisponde ad una mensola, e quindi posso decidere che i miei dati devono essere separati dagli altri. Esempio pratico: ho un dato da 7 byte, un dato da 3 byte, un dato da 4 byte e un dato da 2 byte. L’allineamento è ogni 4 byte (la mia “mensola” è di quattro byte). Rappresentiamo graficamente questa situazione.

Dato 1 (7 byte)
Dato 1 (7 byte)
Dato 1 (7 byte)
Dato 1 (7 byte) -> primi 4 byte
Dato 1 (7 byte)
Dato 1 (7 byte)
Dato 1 (7 byte)
[spazio vuoto] -> perchè avanza un byte rispetto ai 4 della “mensola”
Dato 2 (3 byte)
Dato 2 (3 byte)
Dato 2 (3 byte)
[spazio vuoto] -> perchè avanza nuovamente un byte rispetto ai 4 della “mensola”
Dato 3 (4 byte)
Dato 3 (4 byte)
Dato 3 (4 byte)
Dato 3 (4 byte) -> non avanza nessuno spazio vuoto!
Dato 4 (2 byte)
Dato 4 (2 byte)
[spazio vuoto]
[spazio vuoto] -> doppio spazio vuoto perchè il dato è di 2 byte ma la “mensola” è di 4.

Lo zipalign consiste nell’allineamento dei dati dei pacchetti delle applicazioni (i famosi file “.apk”) ogni 4 byte, così che sia più facile indicizzarli e raggiungerli con istruzioni che richiedono l’allineamento (ad esempio mmap()).

Questo meccanismo consente di gestire più facilmente i dati quando li si deve caricare in RAM. È infatti più semplice trovare un dato sapendo che può iniziare solo ad indirizzi di memoria di tipo 4n (ovvero multipli di 4) invece che ad indirizzi totalmente casuali. Lo zipalign è dunque un metodo per far funzionare più velocemente le applicazioni e consentirne tempi di avvio più veloci.


Speriamo dunque di avervi fatto comprendere l’importante significato dei tre termini più frequenti che si possono incontrare leggendo le caratteristiche di una custom ROM.

Inoltre, qualora siate curiosi di conoscere altri tipi di differenze che non vi sono chiare, fateci richiesta e cercheremo di accontentarvi. Naturalmente, qualora vi accorgiate di qualche imperfezione, potete commentare e gentilmente segnalarcela.

Nota: questo articolo è frutto della collaborazione tra Giuseppe e Riccardo.

Commenti

Ti invitiamo ad usare toni consoni e di rimanere in tema all'argomento trattato, in caso contrario, il sistema automatico potrebbe oscurare il tuo messaggio e potrebbero trascorrere fino a 48h per la verifica ed un'eventuale autorizzazione.
TuttoAndroid si riserva comunque il diritto di allontanare le persone non adatte a tenere un comportamento corretto e rispettoso verso gli altri.

  • Luca D’Alba

    Per quanto riguarda la differenza tra odex e deodex non sono pienamente d’accordo.. comunque per quanto ne so teoricamente e per quello che ho potuto vedere praticamente direi che all’inizio bisognerebbe mettere che di default nel file apk la “parte grafica” si trova nel file resources.arsc e la “parte eseguibile nel classes.dex .
    Questo nelle rom deodex.
    Poi nelle rom odex i file classes.dex di tutti gli apk di sistema vengono convertiti in .odex ed estratti dal file apk e messi in apposite cartelle così all’avvio del telefono vengono caricati i file .odex nella dalvik cache e gli apk di sistema sono più veloci ad avviarsi.. invece nelle rom deodex ciò non succede.
    Non è proprio la stessa cosa del dire che le “le rom odex hanno il classes.dex”.. il classes.dex alla fine ce l’hanno tutti.. solo che nelle rom odex viene convertito ed eliminato dall’apk..

    Invece complimenti per la spiegazione sullo zipalign;)

    Sono neofita sullo zipalign e mi sembra una bella spiegazione

  • Riguardo le differenze tra odex e deodex è TUTTO sbagliato!

    • Alex

      Ecco, per una volta che mi pareva di aver afferrato il concetto …. DOH!

    • Roger214

      Perchè scusa?

  • mgas138

    Grande! Grazie per l’articolo, mi serviva prorpio questa delucidazione. Solo un domanda mi assilla, ovvero posso avere una rom che è sia odex, sia zipalign?

    Grazie

  • Pingback: [ROM] [GT- I9505 XXUAMDM] Deodexdex stock firmware - Pagina 2 - Forum Android Italiano()

  • dariolap

    Complimenti, articolo ben fatto!

Top