- Dalvik funcionava mitjançant compilació JIT, traduint el codi mentre l'app s'executava.
- ART optimitza el sistema mitjançant compilació AOT, realitzant el procés durant la instal·lació.
- Tots dos entorns utilitzen el format de fitxer DEX, assegurant la compatibilitat entre versions.
- La transició a ART ha permès reduir el consum de bateria i millorar la fluïdesa del sistema.
Si alguna vegada t'has preguntat què passa realment sota el capó del mòbil quan obris una aplicació, la resposta és a l'entorn d'execució. A l'ecosistema d'Android, hem passat d'una arquitectura basada en la màquina virtual Dalvik a un sistema molt més robust anomenat Android Runtime, més conegut com a ART. Bàsicament, són els encarregats que el codi que escriuen els programadors es converteixi en instruccions que el maquinari del dispositiu pugui entendre sense tornar-se boig.
Per entendre això, cal saber que Android no corre Java de forma nativa, sinó que utilitza una adaptació pròpia . Tot comença amb el codi font que es transforma en bytecode i acaba en un format específic anomenat DEX. Depenent de si la teva versió d'Android és antiga o moderna, el camí que segueix aquest codi per executar-se canvia radicalment, afectant coses tan quotidianes com la durada de la bateria o la velocitat amb què carrega una app.
El llegat de Dalvik: L'era del Just-In-Time
Dalvik va ser el pilar fonamental des dels inicis d'Android. El seu objectiu era clar: permetre que aplicacions escrites a Java funcionessin en dispositius amb recursos molt limitats . A diferència d'una màquina virtual de Java estàndard, Dalvik va ser optimitzada per ocupar menys memòria i executar diverses instàncies alhora, delegant la gestió de fils al nucli de Linux.
La característica estrella de Dalvik era la compilació Just-In-Time (JIT) . Això vol dir que el codi es traduïa a llenguatge màquina just en el moment que l'usuari interactuava amb l'app. Per no repetir aquest treball tediós cada vegada, Dalvik creava uns fitxers anomenats ODEX (Optimized DEX) , que guardaven les parts ja traduïdes en una memòria cau. El problema és que aquest procés constant de compilació consumia cicles de CPU i, per tant, gastava més energia.
Android Runtime (ART): El salt a l'Ahead-Of-Time
A partir d'Android 5.0 Lollipop, ART va prendre el relleu del tot. La gran diferència és que ART implementa la compilació Ahead-Of-Time (AOT) . En lloc d'esperar que obris l'aplicació, ART fa la feina bruta durant la instal·lació. Utilitza una eina anomenada dex2oat per convertir els fitxers DEX en executables ELF (Executable and Linkable Format), que són nadius de Linux.
Gràcies a aquest enfocament, quan premeu la icona d'una app, el sistema no ha de compilar res; simplement llegeix el fitxer ELF i l'executa. Això es tradueix que el processador treballa menys, la bateria dura més i les aplicacions se senten molt més fluides. Això sí, té un cost petit: la instal·lació de les apps triga una mica més i ocupen més espai d'emmagatzematge que amb Dalvik.
Comparativa tècnica i millores clau
Tot i que tots dos entorns són compatibles i executen el mateix codi de bytes DEX, ART ha portat millores que fan que el sistema voli. Una de les més importants és la recol·lecció d'escombraries (GC) . A Dalvik, el recol·lector d'escombraries solia causar aquestes molestes pauses o “tirons” a la interfície (el famós lag). ART ha redissenyat això amb un sistema principalment concurrent , fent que les pauses siguin independents de la mida de la memòria utilitzada.
- Depuració avançada: ART permet als desenvolupadors veure quins bloquejos mantenen els fils i rastrejar instàncies de classes amb molta més precisió.
- Diagnòstics precisos: Ara, quan una app falla, els informes derrors són molt més detallats, especialment en casos de NullPointerException.
- Gestió de memòria: A diferència de Dalvik, que feia servir una memòria cau no paginable, ART utilitza memòria RAM que es pot paginar, optimitzant lús del maquinari.
El procés d'empaquetament: Del codi a l'APK
Perquè funcioni qualsevol d'aquests entorns, el codi ha de passar per una cadena de muntatge. Primer, el compilador de Java crea fitxers .class, que després l'eina dex converteix en un únic fitxer classes.dex. Aquest fitxer és el cor de l'APK i és el que ART o Dalvik processaran.
Hi ha eines com aapt per empaquetar recursos i zipalign per optimitzar l'alineació de dades, assegurant que el processador accedeixi a la memòria de la manera més eficient possible. Un cop l'APK arriba al dispositiu, és on passa la màgia: si hi ha ART, es genera l' arxiu ELF ; si hi ha Dalvik, es comença a generar el fitxer ODEX sobre la marxa.
Curiositats sobre ROMs i el procés de Deodex
En el món de les ROMs personalitzades, és comú escoltar els termes odexar i deodexar . Com que el fitxer ODEX és dependent del maquinari i del sistema exacte on es va crear, no es pot moure d'un mòbil a un altre fàcilment. Per poder modificar una app sense que el sistema peti, els desenvolupadors realitzen un procés de deodexació , que consisteix a integrar larxiu optimitzat dins de lAPK per facilitar la seva manipulació.
L'ecosistema Android ha evolucionat des d'una màquina virtual flexible però costosa en energia fins a un entorn optimitzat d'execució que prioritza l'experiència de l'usuari. Mentre Dalvik apostava per la versatilitat de traduir el codi en temps real, ART ha aconseguit que el maquinari s'aprofiti al màxim mitjançant la compilació prèvia , garantint que el programari sigui més estable, ràpid i eficient en el consum elèctric.