Diferencias
con una máquina virtual Java normal
En primer lugar, la máquina virtual de Dalvik (Android) toma los archivos generados por las clases Java y los combina en uno o más archivos ejecutables Dalvik (. dex), los cuales a su vez son comprimidos en un sólo fichero .apk (Android Package) en el dispositivo. De esta forma, reutiliza la información duplicada por múltiples archivos .class, reduciendo así la necesidad de espacio (sin comprimir) a la mitad de lo que ocuparía un archivo .jar.
En segundo lugar, Google ha mejorado la recolección de basura en la máquina virtual de Dalvik, pero ha preferido omitir just-in-time (JIT), en esta versión por lo menos. La empresa justifica esta elección diciendo que muchas de las bibliotecas centrales de Android, incluyendo las bibliotecas de gráficos, están implementadas en C y C++. Del mismo modo, Android proporciona una biblioteca de C optimizada para acceder a la base de datos SQLite, pero esta biblioteca está encapsulada en un nivel superior del API de Java. Dado que la mayoría del código del núcleo se encuentra en C y C++, Google argumentó que el impacto de la compilación JIT no sería significativo.
Por último, la máquina virtual de Dalvik utiliza un tipo diferente de montaje para la generación del código, en el que se utilizan los registros como las unidades primarias de almacenamiento de datos en lugar de la pila. Hay que señalar que el código ejecutable final de Android, como resultado de la máquina virtual de Dalvik, no se basa en el bytecode de Java, sino que se basa en los archivos .dex. Esto significa que no se puede ejecutar directamente el Bytecode de Java, sino que hay que comenzar con los archivos .class de Java y luego convertirlos en archivos .dex.
Formato
de un fichero .dex
Tras comenzar a
estudiar las características de Android, pueden observarse algunos aspectos
que, si bien no siempre resultan una ventaja frente a sus competidores, sí son
interesantes y pueden repercutir positivamente en su elección como plataforma. Por
ejemplo:
Diferencias
de arquitectura y Librerias
A
pesar de que Google evita usar el término demasiado, el hecho de utilizar un
lenguaje tan popular como Java ayuda a que cualquier programador
mínimamente experimentado pueda comenzar a programar sus aplicaciones sin mayor
complicación, además de animar a los que ya estén muy familiarizados.
Incluye, además, las API más importantes de este lenguaje como java.util, java.io o java.net.
Como
ya es sabido, Android divide todas sus aplicaciones en componentes o
bloques básicos que, combinados, constituyen el programa final. Así,
tenemos bloques visibles para el usuario mediante interfaces (Activity),
bloques que se ejecutan en background fuera de su conocimiento (Service), bloques
a la escucha de determinados eventos (Broadcast Receiver) y bloques que ofrecen
contenidos a otras aplicaciones (Content Providers). Esta filosofía
es original y ayuda a modularizar funcionalmente las aplicaciones.
·
La
delegación de acciones en otras aplicaciones mediante Intents es otro
de los aspectos más innovadores ofrecidos por Android. Mediante un Intent,
la aplicación simplemente expresa lo que desea hacer y es el sistema el
encargado de buscar la aplicación más adecuada (para llamar, mandar un correo
electrónico, abrir una página web, etc.). Así mismo, las aplicaciones pueden
anunciar a las demás que están preparadas para poder atender determinados tipos
de Intents.
·
La construcción
de interfaces de usuario ha sido un aspecto muy cuidado, no sólo por la
amplia colección de elementos y diseños incorporados, sino por la posibilidad
de ser definidas tanto en el código fuente como mediante documentos XML
externos.
·
El
acceso a los recursos del dispositivo, como GPS, Wi-Fi, etc., se convierte
en una tarea fácil y simple gracias a las API del SDK.
·
La
declaración y uso de recursos externos, tales como imágenes, cadenas de
texto, valores numéricos, o incluso diferentes modelos de interfaz de usuario y
de diseños es cómoda y fácil de realizar.
En cuanto a las librerías estas son algunas diferencias:
·
APIS que controlan el ciclo
de vida de la aplicación.
·
ANDROID: Principalmente se usan android.app.Activity y android.app.ListActivity.
·
JAVA: Principalmente se
usa javax.microedition.midlet.MIDLET.
·
APIS que definen la
interfaz de usuario de la aplicación.
Alto Nivel
·
ANDROID: Principalmente se usan android.widget.ArrayAdapter y android.widget.ListAdapter
·
JAVA: Esencialmente
son javax.microedition.lcdui.Display yjavax.microedition.lcdui.Displayable
Bajo Nivel
·
ANDROID: Principalmente
se usan android.graphics.drawable.Drawable y android.view.View
·
JAVA: Esencialmente
son javax.microedition.lcdui.game.GameCanvas y javax.microedition.lcdui.Displayable.Canvas
·
APIS media: Bluetooth,
Multimedia y sensores.
Bluetooth
·
ANDROID: Android
ofrece la siguiente librería para usar esta interfaz, android.bluetooth.
·
JAVA: CLDC
tiene un paquete opcional para usar Bluetooth (JSR 82): “Bluetooth API”.
Multimedia
·
ANDROID: Ofrece la siguiente
librería para reproducción de audio y vídeo, android.media: MediaPlayer.
·
JAVA: CLDC ofrece el
paquete opcional “MMAPI” y un soporte básico en la API de
MIDP 2.0: Manager, Playery Control en los paquetes javax.microedition.media y javax.microedition.media.control.
Sensores y acelerómetro
·
ANDROID:Android
proporciona la clase android.hardware.SensorManager, la cual sirve para manejar el sensor
de orientación, y el acelerómetro.
·
JAVA: CLDC tiene un paquete opcional para gestionar los sensores
conectados al móvil (JSR 256): “Mobile Sensor API”.
·
Descriptores.
·
ANDROID: AndroidManifest.xml
Los componentes que necesita la
aplicación se enumeran en un archivo llamado AndroidManifest.xml, el cual
es un fichero XML donde se declaran los componentes y cuáles son sus
capacidades y requerimientos.
·
JAVA: Descriptor JAD
Permite
describir las propiedades de la aplicación y los componentes que forman parte
de la misma. De esta manera, el AMS (Application Management System) podrá
verificar si es posible instalar la aplicación antes de descargarla. Es un
fichero de texto con extensión .jad.
Arquitectura: Ciclo de vida de la aplicación
·
ANDROID: En
Android existen 4 grandes bloques de construcción: Activity, Intent, Service y Content
Provider, de los cuales, el bloque Activity es el componente más
habitual de las aplicaciones para Android, es decir, un componente Activity refleja
una determinada actividad llevada a cabo por una aplicación, y que lleva
asociada típicamente una ventana o interfaz de usuario. Los cuatro
posibles estados que definen su ciclo de vida son: Activa, pausada, parada
y reiniciada.
·
JAVA: La
clase encargada del ciclo de vida de una aplicación, es la clase MIDlet, y
los métodos que gestionan el ciclo de vida de una aplicación son tres: activa,
pausada y destruida.
Máquina Virtuales: KVM y CVM (Java ME) vs. Dalvik (Android)
·
ANDROID:La
JVM que utiliza Android es la máquina virtual DalvikVM. En ella
podemos encontrar una gran diferencia con respecto a la máquina virtual Java
(JVM), ya que la máquina virtual de Google no está basada en una pila.
·
JAVA: En
el perfil MIDP, la JVM es la máquina virtual KVM, la cual es la
máquina virtual más pequeña desarrollada por Sun, y se usa con la configuración
CLDC. Se trata de una implementación reducida y especialmente orientada a
dispositivos con bajas capacidades computacionales y de memoria.
Herencia de interfaz ráfica de Java
·
ANDROID: Android
hereda las siguientes librerías de Java:
·
JAVA: El perfil MIDP,
hereda las siguientes librerías de Java:
· java.io.*
Clases y paquetes estándar de E/S. (Subconjunto de J2SE)
· java.lang.*
Clases e interfaces de la VM. (Subconjunto de J2SE)
· java.util.*
Clases, interfaces y utilidades estándar. (Subconjunto de J2SE)
Mensajería instantánea: SIP(Java ME) vs. XMPP(Android)
·
ANDROID: Android
ofrece una API para desarrollar protocolos de mensajería instantánea,
concretamente
XMPP (Extensible
Messaging and Presence Protocol), protocolo de intercambio de mensajes
basado en XML.
·
JAVA: Java ME con el perfil MIDP ofrece un paquete opcional para utilizar
protocolos de mensajería instantánea, concretamente SIP (Session Initition Protocol).
Almacenamiento de Datos: RMS(Java ME) vs. SQLite(Android)
·
ANDROID: Android ofrece la
superclase android.content.ContentProvider para el manejo y almacenamiento de
datos, conocido también como “proveedor de contenido”. Este bloque de
construcción, permite compartir datos entre procesos y aplicaciones.
Además,
Android soporta BBDD SQLite y proporciona funciones de control
que permiten almacenar datos complejos en forma de objeto.
·
JAVA: MIDP ofrece la
librería javax.microedition.rms para memoria persistente, lo cual
consiste en una base de datos binaria sencilla (sin usar SQL) orientada a
almacenes de registros (RecordStore).
Navegador (Java ME) vs. WebKit (Android)
·
ANDROID: El SO Android dispone de un navegador
integrado basado en el motor del proyecto abierto WebKit.
·
JAVA: CLDC ofrece la
posibilidad de desarrollar clientes web con “Web Services APIs”.
Portabilidad de Aplicaciones
·
ANDROID: En este ámbito,
Java ME tiene una enorme ventaja sobre Android, ya que tiene una VM “totalmente
Java”, mientras que la VMde Google (Dalvik), a pesar de sus grandes ventajas ya
comentadas, hace que la migración de una aplicación open-source de Linux x86 sea realmente dura. Todos los
interfaces de usuario y la lógica han de ser reescritos desde cero.
·
JAVA: La existencia de
diferentes perfiles en Java ME consiguen garantizar la portabilidad de las
aplicaciones, que utilizan un API no tan complejo y extenso como en el caso de
Android, pero suficiente para que el código sea portable entre diferentes
dispositivos móviles.
¿Puede ejecutarse un Proyecto Java ME en un móvil con ANDROID?
·
Claro
que si, usando MicroEmu (Emulador de J2ME hecho en Java) o bien con el J2ME MIDP Runner.
Diferencias
en aspectos de programación
·
ANDROID: Permite
desarrollar aplicaciones en los siguientes entornos de programación:
Eclipse
Netbeans
·
JAVA: Permite
desarrollar aplicaciones en los siguientes entornos de programación:
J2ME Wireless Toolkit 2.2
J2ME WTK 2.5
Java ME Platform SDK 3.0
Netbeans: Mobility Pack 4.1
Eclipse: Plug-in EclipseME
Midlet(Java ME) vs. Activity(Android)
·
ANDROID: En
Android una pantalla (asociada a una interfaz de usuario) se corresponde
con la
clase Activity,
y para pasar de una pantalla a otra se utiliza la clase Intent de
la
siguiente manera:
Intent
intentLista = new Intent(); intentLista.setClass(Clase1.this,Lista.class);//origen,destino
startActivity(intentList);//para pasar a la pantalla asociada a la clase Lista
·
JAVA: En
MIDP para pasar de una pantalla otra se utiliza la clase Display de la siguiente
manera:
this.midlet.getDisplay().setCurrent(this.midlet.getLista());
Donde
el método getLista() devuelve un objeto del tipo List de la API de alto nivel
Además, se usa
la clase Command para añadir un comando al Displayable y
poder cambiar
de una pantalla a
otra, utilizando el siguiente método:
addComand(Command)
Modelo de seguridad
·
ANDROID: En Android
se hace en el fichero AndroidManifest.xml.
Por ejemplo, si
queremos
acceder a la API de bajo nivel, ActivityManager, para obtener el número
de procesos en ejecución, debemos añadir la
siguiente línea al descriptor:
<uses-permission
id="android.permission.GET_TASKS" android:name="GET_TASKS"/>
·
JAVA: CLDC
sigue el modelo “sandbox” y MIDP 2.0 proporciona un
modelo de seguridad
a nivel de aplicaciónmediante firmas
digitales que permiten determinar si una aplicación es
fiable o
no asociada a un dominio de seguridad. Las políticas permiten especificar los
permisos asignados a cada dominio.
Gestión de eventos (escuchadores)
·
ANDROID: Principalmente
se usan android.view.View.OnClickListener
(para capturar el evento OnClick de cualquier elemento del Layout, por ejemplo un botón) y android.view.MenuItem.onMenuItemSelected (cuando
se usa la tecla Menú
para interactuar con el usuario, para capturar el
evento OnClick de una de las
opciones del menú).
·
JAVA: Sigue el
modelo de manejo de eventos y escuchadores definidos en Java SE,
así tenemos fuentes de eventos que mantiene
escuchadores que están interesados en saber cuándo ocurre un evento y
proporciona métodos que permite que los escuchadores se añadan a dicha lista.
Así cuando la fuente genera un evento, se lo notifica al escuchador
correspondiente para que procese el evento, ejecutando la acción programada.
Además, con la API de bajo nivel se pueden programas eventos del teclado y
puntero. Por ejemplo, en la clase javax.microedition.lcdui.game.GameCanvas se gestionan los eventos de
teclado por polling utilizando el método getKeyStates().
Propiedades del sistema
·
ANDROID: Las
propiedades del sistema se definen en el fichero AndroidManifest.xml, el cual
describe la aplicación, los permisos necesarios, etc… Todos los proyectos Android
tienen este archivo que, entre otras cosas, nos dará la posibilidad depedir
los permisos que vayamos necesitando, y
definirá la actividad inicial que se ejecutará.
·
JAVA: Las
propiedades del sistema se definen en el fichero descriptor de la aplicación
(JAD) y se obtienen viajava.lang.System y javax.microedition.MIDlet, por
ejemplo:
System.getproperty(String
key)
Uso de
memoria
·
ANDROID: En
este aspecto Android es el ganador ya que los terminales Android no imponen restricciones de memoria, debido
a que cada aplicación Android corre su propio proceso, con su propia
instancia de la VM Dalvik. Dalvik permite el uso eficiente de dichas instancias.
Ejecuta ficheros en el formato .dex optimizado para el consumo
mínimo de memoria.
·
JAVA: Los
sistemas J2ME tienen restricciones importantes de memoria para el almacenamiento y
ejecución de aplicaciones, restricciones por debajo de 50K.
Uso de hilos (contextos)
·
ANDROID: Ofrece el paquete java.util.concurrent, heredado de java, y android.os para mecanismos de
sincronización de procesos, tareas, hilos y actividades.
·
La principal diferencia entre las dos tecnologías es que Android ofrece
un “entorno
multitarea”, es decir, cada aplicaciónde Android corre en su propio proceso, el cual es
creado por la aplicación cuando se ejecuta y permanece hasta que la
aplicación deja de trabajar o el sistema necesita memoria para otras
aplicaciones. Una característica fundamental de Android es que el ciclo de
vida de una aplicación no está controlado por la misma aplicación sino
que lo determina el sistema a partir de una combinación de estados como pueden ser que aplicaciones
están funcionando, que prioridad tienen para el usuario y cuanta memoria
queda disponible en el sistema. De esta manera, Android sitúa cada
proceso en una jerarquía de "importancia", concretamente sigue el
estándar POSIX, de modo que la política de
eliminación de procesos esTRANSPARENTE para el programador, ya que la
capa inferior de la plataforma está compuesta por un núcleo Linux (versión
2.6) que se usa como capa de abstracción de hardware
(HAL, Hardware Abstraction Layer). Si el programador desea ver los
procesos en ejecución a bajo nivel, la única posibilidad es usar la
herramienta AIDL, la cual ofrece al programador
la visualización de las llamadas del SO a los métodos IPC.
·
JAVA: Java ME, al
igual que Android ofrece un entorno “multithreaded”, ya que permite realizar
múltiples actividades simultáneamente, pero se diferencia en que el Planificador de hilos (el cambio de contexto) no lo
puede controlar el programador sino que puede suceder en cualquier momento.
Aún así, existen “trucos” para que el programador sea capaz de gestionar
varios hilos dentro de una misma aplicación.
Finalmente el proyecto de como seria un HELLO WORD en las dos tecnologias: Android: Java: |
