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.