Dalvik es una máquina virtual de procesos (VM) discontinuada en el sistema operativo Android que ejecuta aplicaciones escritas para Android. [1] (El formato de código de bytes Dalvik todavía se usa como formato de distribución, pero ya no en tiempo de ejecución en las versiones más nuevas de Android). Dalvik era una parte integral de la pila de software de Android en las versiones de Android 4.4 "KitKat" y anteriores (ahora sin soporte), que se usaban comúnmente en dispositivos móviles como teléfonos móviles y tabletas , y más en algunos dispositivos como televisores inteligentes y wearables . Dalvik es un software de código abierto , originalmente escrito por Dan Bornstein, quien lo nombró en honor al pueblo pesquero de Dalvík en Eyjafjörður , Islandia . [2] [3]
Los programas para Android se escriben comúnmente en Java y se compilan en código de bytes para la máquina virtual de Java , que luego se traduce a código de bytes Dalvik y se almacena en archivos .dex( Dalvik EXecutable ) y .odex( Optimized Dalvik EXecutable ); los términos relacionados odex y de-odex están asociados con las respectivas conversiones de código de bytes. El formato compacto Dalvik Executable está diseñado para sistemas que están limitados en términos de memoria y velocidad del procesador .
El sucesor de Dalvik es Android Runtime (ART), que utiliza el mismo código de bytes y archivos .dex (pero no archivos .odex), con el objetivo de mejorar el rendimiento. El nuevo entorno de ejecución se incluyó por primera vez en Android 4.4 "KitKat" como una vista previa de la tecnología , [4] [5] y reemplazó a Dalvik por completo en versiones posteriores; Android 5.0 "Lollipop" es la primera versión en la que ART es el único entorno de ejecución incluido.
Dalvik, llamado así por una ciudad de Islandia por su creador Dan Bornstein, [6] fue diseñado para dispositivos integrados con muy poca RAM y CPU [7] para ejecutar código Java, y eventualmente soportar C++ para "aplicaciones de alto rendimiento" y JavaScript para "aplicaciones livianas tipo widget" como lenguajes de primera clase con Java para el resto. Android Native Development Kit que eventualmente allanó el camino para el soporte de C++ ha existido desde el primer lanzamiento público de Dalvik. Según Bornstein, la asignación de archivos ejecutables y bibliotecas en memoria a través de múltiples procesos y la construcción de un intérprete más rápido con semántica basada en registros impulsaron gran parte del diseño inicial del conjunto de instrucciones alineadas por bytes y la máquina virtual. La experiencia trabajando con J2ME en Sidekick en Danger , Bornstein descubrió que era demasiado simple y bastante restringido para Android. Mientras que las mejoras como Isolates, tal como las planeó Sun en ese momento, hicieron que el aislamiento de procesos fuera inviable ya que rompía el modelo de seguridad intradispositivo de Android. Para Dalvik VM, Bornstein se inspiró particularmente en The Case for Register Machines [6] escrito por Brian Davis et al de Trinity College , Dublín. [8]
Dalvik se convirtió en código abierto bajo la licencia Apache v2 como el resto del Proyecto de código abierto Android en 2008. [9]
A diferencia de las máquinas virtuales Java , que son máquinas de pila , la máquina virtual Dalvik utiliza una arquitectura basada en registros que requiere menos instrucciones de máquina virtual, normalmente más complejas. Los programas Dalvik se escriben en Java utilizando la interfaz de programación de aplicaciones (API) de Android , se compilan en código de bytes Java y se convierten en instrucciones Dalvik según sea necesario.
dxSe utiliza una herramienta llamada para convertir archivos .class de Java al formato .dex. Se incluyen varias clases en un único archivo .dex. Las cadenas duplicadas y otras constantes utilizadas en varios archivos de clase se incluyen solo una vez en la salida .dex para ahorrar espacio. El bytecode de Java también se convierte en un conjunto de instrucciones alternativo utilizado por la máquina virtual Dalvik. Un archivo .dex sin comprimir suele ser un poco más pequeño que un archivo comprimido de Java (JAR) derivado de los mismos archivos .class. [10]
Los ejecutables de Dalvik pueden modificarse nuevamente cuando se instalan en un dispositivo móvil. Para lograr más optimizaciones , se puede intercambiar el orden de bytes en ciertos datos, se pueden vincular en línea estructuras de datos simples y bibliotecas de funciones , y se pueden cortocircuitar objetos de clase vacíos, por ejemplo.
Al estar optimizado para requisitos de memoria bajos, Dalvik tiene algunas características específicas que lo diferencian de otras máquinas virtuales estándar: [11]
Según Google, el diseño de Dalvik permite que un dispositivo ejecute múltiples instancias de la máquina virtual de manera eficiente. [12]
Android 2.2 "Froyo" incorporó la compilación Just-in-Time (JIT) basada en trazas a Dalvik, optimizando la ejecución de aplicaciones mediante la creación de perfiles de aplicaciones cada vez que se ejecutan y compilando dinámicamente segmentos cortos de su código de bytes que se ejecutan con frecuencia en código de máquina nativo . Si bien Dalvik interpreta el resto del código de bytes de la aplicación, la ejecución nativa de esos segmentos cortos de código de bytes, llamados "trazas", proporciona mejoras significativas en el rendimiento. [13] [14] [15]
Los méritos relativos de las máquinas de pila frente a los enfoques basados en registros son un tema de debate constante. [16]
En general, las máquinas basadas en pila deben usar instrucciones para cargar datos en la pila y manipularlos y, por lo tanto, requieren más instrucciones que las máquinas de registro para implementar el mismo código de alto nivel , pero las instrucciones en una máquina de registro deben codificar los registros de origen y destino y, por lo tanto, tienden a ser más grandes. Esta diferencia es importante para los intérpretes de VM, para los cuales el envío de códigos de operación tiende a ser costoso, junto con otros factores igualmente relevantes para la compilación justo a tiempo .
Las pruebas realizadas en dispositivos ARMv7 en 2010 por Oracle (propietario de la tecnología Java) con benchmarks Java estándar no gráficos mostraron que la VM HotSpot de Java SE integrado era 2-3 veces más rápida que la VM Dalvik basada en JIT de Android 2.2 (la versión inicial de Android que incluía un compilador JIT). [17] En 2012, los benchmarks académicos confirmaron el factor de 3 entre HotSpot y Dalvik en la misma placa Android, y también señalaron que el código Dalvik no era más pequeño que Hotspot. [18]
Además, a marzo de 2014 [actualizar], las pruebas comparativas realizadas en un dispositivo Android todavía muestran una diferencia de hasta 100 veces entre las aplicaciones nativas y una aplicación Dalvik en el mismo dispositivo Android. [19] [ ¿ Investigación original? ] [ ¿ Síntesis incorrecta? ] Al ejecutar pruebas comparativas utilizando el primer intérprete de 2009, tanto la Interfaz nativa de Java (JNI) como el código nativo mostraron una aceleración de un orden de magnitud. [20]
Dalvik se publica bajo los términos de la Licencia Apache 2.0. [21] Algunos [¿ quiénes? ] dicen que Dalvik es una implementación de sala limpia en lugar de un desarrollo sobre un entorno de ejecución Java estándar, lo que significaría que no hereda las restricciones de licencia basadas en derechos de autor ni de los entornos de ejecución Java de edición estándar ni de edición de código abierto. [22] Oracle y algunos revisores lo disputan. [23]
El 12 de agosto de 2010, Oracle , que adquirió Sun Microsystems en abril de 2009 y por lo tanto posee los derechos de Java, demandó a Google por supuesta infracción de derechos de autor y patentes. Oracle alegó que Google, al desarrollar Android, infringió a sabiendas, directa y repetidamente la propiedad intelectual relacionada con Java de Oracle. [24] [25] [26] En mayo de 2012, el jurado de este caso determinó que Google no infringió las patentes de Oracle, y el juez de primera instancia dictaminó que la estructura de las API de Java utilizadas por Google no era susceptible de derechos de autor. [27] [28] Las partes acordaron cero dólares en daños legales por 9 líneas de código copiado. [29] [30]
El entorno de ejecución Dalvik ya no se mantiene ni está disponible [en las versiones actuales de Android] y ART ahora utiliza su formato de código de bytes.
Los resultados muestran que, si bien el nuevo JIT de Android es una mejora con respecto a su implementación solo con intérprete, Android aún está por detrás del rendimiento de nuestro Java SE Embedded habilitado para Hotspot. Como puede ver en los resultados anteriores, Java SE Embedded puede ejecutar códigos de bytes de Java de 2 a 3 veces más rápido que Android 2.2.
Sin embargo, en el modo JITC, Dakvik es más de 2,9 veces más lento que HotSpot y el tamaño de su código generado no es menor que el de HotSpot debido a su peor calidad de código y código de encadenamiento de seguimiento.
Los resultados muestran que las aplicaciones nativas de C pueden ser hasta 30 veces más rápidas que un algoritmo idéntico que se ejecuta en Dalvik VM. Las aplicaciones Java pueden alcanzar una velocidad hasta 10 veces mayor si se utiliza JNI.
La definición de una implementación de "sala limpia" es que los ingenieros que escriben el código no tienen exposición directa al material original protegido por derechos de autor, incluido el código, las especificaciones y otra documentación. Eso es un problema para Google, como señalé en la publicación de ayer, porque hay evidencia sustancial de que los ingenieros que trabajaban en el proyecto tenían acceso directo al material protegido por derechos de autor.
Una parte importante de las afirmaciones de Oracle se basan en 9 líneas de código contenidas en Java.Util.Arrays.rangeCheck(). Este es el código en cuestión:...
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}