Dalvik es una máquina virtual (VM) de proceso descontinuada en el sistema operativo Android que ejecuta aplicaciones escritas para Android. [1] (El formato de código de bytes de 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 (ahora no compatibles) de Android 4.4 "KitKat" y anteriores. , 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 dispositivos portátiles . Dalvik es un software de código abierto , escrito originalmente por Dan Bornstein, quien le puso el nombre del pueblo pesquero de Dalvík en Eyjafjörður , Islandia . [2] [3]
Los programas para Android comúnmente se escriben en Java y se compilan en código de bytes para la máquina virtual Java , que luego se traduce al código de bytes de 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ódigos 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), y la sucesión apunta a mejoras de 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 tiempo de ejecución incluido.
Dalvik, que su creador Dan Bronstein lleva el nombre de una ciudad de Islandia, [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 pesadas" y JavaScript para "aplicaciones livianas tipo widget" como lenguajes de primera clase y Java se ocupa del resto. El kit de desarrollo nativo de Android , que finalmente allanó el camino para la compatibilidad con C++, existe desde el primer lanzamiento público de Dalvik. Según Bronstein, los ejecutables y bibliotecas de mapeo de 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. Al tener experiencia trabajando con J2ME en Sidekick at Danger , Bronstein descubrió que era demasiado simple y bastante limitado para Android. Si bien las mejoras como Isolates , tal como planeó Sun en ese momento, hicieron que el aislamiento de procesos fuera inviable, ya que rompía el modelo de seguridad intra-dispositivo de Android. Para Dalvik VM, Bronstein se inspiró particularmente en The Case for Register Machines [6] escrito por Brian Davis et al del Trinity College , Dublín. [8]
Dalvik fue de código abierto bajo la licencia Apache v2 como el resto del Proyecto de código abierto de Android en 2008. [9]
A diferencia de las máquinas virtuales Java , que son máquinas de pila , Dalvik VM utiliza una arquitectura basada en registros que requiere menos instrucciones de máquina virtual, generalmente más complejas. Los programas de Dalvik se escriben en Java utilizando la interfaz de programación de aplicaciones (API) de Android, se compilan en código de bytes de Java y se convierten a instrucciones de Dalvik según sea necesario.
dxSe utiliza una herramienta llamada para convertir archivos Java .class 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 código de bytes de Java también se convierte en un conjunto de instrucciones alternativo utilizado por Dalvik VM. Un archivo .dex sin comprimir suele tener un tamaño un porcentaje menor que un archivo Java comprimido (JAR) derivado de los mismos archivos .class. [10]
Los ejecutables de Dalvik pueden modificarse nuevamente cuando se instalan en un dispositivo móvil. Para obtener mayores optimizaciones , se puede intercambiar el orden de los bytes en determinados datos, se pueden vincular en línea estructuras de datos simples y bibliotecas de funciones y, por ejemplo, se pueden cortocircuitar objetos de clase vacíos.
Al estar optimizada para requisitos de memoria bajos, Dalvik tiene algunas características específicas que la 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 VM de manera eficiente. [12]
Android 2.2 "Froyo" trajo la compilación justo a tiempo (JIT) basada en trazas a Dalvik, optimizando la ejecución de aplicaciones perfilando continuamente las aplicaciones cada vez que se ejecutan y compilando dinámicamente segmentos cortos de su código de bytes ejecutados con frecuencia en código de máquina nativo . Mientras 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 "rastros", proporciona mejoras significativas en el rendimiento. [13] [14] [15]
Las ventajas relativas de las máquinas apilables versus los enfoques basados en registros son un tema de debate continuo. [dieciséis]
Generalmente, las máquinas basadas en pila deben usar instrucciones para cargar datos en la pila y manipular esos datos 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 el código fuente. y registros de destino y, por tanto, tienden a ser mayores. Esta diferencia es importante para los intérpretes de VM, para quienes 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 puntos de referencia Java no gráficos estándar mostraron que la VM HotSpot de Java SE integrada era de 2 a 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 puntos de referencia académicos confirmaron el factor de 3 entre HotSpot y Dalvik en la misma placa de Android, y también señalaron que el código de Dalvik no era más pequeño que Hotspot. [18]
Además, a partir de marzo de 2014 [actualizar], las pruebas comparativas realizadas en un dispositivo Android todavía muestran un factor de 100 entre las aplicaciones nativas y una aplicación Dalvik en el mismo dispositivo Android. [19] [ ¿ investigación original? ] [ ¿ síntesis inadecuada? ] Al ejecutar pruebas comparativas utilizando el intérprete inicial 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én? ] dicen que Dalvik es una implementación de sala limpia en lugar de un desarrollo sobre un tiempo de ejecución de Java estándar, lo que significaría que no hereda restricciones de licencia basadas en derechos de autor ni de los tiempos de ejecución de Java de edición estándar ni de código abierto. [22] Oracle y algunos críticos cuestionan esto. [23]
El 12 de agosto de 2010, Oracle , que adquirió Sun Microsystems en abril de 2009 y, por 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ó consciente, directa y repetidamente la propiedad intelectual de Oracle relacionada con Java. [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 estaba protegida por derechos de autor. [27] [28] Las partes acordaron cero dólares en concepto de daños y perjuicios por 9 líneas de código copiado. [29] [30]
El tiempo de ejecución de 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, aunque el nuevo JIT de Android es una mejora con respecto a su implementación de solo intérprete, Android todavía 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 lento que HotSpot en más de 2,9 veces 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 C nativas pueden ser hasta 30 veces más rápidas que un algoritmo idéntico que se ejecuta en Dalvik VM. Las aplicaciones Java pueden acelerarse hasta 10 veces si se utiliza JNI.
La definición de implementación de una "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 trabajaron en el proyecto tuvieron 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().
Aquí está el código en cuestión:...
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}