Historia del Desarrollo del Sistema Operatico Android
Hace unos años, con el desarrollo de Android por parte Google, se tomaron varias decisiones con respecto a Java. La primera de ellas consistía en utilizarlo como lenguaje de desarrollo de aplicaciones, debido a la gran portabilidad que simboliza el lenguaje de Sun Microsystems y Oracle. Sin embargo, una segunda decisión consistió en apartar el uso de Java Micro Edition, tecnología destinada a ejecutar aplicaciones en dispositivos móviles y sistemas integrados; así como de la Java Virtual Machine.
En detrimento de estas, Google decidió utilizar una máquina virtual propia: Dalvik VM, acompañada de una implementación alternativa de las librerías de Java. Así pues, se optó por una serie de decisiones que condujeron al uso de un Java no estándar.
De esta forma, Dalvik Vm utiliza un byte-code propio, por lo que ejecutar un código nativo de Java directamente en la máquina virtual. Es decir, la máquina Dalvik utiliza un formato propio llamado Dalvik Executable (DEX) y, por tanto, empaquetado en archivos .dex; mientras que el estándar Java utiliza archivos .class.
Los archivos .dex, de forma más concreta, se utilizan para inicializar y ejecutar aplicaciones desarrolladas para Android, siendo uno los tipos de archivo que se contienen en los paquetes de aplicaciones Android (APK). Una de las peculiaridades de estos archivos Dalvik es su organización de las constantes. Cuando varios archivos de java (.class) se quieren convertir en archivos Dalvik, una herramienta se encarga de convertir y reagrupar los archivos de clase en un único archivo Dex con varios grupos de constantes. Esta reagrupación se utiliza para reducir los argumentos duplicados y compactar el tamaño del archivo.
Sin embargo, el desarrollo de un formato de archivo único podía presentar varias complicaciones de cara al desarrollo de aplicaciones para el sistema Android. Para salvar estas complicaciones, se han facilitado mecanismos conversores entre el archivo de clase de java y los archivos ejecutables de Dalvik, por ejemplo, la herramienta “dx” Tool incluida en el kit de desarrollo software de Android.
Google puso un esfuerzo especial en conseguir que la implementación de la máquina virtual Dalvik estuviese muy optimizado, para conseguir que fuese tan eficiente y efectivo como fuera posible en dispositivos con recursos muy limitados como los que presentaban los primeros dispositivos que incorporaron el sistema operativo. Esto es, aspectos como una CPU con un único núcleo, módulos muy reducidos de memoria principal o su reducida capacidad de batería.
La máquina Dalvik fue, por tanto, implementada de manera que fuese posible lanzar varias ejecuciones simultáneas de una manera sumamente eficiente. Además, debido a las características de la arquitectura Android, se diseñó Dalvik VM de tal forma que pudiese confiar en el núcleo modificado de Linux las tareas de threading y administración de memoria en niveles bajos.
A día de hoy, sin embargo, y desde la implementación de la versión 5.0 de Android, o como se conoce comúnmente: Android Lollipop, en el año 2014, Dalvik dejó de ser usado, en favor de ART (Android Runtime), un entorno de ejecución que se encarga de llevar a cabo la conversión de una aplicación específica en instrucciones máquina, que posteriormente ejecuta el entorno de ejecución nativo del dispositivo; e introduce significativas mejoras frente a su predecesor.
Como dato adicional, y a modo de curiosidad, la máquina Dalvik recibe su nombre de un pueblo islandés.
