precio - ¿Qué sucede con el código JavaScript después de compilar la aplicación con Titanium Mobile?
appcelerator titanium ventajas y desventajas (2)
Instalé Titanium desde appcelerator y construí la aplicación de ejemplo "KitchenSink".
Todo funciona bien, me pregunto dónde termina el código javascript en una aplicación creada.
Conseguí el proyecto Xcode y también la aplicación de resultados tal como lo encontré en Library/Application Support/iPhone Simulator/....KitchenSink.app , pero no puedo encontrar ningún nombre de función de los archivos .js , ni siquiera una cadena Textos utilizados dentro de la aplicación.
La información más cercana que encontré es una respuesta aquí: ¿Cómo funciona Appcelerator Titanium Mobile? pero no entiendo claramente cómo funciona el proceso.
¿Se está compilando el código javascript en un código binario (qué compilador se usa entonces?), O simplemente se transforma en algún formato especial de datos y se interpreta en una aplicación en ejecución?
Actualizar:
Esto es lo que puedo ver en un directorio build / android de KitchenSink:
michal:bin mac$ find . -name table_view_layout/*
./assets/Resources/examples/table_view_layout.js
./assets/Resources/examples/table_view_layout_2.js
./assets/Resources/examples/table_view_layout_3.js
./assets/Resources/examples/table_view_layout_4.js
./assets/Resources/examples/table_view_layout_5.js
./classes/org/appcelerator/generated/examples/table_view_layout.class
./classes/org/appcelerator/generated/examples/table_view_layout_2.class
./classes/org/appcelerator/generated/examples/table_view_layout_3.class
./classes/org/appcelerator/generated/examples/table_view_layout_4.class
./classes/org/appcelerator/generated/examples/table_view_layout_5.class
michal:bin mac$ unzip -t app.apk | grep table_view_layout
testing: assets/Resources/examples/table_view_layout.js OK
testing: assets/Resources/examples/table_view_layout_2.js OK
testing: assets/Resources/examples/table_view_layout_3.js OK
testing: assets/Resources/examples/table_view_layout_4.js OK
testing: assets/Resources/examples/table_view_layout_5.js OK
No miré en app.apk antes, todo lo que pude ver fueron estos archivos de clase correspondientes a cada uno de los archivos javascript. Por lo tanto, asumí que en Android javascript se está compilando para JVM. ¿Por qué no se pueden encontrar en app.apk?
Lo que dice jhaynie en su pregunta vinculada es que Titanium interpreta su código JS y lo convierte en algo que es casi idéntico a Objective-C.
En una aplicación web, el navegador lee e interpreta su Javascript y ejecuta el código nativo asociado (quizás C ++) internamente. Por ejemplo, el navegador podría decir: "Este script está ejecutando getElementById() , así que ejecutaré mis propios métodos de C ++ para lograr eso". Lo que Titanium está haciendo es averiguar qué JS-> C ++ (o en este caso, JS-> Objective-C) sería por adelantado, y compilarlo. Todavía deja un intérprete abierto donde sea necesario para su código dinámico, pero convertirá y compilará lo que pueda.
Eso significa que no encontrará nada similar a lo que escribió originalmente en su script. Cualquier cosa que deba dejarse a un intérprete aún se procesa y convierte, y sus símbolos cambiarán (por ejemplo, una llamada a myTestFunction() podría convertirse a A() , o 10001101001101 : P).
El uso habitual de Javascript es tenerlo interpretado en tiempo real por un programa en ejecución. Eso no es lo que está pasando aquí, y es por eso que no puedes ver ningún rastro de tu script.
Titanium realiza la interpretación de su script como cualquier otro programa (como un navegador web). Averigua qué dependencias tiene tu script en la API de Titanium y configura esas cosas. Luego asigna sus símbolos directamente en (en el caso del iPhone) Objective-C.
Por lo general, un programa lee en su script (que es simplemente una cadena), lo interpreta y ejecuta el código C para lograr lo que su script solicitó. Titanium hace esto de antemano para averiguar qué código C debe ejecutarse, y realiza la conversión por adelantado.
Basándose en la interpretación de su código y sus dependencias en la API de Titanium, Titanium descubre qué código puede compilarse directamente y qué no debe compilarse para permitir la dinámica completa de Javascript. No sé cómo elige lo que hace y no se compila, pero puedes revisar la fuente si quieres saber tantos detalles.
El código que aún debe interpretarse (dejado como un script) todavía se convierte en símbolos que resultan en una asignación más eficiente al código nativo. Así que sigue siendo un script interpretado, pero eso no significa que todavía sea Javascript. Esto significa que estas partes de su script aún se ejecutarán más rápido que el Javascript habitual.
Para iPhone, la compilable C se compila con GCC para crear un binario nativo.
Ahora tienes una aplicación que puedes ejecutar en tu dispositivo móvil. Su código compilable se ha compilado y se ejecuta a la velocidad del rayo, mientras que el resto se convierte y aún se interpreta de una manera más eficiente que se ejecuta a casi la velocidad del rayo. :PAG
Espero que esto tenga sentido ahora, porque es todo lo que tengo! :RE
Titanium no es una envoltura alrededor de una vista web como se indicó anteriormente (aunque eso explica con precisión cómo funciona Phonegap). La respuesta de Jeff, vinculada en la pregunta, es una explicación técnicamente correcta de cómo funciona Titanium, pero aquí está la mejor versión que he escuchado, de parte de Marshall Culpepper :
Es cierto que Titanium Mobile usó WebView (tanto en Android como en iOS) en los días anteriores a 1.0. Sin embargo, esto ya no es cierto y no ha sido así desde que nuestra versión 1.0 es marzo de 2010.
Desde la versión 1.0, hemos enviado dos tiempos de ejecución de Javascript separados con nuestras aplicaciones, y estamos ejecutando el código Javascript directamente sin una vista web. JS ahora controla toda la aplicación, de principio a fin, y proporcionamos un conjunto completo de API nativas que lo habilitan. Todo, desde widgets de UI (sí, incluyendo WebView), API Core como Networking, Filesystem, Database, hasta cosas específicas del sistema operativo como JS Activities en Android. En el frente de ejecución de JS, estamos enviando una versión bifurcada del JavaScriptCore de WebKit en iOS y una instantánea de Rhino 1.7 R3 CVS para Android. Lo que realmente hacemos con su fuente de javascript depende de la plataforma, pero generalmente se divide de la siguiente manera:
- La fuente se analiza estáticamente para encontrar referencias a los módulos de titanio.
- Las cadenas de localización (strings.xml), los metadatos de la aplicación (tiapp.xml) y las imágenes específicas de densidad generan todos los análogos específicos de la plataforma.
- En iOS:
- Se genera un proyecto / configuración XCode
- JS Source es base64''d y está alineado como una variable en un archivo C generado
- xcodebuild se utiliza para generar los binarios finales
- Se aplican perfiles de aprovisionamiento, claves de firma, etc.
- iTunes y algún otro pegamento se utilizan para enviar el IPA a su dispositivo iOS
- En Android:
- Se genera un proyecto de Android / Eclipse.
- En el modo "Desarrollo", la fuente JS se empaqueta como activos APK
- En el modo "Distribución" (producción), cuando esté listo para enviar la aplicación, compilamos el código de bytes de JS a Java utilizando el compilador Rhino JSC. También puede habilitar esto durante el modo de desarrollo configurando "ti.android.compilejs" en "true" en tiapp.xml, consulte: http://developer.appcelerator.com/question/100201/enable-android-byte-code-compile
- dex, aapt y otras herramientas del SDK de Android se utilizan para crear y generar el APK final
- adb y keytool se utilizan para enviar el APK al emulador y / o dispositivo
Hay muchos más detalles que podría analizar específicamente en cada uno de estos puntos, pero el punto que quería recordar es que ya no usamos el WebView como nuestro motor de Javascript. Sin embargo, aún puede integrar WebViews, y proporcionamos una integración simple que le permite llamar a las API de Titanium desde un WebView incorporado.