En los entornos Java estándar, el código fuente de Java es compilado en bytecode de Java, y almacenado en archivos .class. Los archivos .class son leídos por la máquina virtual Java en tiempo de ejecución. Cada clase en tu código Java se traducirá en un archivo .class. Esto significa que si tienes, por ejemplo, un archivo .java (código fuente) que contiene una clase pública, una clase interna estática, y tres clases anónimas, el proceso de compilación (javac) nos generará 5 archivos .class.
En la plataforma Android, el código fuente de Java también se compila en archivos .class. Pero después de generar los archivos .class, mediante la herramienta “dx“ son convertidos a un único archivo dex (Dalvik Executable). Mientras que un archivo .class contiene una sola clase, un archivo .dex contiene múltiples clases. Es el archivo .dex el que se ejecuta en la máquina virtual Dalvik.
El archivo .dex ha sido optimizado para el mínimo consumo de memoria y el diseño esta condicionado por la reutilización de datos. El siguiente diagrama compara el formato de los archivos .class utilizado por la JVM con el formato de .dex utilizado por la máquina virtual Dalvik.

A grandes rasgos las estructura de un Archivo .dex consta de las siguientes partes:
- Cabecera
- Tabla con las posiciones de los Strings
- Tabla con las posiciones de los Tipos
- Tabla con las posiciones de las estructuras/Prototipos de los métodos
- Tabla con las posiciones de las Propiedades de las clases o Campos de los métodos
- Tabla con las posiciones de los Métodos
- Tabla con las posiciones de las Clases
- Datos

Salvo la tabla de Strings (que es a la que hacen referencia todas las tablas ya que es en esta parte donde se almacenan todos los nombre de clases, métodos, funciones, variable y tipos de datos), el resto sigue un orden jerárquico inverso, es decir, si quisiéramos desensamblar el archivos dex, tras obtener el listado de Strings, obtendríamos el listado de Clases, sus métodos, sus propiedades y campos de los métodos, la estructura de dichos métodos – que relaciona métodos y campos – y por ultimo los tipos, que nos indicaría los tipos de los campos de los métodos y los tipos que devuelven los métodos. Es decir, es una estructura relacional, que tiene como objetivo el reaprovechamiento máximo de la información, evitando redundancias y así conseguir un formato optimo para terminales móviles.
Como he indicado, son tablas donde se indica la posición donde esta la información que compone dicha tabla, normalmente mediante un Offset y opcionalmente una longitud. Estos datos junto con el código maquina están en la sección de datos.

En próximos artículos iremos desgranando con mas detalle, cada parte de la estructura del formato Dalvik Executable.
Fuente 1:http://davidehringer.com/software/android/The_Dalvik_Virtual_Machine.pdf
Fuente 2:http://www.scribd.com/doc/17194679/DalvikVMInternals#
3 Responses to Archivos DEX (Dalvik Executable): Introducción
Sergio Ciruela febrero 20, 2011
Hola Iker, me parece muy interesante lo que cuentas. Yo estoy intentando realizar un aplicación que genere ficheros Dex en tiempo de ejecución para posteriormente cargarlos en tiempo de ejecución, creo que he hecho grandes avances y lo puedes comprobar en: http://code.google.com/p/android/issues/detail?id=6322
o
http://stackoverflow.com/questions/4836847/triying-to-generate-dex-bytecode-at-runtime
Podría ser interesante que le echaras un vistazo ya que te veo puesto en el tema.
Simplemente el mecanismo es la invocación directa de la librería DX tool y con ello se pretende generar un fichero en una sdcard que pueda generar bytecode y cargarlo dinamicamente.
Saludos
Iker febrero 20, 2011
suena muy interesante… pero solo se me ocurren cosas malas que hacer… XDD
Sergio Ciruela febrero 22, 2011
@Iker
Imaginate la utilidad para servicios web en entornos dinámicos
Te apuntas?