I. INTRODUCCIÓN

En computación, “Cross-Platform” se refiere al desarrollo de software o hardware que es compatible con

diferentes plataformas sin necesidad de hacer un desarrollo

específico para cada una de estas. Este trabajo se enfocará

en el Cross-Platform para desarrollo móvil en las dos

plataformas más importantes en la actualidad, es decir para

las plataformas Android y iOS. Se tomará como dispositivo

móvil a los smartphones y tablets.

En este trabajo se buscará explicar la arquitectura

de cada una de las principales plataformas para teléfonos

móviles (Android y iOS), cómo funciona el desarrollo nativo (compilación de aplicaciones o “apps”) y cómo

funcionan diferentes herramientas para desarrollo Cross-

Platform.

II. ARQUITECTURA DE MÓVILES

En la actualidad, todos los dispositivos móviles

utilizan la arquitectura ARM de 32 bits. Los procesadores ARM diseñados con tecnología RISC (Reduced Instruction

Set Computing), lo cual quiere decir que buscan la

optimización a la hora de llevar a cabo una instrucción. La

arquitectura ARM se hizo popular entre los dispositivos

móviles debido a su poco consumo de energía, factor

importante que puede afectar de gran manera la forma en

que se ejecuta el software en un dispositivo móvil ya que

esta es más limitada. (1)

A. Arquitectura ARM

El procesador ARM fue creado con el objetivo de

tener un procesador de alto rendimiento pero que

consumiera pocos recursos, la primera versión de este salió

en 1,983 por Acorn Proton y fue llamado ARM1. A finales

de los 80 Apple empezó a colaborar con esta empresa para

crear procesadores para la Apple Newton y luego de esto muchas empresas importantes en la industria empezaron a

interesarse en los procesadores ARM; en la actualidad son

varias las empresas que crean o en algún momento crearon

procesadores ARM, algunas de estas son: Sony, Samsung,

Panasonic, Apple e IBM. (2)

La importancia de los procesadores ARM en los

dispositivos móviles es debido a su poca cantidad de

transistores lo cual ofrece un consumo bajo de energía que

es uno de los recursos más limitados en los dispositivos

móviles. Además de su bajo consumo energético, los

procesadores ARM generan menos calor y por esta razón se

están haciendo más populares en otras áreas. (1)

La arquitectura ARM está basada en la arquitectura

RISC lo cual significa que incluye los beneficios de su

arquitectura base, hay tres principales que son de suma

importancia para el desarrollo en dispositivos móviles. La

primera es que las operaciones de cargar y guardar se

manejan por medio de registros y no por memoria. A esto

se suma que las direcciones de carga y almacenamiento

están limitadas a uso solamente para contenidos de los

registros y de instrucciones por lo tanto la generación de

direcciones es más simple. El código es corto. (2)

III. PLATAFORMAS MÓVILES

Una plataforma no es solamente el software sobre

el cual estará corriendo el programa a desarrollar, la

plataforma también incluye el hardware. Especialmente en

los móviles, es importante tomar en cuenta el manejo del

hardware debido a la gran variedad de dispositivos móviles que hay en el mercado. (3)

A. Android

Los dispositivos Android trabajan básicamente a partir de una pila de software la cual incluye el Sistema

Operativo, Middleware1 y aplicaciones clave para el manejo

del hardware. Esta pila está formada por 5 capas:

1) Aplicaciones

Estas son aplicaciones nativas que han sido escritas

en Java, incluyen cliente para correo electrónico,

mensajería SMS, calendario, mapas, navegador de internet,

contactos, entre otros.

1 Middleware: Es el software encargado de conectar una o varias aplicaciones con otro software y/o hardware.

Cross-Platform en Móviles

Ana Silvia Gonzáles Torres, 10194, Ingeniería en Ciencias de la Computación y Tecnologías de la

Información, UVG

2) Framework para aplicaciones

Permite que los desarrolladores de aplicaciones

puedan acceder al hardware del dispositivo, correr servicios

en el background, agregar notificaciones, etc. Esto habilita

la posibilidad de reusar componentes que ya han sido

creados por otras aplicaciones e incluso reemplazar las aplicaciones nativas del dispositivo.

3) Librerías

Las librerías nativas de Android están escritas en

C/C++ y estas pueden ser accesadas por los programadores

a través del framework. El fin de estas librerías es tener

control sobre funciones básicas tales como reproducción

multimedia, bases de datos locales, graficas 2D y 3D, etc.

4) Runtime

Cada vez que se corre una aplicación en Android,

esta corre bajo su propio proceso. Esto se hace a partir de una máquina virtual Dalvik (se explicará más sobre el

proceso en las siguientes secciones) de modo que un

dispositivo Android es capaz de correr varias máquinas

virtuales al mismo tiempo. La máquina virtual Dalvik

depende de un kernel2 de Linux para asegurar que el

manejo de memoria sea óptimo.

5) Kernel de Linux

Los servicios básicos de Android, tales como

seguridad, manejo de memoria, y manejo de procesos, son

llevados a cabo a través de Linux 2.6.

(4)

B. iOS

El sistema operativo iOS corre en los dispositivos

iPhone, iPod touch y iPad. El sistema operativo incluye las herramientas para poder manejar el hardware de los

dispositivos lo cual es necesario a la hora que se desee

desarrollar aplicaciones.

Al igual que Android, iOS está diseñado por capas.

Los servicios básicos para el funcionamiento del sistema

operativo se encuentran en las capas más bajas y las más

altas contienen la tecnología que permite a los

desarrolladores abstraer funcionalidades de las capas más

bajas, sin embargo estas siempre estarán disponibles. Las

capas son las siguientes:

1) Cocoa Touch

Esta capa contiene los frameworks que los

desarrolladores necesitan para construir aplicaciones para

2 Kernel: Es la parte encargada de hacer el procesamiento de

información del lado del hardware, une el hardware con el software. Esto incluye manejo de memoria y acceso a controladores.

iOS. Las funcionalidades principales que cubren estos

frameworks son: multitasking, ingreso por touch,

notificaciones, gestos, servicios peer-to-peer, display por

medios externos y mensajería.

2) Media Las tecnologías necesarias para manejar gráficas,

audio y video del dispositivo se encuentran dentro de esta

capa. Generalmente el camino más fácil para un

programador es utilizar los frameworks que se encuentran

en la capa Cocoa Touch, sin embargo habrán ocasiones en

las que el procesamiento de multimedia es más complejo y

para esto se encuentran los frameworks que trabajan áreas

específicas del procesamiento multimedia.

3) Capa de Servicios Básicos

Estos son los servicios utilizados por el sistema y que la

mayoría de aplicaciones debe utilizar para poder correr en iOS, si no son utilizados directamente por la aplicación lo

más probable es que algún componente sobre el cual este

corriendo utilice uno de estos servicios. Los servicios

básicos de iOS incluyen herramientas que son necesarias en

la fase de compilación, principalmente para el manejo de

memoria.

4) Sistema Operativo Base

Aquí se encuentran todas las funcionalidades en base a las

cuales están construidos los frameworks de las capas

superiores. Estas funcionalidades son utilizadas cuando el programador necesita lidiar con seguridad o comunicación

que involucre hardware externo.

(5)

IV. DESARROLLO NATIVO

A. Android

Android posee el Android Software Development

Kit (SDK) el cual incluye todas las librerías y herramientas

necesarias para desarrollar en Android nativo. Dentro del

SDK se incluye un emulador para correr las aplicaciones sin necesidad de pasarlas a un dispositivo real, el emulador

está basado en QEMU (Quick Emulator) que se encarga de

virtualizar hardware incluyendo el procesador ARM que es

el corazón de los dispositivos móviles. (6)

Oficialmente Android no cuenta con un IDE

exclusivo o nativo para desarrollo de aplicaciones, hasta

ahora cuenta con un plugin para Eclipse Android

Development Tools (ADT) y este también es soportado por

NetBeans. En el Google I/O 2013 hicieron el anuncio del

Android Studio, es el nuevo IDE para desarrollo en Android

el cual es gratis y por el momento se encuentra con posibilidad de acceso previo antes de que sea lanzado

oficialmente. En la Figura 1 se puede observar cómo será el

Android Studio. (7)

Figura 1

El ADT permite bajar las diferentes versiones de

Android que se encuentran en el mercado hasta el momento, esto permite enfocarse en que el desarrollo

funcione eficientemente en la versión que más interese o

hacer pruebas de compatibilidad con versiones anteriores a

la versión que se tiene como target. (6)

El lenguaje para desarrollo en Android tiene la

misma gramática que el de Java (pueden ser considerados

los mismos lenguajes) pero no significa que haya

compatibilidad entre ambas plataformas. En la Figura 2

puede verse un ejemplo de una clase sencilla implementada

para Android.

Figura 2

Luego de que la aplicación sea compilada se

empaqueta en un archivo APK el cual incluye todo el

código del programa en Bytecode que se encuentra en

archivos .dex (Dalvik Executable) los cuales pueden ser

ejecutados por medio de una máquina virtual Dalvik.

B. iOS

Para poder desarrollar aplicaciones nativas de iOS

es necesario utilizar una computadora Macintosh (esta

puede ser reemplazada con otras opciones tales como

máquinas virtuales) con procesador Intel y Xcode tools.

Xcode contiene las herramientas para poder manejar proyectos, editar código, crear interfaces y

construir código ejecutable, entre otras funcionalidades.

Este IDE permite al desarrollador ejecutar la aplicación en

un simulador antes de ejecutarla en un dispositivo real. En

la Figura 3 se puede observar una de las vistas de Xcode.

Figura 3

Aunque el lenguaje para aplicaciones iOS sea

Objective-C, Xcode es capaz de compilar código escrito en

C, C++, Java y Applescript. El código que se encuentra en

la Figura 4 muestra un ejemplo del constructor de una clase

llamada “ScaryBugData” en Objective-C.

Figura 4

El lenguaje de programación que utilizan las

aplicaciones nativas de iOS es Objective-C, este está

basado en el lenguaje C por lo tanto es posible compilar un

programa escrito en C con un compilador de Objective-C. Este es un lenguaje orientado a objetos y es utiliza un

compilador GCC (será explicado con más detalle en las

siguientes secciones).

(5)

V. COMPILACIÓN NATIVA

A. Android

Android utiliza una máquina virtual Dalvik para

ejecutar las aplicaciones en su sistema operativo. Los pasos

de compilación antes de que la aplicación sea ejecutada en

el dispositivo son los siguientes (mostrados en la Figura 5):

El programa escrito en lenguaje nativo de Android

o Java son compiladas a código fuente Bytecode

utilizando ya sea el IDE Eclipse o NetBeans.

Los archivos .class son convertidos a .dex antes de

ser instalados en el dispositivo. Los archivos .dex son empaquetados a un solo

archivo .apk que será el ejecutable ya en el

dispositivo.

Figura 5

(8)

El primer paso está dividido en tres fases, la

primera es la generación de los archivos de Java a partir de

los recursos (iconos, Strings, etc.) que utiliza la aplicación

para Android. Este primer paso se lleva a cabo con ayuda

de una herramienta llamada “aap” la cual compila todos estos recursos a un solo archivo .java. Luego se hace la

compilación de las interfaces que se usen en el programa,

estas son almacenadas con su mismo nombre solamente que

la extensión es .java. Por último se hace la compilación

final de los archivos .class que contienen el código fuente

con los otros generados en los pasos anteriores, se genera el

Bytecode que incluye todas las librerías del API3 de

Android.

Lo siguiente es convertir el Bytecode de Java a

Bytecode de Dalvik. Al terminar la compilación, se utiliza

la herramienta “dx” que convierte todos los .class a un solo archivo ejecutable .dex.

Por último, el ejecutable debe ser comprimido en

un paquete APK. Con el fin de realizar este paso se utiliza

la herramienta “apkbuilder” el cual empaqueta:

El ejecutable .dex

Los recursos (imágenes, sonidos, etc.) que utiliza

la aplicación

Librerías nativas

(9)

Antes que los .class sean convertidos a .dex estos

podrían ser ejecutados en una JVM pero no serían

compatibles con la MV Dalvik. Esta MV tiene una

arquitectura de registros que es totalmente lo opuesto a la

JVM ya que esta está basada en Stacks, tiene una “Constant

Pool” de 32 bits para simplificar la interpretación del

código, las instrucciones ejecutadas por la JVM son de 8

bits y las de la Dalvik son de 16 lo cual permite que sí se

puedan tener variables globales y mejore el proceso de

interpretación. Dentro del proceso de empaquetado a APK

se lleva a cabo un paso llamado “alineamiento” el cual hace todas las instrucciones de 8 bits sean “alineadas”

correctamente y de forma eficiente a instrucciones de 16

bits, esto se hace por medio de la herramienta “Zipalign”.

(10)

Este cambio de máquina de Stack a máquina de

registro resultó ser de mucha importancia para Google ya

que los procesadores ARM llegan a ser hasta 3 veces más

rápidos con aplicaciones para Android que con aplicaciones

para Java.

3 Application Programming Interface, es una librería que contiene la información sobre como estarán interactuando distintos componentes del software.

A partir de Android 2.2 la MV Dalvik posee un

compilador en tiempo de ejecución o JIT (Just-In-Time),

esto quiere decir que el Bytecode generado (los archivos

.dex dentro del .apk) será traducido a lenguaje de máquina

hasta que se esté ejecutando el programa. De esta forma es

posible hacer optimizaciones al código fuente antes de ser ejecutado, es decir en su traducción a Bytecode,

permitiendo que la ejecución sea más rápida.

(11)

B. iOS

Las aplicaciones para iOS son desarrolladas con el lenguaje Objective C el cual es compilado por GNU

Compiler Collection (GCC). GNU es un sistema que

soporta varios lenguajes de programación, la mayoría,

derivados de C y una de las razones por la cual fue

elegido como compilador para Objective C fue por su

compatibilidad con la arquitectura ARM. (12)

La sintaxis de este lenguaje de programación está

basada en C, por esta razón es posible insertar cualquier

código escrito en C y este será ejecutado sin ningún

problema. Objective C es un lenguaje orientado a objetos pero C no lo es, para complementar esto utiliza la sintaxis

de SmallTalk. SmallTalk es diferente a otros lenguajes

orientados a objetos como Java, C#, etc. gracias a su

estilo de programación, este no hace llamadas a métodos

sino “envía mensajes”. Los mensajes son interpretados

por el objeto que está siendo receptor y lo hace en tiempo

de ejecución, esto permite que no exista la revisión de

tipos y por lo tanto sólo hasta que el programa se esté

ejecutando se podrán producir los errores los cuales son

manejados por medio de excepciones. (13)

Objective C tiene dos tipos de archivos; los .m son los que almacenan el código con las implementaciones

mientras que los .h son los que contienen las interfaces.

(13)

GCC funciona como cualquier otro compilador,

luego de revisar el código fuente pasa a la fase de generar

el código objeto. Para iOS el código objeto que se utiliza

es Mach-O y tiene la estructura que se muestra en la

Figura 6.

Figura 6

En el archivo Mach-O, el encabezado contiene la

información básica sobre la arquitectura sobre la cual se

ejecutará y las banderas utilizadas a la hora de ser ejecutado. En la siguiente sección están las instrucciones

de carga, estas especifican la siguiente información:

El espacio inicial del archivo en memoria

Ubicación de la tabla de símbolos

Estado inicial de la máquina

Nombres de librerías externas

En los siguientes segmentos se encuentra

información sobre espacios de memoria, direcciones de

memoria, etc. El último de estos segmentos contiene la tabla de símbolos e información sobre librerías. (14)

El código objeto Mach-O que se genera tiene la

extensión .o. Este archivo entra al último proceso llamado

“Vinculación” (Linking). Aquí se toman todos los archivos

.o generados y los empaqueta en un solo ejecutable, el

ejecutable incluirá otros archivos como librerías y recursos

que necesita la aplicación. (13)

VI. VENTAJAS Y DESVENTAJAS DEL DESARROLLO CROSS-PLATFORM

A. Ventajas

Reducción de costos debido a la rapidez de

desarrollo además que luego de que la aplicación

sea lanzada, se puede utilizar el mismo código

como base para dar mantenimiento y tener a los

usuarios satisfechos en lapsos de tiempo cortos.

Disponibilidad de plugins que facilitan el acceso

a servicios y/o hardware como GPS.

Generalmente las herramientas cross-platform tienen la posibilidad de integrar plugins que

evitan que el desarrollador escriba código para

servicios básicos que ya han sido implementados

en incontables ocasiones.

Soporte para servicios en la nube lo cual facilita

al desarrollador poner a disposición del público

su aplicación ya que no es necesario que cuente

con toda la tecnología necesaria para armar este

negocio.

Facilidad de compilación. debido a que

solamente se compila una vez, el desarrollo cross-platform ahorra a los desarrolladores que

deban compilar varias veces un mismo producto.

B. Desventajas

Desactualización en el framework de la plataforma original, esto pasa cuando, por ejemplo, Google o

Apple agregan una funcionalidad a su framework.

Por obvias razones la herramienta no tendrá acceso

inmediato a esta nueva funcionalidad y por lo tanto

el desarrollador deberá esperar hasta que esta sea

añadida a ambiente cross-platform

El tiempo de ejecución suele ser más lento que

cuando se trata de una aplicación nativa.

El uso del hardware encargado de mostrar y

procesar gráficas es limitado y generalmente se

debe usar alguna herramienta que incluya el

ambiente de desarrollo. Cuando hablamos de dispositivos móviles nos

enfrentamos a una gran variedad, por esta razón el

diseño es de suma importancia y una aplicación en

Android no es lo mismo que una aplicación en

iOS. El cross-platform elimina la posibilidad de

hacer un diseño eficiente para cada una de las

plataformas.

El desarrollador debe pagar la herramienta para

poder colocar la aplicación en venta. Este es el

caso de la mayoría de herramientas cross-platform.

(15)

VII. HERRAMIENTAS PARA DESARROLLO CROSS-PLATFORM

Existen tanto Engines como Frameworks para

lograr este tipo de desarrollo, estos pueden utilizar un

lenguaje de programación diseñado específicamente para la

herramienta o adecuan uno que ya sea popular entre los

desarrolladores. La mayoría de herramientas, cualquiera sea

su tipo, utilizan lenguajes para desarrollo web debido a su

flexibilidad y popularidad. (16)

A. PhoneGap

PhoneGap es un Framework Open Source que

permite crear aplicaciones para móviles utilizando

lenguajes de desarrollo web (HTML, CSS y Javascript).

Actualmente es capaz de compilar para las plataformas iOS,

Android, Blackberry OS, WebOS, Windows Phone,

Symbian y Bada pero está investigación se enfocará

únicamente en iOS y Android.

Como se mencionó anteriormente, una de las

desventajas de trabajar con herramientas cross-platform es

la limitación que se puede tener con el hardware y algunos

servicios que brinde el sistema operativo nativo. PhoneGap

tiene estas limitaciones en algunas de las plataformas con

las que trabaja, sin embargo para iOS y Android es capaz de

utilizar todos los servicios y hardware que estas plataformas

ofrecen y están especificados en la Figura 7. (17)

Figura 7

Cada una de los servicios o funcionalidades que se

presentan en la Figura 7 están integradas por diferentes

API’s de PhoneGap (uno por cada elemento). (18)

La forma en que trabaja PhoneGap es llamada

“hibrida” debido a que no genera exactamente una aplicación nativa para el dispositivo sino que es un

WebApp4 que hace llamadas a las API’s nativas de la

plataforma. Esto significa que en realidad el contenido

visual que muestra una aplicación desarrollada con

PhoneGap no utiliza los frameworks de la interfaz de

usuario que posee la plataforma nativa sino que lo hace a

través de vistas web.

Debido a que PhoneGap sí hace llamadas a las

API’s nativas de la plataforma, se le permite al

desarrollador que dentro de su código ingrese llamadas

directas a las API’s nativas que puede ser de utilidad para un manejo más completo de los procesos. (19)

El proceso de compilación para PhoneGap consta

de dos etapas, la primera se realiza desde el IDE y la

segunda en la nube con la ayuda de los servidores de

PhoneGap. La primera parte que se lleva a cabo en el IDE

es simplemente el escaneo y parseo del código fuente, este

código fuente incluye archivos HTML, Javascript CSS y

plugins de PhoneGap. Estos archivos son comprimidos en

una carpeta ZIP y subidos al constructor de PhoneGap en la

nube para iniciar con la segunda etapa. (20)

El “PhoneGap Build” se encarga de “traducir”

todas las llamadas de las API’s de PhoneGap a llamadas de

API’s nativas dejando todo lo visual como una aplicación

web que hace las llamadas a los procedimientos nativos,

luego empaqueta todos los archivos al ejecutable indicado

para cada plataforma y lo habilita para su descarga e

instalación. La traducción a llamadas a API’s nativas las

hace por medio del SDK de cada plataforma al igual que la

generación del archivo ejecutable. En la Figura 8 se muestra

un diagrama con el proceso de compilación y en la Figura 9

cómo se dividen los respectivos SDK’s. (20)

4 Web Application, es un conjunto de recursos (HTML, conexiones a servidor, etc.) que llevan a cabo una tarea por medio de una conexión a un servidor local o remoto.

Figura 8

Figura 9

En la Figura 10 se puede observar cómo interactúa

la aplicación con el dispositivo. Todo lo relacionado con la

interfaz se hace de forma web es decir con el HTML y CSS

del código fuente, luego el Javascript hace las llamadas a

las API’s nativas que dan una respuesta y esta se muestra de

nuevo en forma web. (20)

Figura 10

B. MoSync

A diferencia de PhoneGap, MoSync es un SDK completo

que se integra a Eclipse para poder crear aplicaciones, estas

son escritas en C/C++, HTML5 y Javascript. Otro factor

que diferencia MoSync de PhoneGap es que este SDK sí

genera aplicaciones nativas para cada plataforma móvil. Las plataformas que este soporta son Android, iOS, Windows

Mobile Classic, Windows Phone, Symbian, Moblin y Java

Mobile. (21)

El proceso de compilación utilizando MoSync y ejecución

de la aplicación en la plataforma móvil están descritos en la

Figura 11.

Figura 11

Al igual que Objective-C, MoSync utiliza el

compilador GCC que ha sido modificado para que genere

código objeto MoSync que luego puede ser ejecutado por la

plataforma virtual de MoSync. Esta plataforma está basada

en registros para facilitar una re-compilación hacia el

código de cada plataforma o hacia código de más alto nivel en lugar de código objeto. (22)

Las librerías de MoSync y el código objeto

generado por GCC entran a Pipetool. Las librerías

contienen la información sobre procedimientos básicos y

manejo de la interfaz gráfica. Pipetool se encarga de unir el

código objeto con estas librerías, puede ser comparado con

el proceso de “Linking” en iOS con la diferencia que

Pipetool también funciona como un compilador. La función

de compilador la realizar al optimizar el código generado

luego de hacer el “linking” y después genera una versión binaria de MoSync IL o código Java dependiendo de cuál

sea su uso final. (22)

En caso se genere código Java, este será compilado

ya sea por el ambiente J2ME o por la máquina virtual

Dalvik en caso se desee generar Bytecode para Android.

Si en caso se genera MoSync IL, este se asigna al

ambiente indicado para la plataforma en la cual se desee

ejecutar la aplicación. El código binario MoSync es

traducido al código objeto de la plataforma deseada y este

ya está listo para ser ejecutado. (22)

VIII. BIBLIOGRAFÍA

1. Espeso, Pablo. ARM, La "Navaja Suiza de los

Procesadores". Xataka. [En línea] 24 de diciembre de 2012.

http://www.xataka.com/componentes-de-pc/arm-la-navaja-

suiza-de-los-procesadores-1.

2. ARM Ltd. ARM Processor Architecture. ARM. [En

línea] 2013.

http://www.arm.com/products/processors/instruction-set-

architectures/index.php.

3. Bramble, Cate. Definition Platform. Search Server

Virtualization. [En línea] Septiembre de 2006. http://searchservervirtualization.techtarget.com/definition/pl

atform.

4. Android, Inc. About Android. Developer Android. [En

línea]

http://developer.android.com/about/versions/index.html.

5. Apple Inc. iOS Technology Overview. Developer Apple.

[En línea] 2012.

http://developer.apple.com/library/ios/documentation/Misce

llaneous/Conceptual/iPhoneOSTechOverview/iPhoneOSTe

chOverview.pdf.

6. Android Open Source Project. Android SDK. Developer Android. [En línea]

http://developer.android.com/sdk/index.html.

7. Android Open Source Proyecto. Getting Started with

Android Studio. Developer Android. [En línea] 15 de mayo

de 2013.

http://developer.android.com/sdk/installing/studio.html.

8. Android Open Source Project. Building and Running.

Developer Android. [En línea]

http://developer.android.com/tools/building/index.html.

9. Ostermeier, Daniel y Sankey, Jason. Understanding the

Android Building Process. A Little Madness. [En línea] 27

de junio de 2010. http://www.alittlemadness.com/2010/06/07/understanding-

the-android-build-process/.

10. Queru, Jean-Baptiste. Zipalign: an easy optimization.

Developer Android. [En línea] 28 de septiembre de 2009.

http://android-developers.blogspot.com/2009/09/zipalign-

easy-optimization.html.

11. Bornstein, Dan. Dalvik JIT. Developer Android. [En

línea] 25 de mayo de 2010. http://android-

developers.blogspot.com/2010/05/dalvik-jit.html.

12. Apple Inc. GNU C/C++/Objective-C 4.2.1 Compiler

User Guide. Developer Apple. [En línea] https://developer.apple.com/library/ios/#documentation/De

veloperTools/gcc-4.2.1/gcc/Invoking-GCC.html.

13. DeVoe, Jiva. Understanding the Compilation Process.

Objective -C. s.l. : Wiley Publishing Inc, 2011, pág. 403.

14. Apple Inc. OS X ABI Mach-O File Format Reference.

Developer Apple. [En línea] 2 de abril de 2009.

https://developer.apple.com/library/mac/#documentation/de

velopertools/conceptual/MachORuntime/Reference/referen

ce.html.

15. Warren, Christina. The Pros and Cons of Cross-

Platform App Design. Mashable. [En línea] 16 de febrero

de 2012. http://mashable.com/2012/02/16/cross-platform-

app-design-pros-cons/.

16. O'Dell, Jolie. 5 Cross-Platform Mobile Development

Tools You Should Try. Mashable. [En línea] 10 de agosto de 2010. http://mashable.com/2010/08/11/cross-platform-

mobile-development-tools/.

17. Adobe Systems Inc. Supported Features. PhoneGap.

[En línea] http://phonegap.com/about/feature/.

18. —. API Reference. PhoneGap Documentation. [En

línea] http://docs.phonegap.com/en/2.7.0/index.html.

19. Trice, Andrew. PhoneGap Explained Visually.

PhoneGap. [En línea] 2 de mayo de 2012.

http://phonegap.com/2012/05/02/phonegap-explained-

visually/.

20. Pukhalski, Ilya. How PhoneGap Really Works.

SpeackerDeck. [En línea] 12 de febrero de 2013. https://speakerdeck.com/witchfinderx/how-phonegap-

really-works.

21. MoSync AB. MoSync SDK. MoSync Developer. [En

línea] 2013. http://www.mosync.com/docs/index.html.

22. Mosavian, Ali. Under the Hood. MoSync. [En línea] 14

de enero de 2010.

http://www.mosync.com/blog/2010/01/under-hood.