- Dalvik funcionaba mediante compilación JIT, traduciendo el código mientras la app se ejecutaba.
- ART optimiza el sistema mediante compilación AOT, realizando el proceso durante la instalación.
- Ambos entornos utilizan el formato de archivo DEX, asegurando la compatibilidad entre versiones.
- La transición a ART ha permitido reducir el consumo de batería y mejorar la fluidez del sistema.
Si alguna vez te has preguntado qué ocurre realmente bajo el capó de tu móvil cuando abres una aplicación, la respuesta está en el entorno de ejecución. En el ecosistema de Android, hemos pasado de una arquitectura basada en la máquina virtual Dalvik a un sistema mucho más robusto llamado Android Runtime, mejor conocido como ART. Básicamente, son los encargados de que el código que escriben los programadores se convierta en instrucciones que el hardware de tu dispositivo pueda entender sin volverse loco.
Para entender esto, hay que saber que Android no corre Java de forma nativa, sino que usa una adaptación propia. Todo empieza con el código fuente que se transforma en bytecode y termina en un formato específico llamado DEX. Dependiendo de si tu versión de Android es antigua o moderna, el camino que sigue ese código para ejecutarse cambia radicalmente, afectando a cosas tan cotidianas como la duración de la batería o la velocidad con la que carga una app.
El legado de Dalvik: La era del Just-In-Time
Dalvik fue el pilar fundamental desde los inicios de Android. Su objetivo era claro: permitir que aplicaciones escritas en Java funcionaran en dispositivos con recursos muy limitados. A diferencia de una máquina virtual de Java estándar, Dalvik fue optimizada para ocupar menos memoria y ejecutar varias instancias a la vez, delegando la gestión de hilos al núcleo de Linux.
La característica estrella de Dalvik era la compilación Just-In-Time (JIT). Esto significa que el código se traducía a lenguaje máquina justo en el momento en que el usuario interactuaba con la app. Para no repetir este trabajo tedioso cada vez, Dalvik creaba unos archivos llamados ODEX (Optimized DEX), que guardaban las partes ya traducidas en una caché. El problema es que este proceso constante de compilación consumía ciclos de CPU y, por ende, gastaba más energía.
Android Runtime (ART): El salto al Ahead-Of-Time
A partir de Android 5.0 Lollipop, ART tomó el relevo por completo. La gran diferencia es que ART implementa la compilación Ahead-Of-Time (AOT). En lugar de esperar a que abras la aplicación, ART hace el trabajo sucio durante la instalación. Utiliza una herramienta llamada dex2oat para convertir los archivos DEX en ejecutables ELF (Executable and Linkable Format), que son nativos de Linux.
Gracias a este enfoque, cuando pulsas el icono de una app, el sistema no tiene que compilar nada; simplemente lee el archivo ELF y lo ejecuta. Esto se traduce en que el procesador trabaja menos, la batería dura más y las aplicaciones se sienten mucho más fluidas. Eso sí, tiene un pequeño coste: la instalación de las apps tarda un poco más y ocupan más espacio de almacenamiento que con Dalvik.
Comparativa técnica y mejoras clave
Aunque ambos entornos son compatibles y ejecutan el mismo código de bytes DEX, ART ha traído mejoras que hacen que el sistema vuele. Una de las más importantes es la recolección de basura (GC). En Dalvik, el recolector de basura solía causar esas molestas pausas o \»tirones\» en la interfaz (el famoso lag). ART ha rediseñado esto con un sistema principalmente concurrente, haciendo que las pausas sean independientes del tamaño de la memoria utilizada.
- Depuración avanzada: ART permite a los desarrolladores ver qué bloqueos mantienen los hilos y rastrear instancias de clases con mucha más precisión.
- Diagnósticos precisos: Ahora, cuando una app falla, los informes de errores son mucho más detallados, especialmente en casos de NullPointerException.
- Gestión de memoria: A diferencia de Dalvik, que usaba una caché no paginable, ART utiliza memoria RAM que se puede paginar, optimizando el uso del hardware.
El proceso de empaquetado: Del código al APK
Para que cualquier de estos entornos funcione, el código debe pasar por una cadena de montaje. Primero, el compilador de Java crea archivos .class, que luego la herramienta dex convierte en un único archivo classes.dex. Este archivo es el corazón del APK y es el que ART o Dalvik procesarán.
Existen herramientas como aapt para empaquetar recursos y zipalign para optimizar la alineación de datos, asegurando que el procesador acceda a la memoria de la forma más eficiente posible. Una vez que el APK llega al dispositivo, es donde ocurre la magia: si hay ART, se genera el archivo ELF; si hay Dalvik, se empieza a generar el archivo ODEX sobre la marcha.
Curiosidades sobre ROMs y el proceso de Deodex
En el mundo de las ROMs personalizadas, es común escuchar los términos odexar y deodexar. Como el archivo ODEX es dependiente del hardware y del sistema exacto donde se creó, no se puede mover de un móvil a otro fácilmente. Para poder modificar una app sin que el sistema pete, los desarrolladores realizan un proceso de deodexación, que consiste en integrar el archivo optimizado dentro del APK para facilitar su manipulación.
El ecosistema Android ha evolucionado desde una máquina virtual flexible pero costosa en energía hasta un entorno de ejecución optimizado que prioriza la experiencia del usuario. Mientras que Dalvik apostaba por la versatilidad de traducir el código en tiempo real, ART ha logrado que el hardware se aproveche al máximo mediante la compilación previa, garantizando que el software sea más estable, rápido y eficiente en el consumo eléctrico.