Este artículo compara las interfaces de programación de aplicaciones (API) y las máquinas virtuales (VM) del lenguaje de programación Java y el sistema operativo Android.
Si bien la mayoría de las aplicaciones de Android están escritas en un lenguaje similar a Java, existen algunas diferencias entre la API de Java y la API de Android, y Android no ejecuta el código de bytes de Java por una máquina virtual Java (JVM) tradicional, sino por una máquina virtual Dalvik en versiones anteriores de Android y Android Runtime (ART) en versiones más nuevas, que compilan el mismo código que Dalvik ejecuta en ejecutables de formato ejecutable y enlazable (ELF) que contienen código de máquina.
El código de bytes de Java en archivos Java Archive (JAR) no es ejecutado por dispositivos Android. En cambio, las clases Java se compilan en un formato de código de bytes patentado y se ejecutan en Dalvik (o una versión compilada de las mismas con ART más reciente), una máquina virtual especializada (VM) diseñada para Android. A diferencia de las máquinas virtuales Java, que son máquinas de pila (arquitectura basada en pila), la máquina virtual Dalvik es una máquina de registro (arquitectura basada en registro).
Dalvik tiene algunos rasgos que lo diferencian de otras máquinas virtuales estándar: [1]
La VM fue diseñada para usar menos espacio.
El grupo constante se ha modificado para usar solo índices de 32 bits para simplificar el intérprete.
El código de bytes estándar de Java ejecuta instrucciones de pila de 8 bits. Las variables locales deben copiarse ao desde la pila de operandos mediante instrucciones separadas. En cambio, Dalvik usa su propio conjunto de instrucciones de 16 bits que funciona directamente en variables locales. La variable local es comúnmente elegida por un campo de registro virtual de 4 bits.
Debido a que el código de bytes cargado por la máquina virtual Dalvik no es código de bytes Java y debido a la forma en que Dalvik carga las clases, es imposible cargar paquetes de biblioteca como archivos JJAR. Se debe usar un procedimiento diferente para cargar las bibliotecas de Android, en el que el contenido del archivo dex subyacente se debe copiar en el área de almacenamiento interno privado de la aplicación antes de cargarlo. [2]
Como es el caso del sistema de clase Java SE, la clase de sistema Android permite recuperar las propiedades del sistema. Sin embargo, algunas propiedades obligatorias definidas con la máquina virtual Java no tienen significado o tienen un significado diferente en Android. Por ejemplo:
La propiedad .version de Java devuelve 0 porque no se usa en Android.
Java .specification.version invariablemente devuelve 0.9 independientemente de la versión de Android utilizada.
Java .class.version invariablemente devuelve 50 independientemente de la versión de Android utilizada.
user.dir tiene un significado diferente en Android.
user.home y las propiedades no existen en Android.
Biblioteca de clases [editar]
Las versiones actuales de Android usan el último lenguaje Java y sus bibliotecas (pero no marcos de interfaz gráfica de usuario (GUI) completos), no la implementación Apache Harmony Java, que usaban las versiones anteriores. El código fuente de Java 8 que funciona en la última versión de Android, puede funcionar en versiones anteriores de Android.
Paquete Java.lang [editar]
Por defecto, el flujo de salida predeterminado System.out y System.err no genera nada, [3] y se alienta a los desarrolladores a usar la clase Log, que registra las cadenas en la herramienta LogCat. [4] Esto ha cambiado al menos desde HoneyComb, y ahora también salen a la consola de registro.
Gráficos y biblioteca de widgets [editar]
Android no utiliza el kit de herramientas de la ventana abstracta ni la biblioteca Swing. Las interfaces de usuario se crean utilizando objetos View. Android usa un marco similar a Swing, basado en Vistas en lugar de JComponents. Sin embargo, los widgets de Android no son JavaBeans: el contexto de la aplicación de Android se debe proporcionar al widget en la creación.
Mirar y sentir [editar]
La biblioteca de widgets de Android no admite una arquitectura de aspecto y conexión conectables. La apariencia de los widgets de Android debe estar integrada en los widgets. Sin embargo, existe una capacidad limitada para establecer estilos y temas para una aplicación. [5]
Administrador de diseño [editar]
A diferencia de Swing, donde los administradores de diseño se pueden aplicar a cualquier widget de contenedor, el comportamiento del diseño de Android está codificado en los contenedores. [6]
Paquete Java.beans [editar]
Android incluye solo un pequeño subconjunto del paquete java.beans (PropertyChangeEvent y clases relacionadas).
Ver también [editar]
Android (sistema operativo)
Java (lenguaje de programación)
