¿Qué sucede con el código JavaScript después de compilar la aplicación utilizando Titanium Mobile?

Question

Instalé Titanium desde el acelerador y creé la aplicación de ejemplo "KitchenSink".

Todo funciona bien, solo me pregunto dónde termina el código javascript en una aplicación creada.

Analicé el proyecto de Xcode y también la aplicación de resultados como la 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 los textos de cadena utilizados en la aplicación.

La información más cercana que encontré es una respuesta aquí: How Does Appcelerator Titanium Mobile Work? pero no entiendo claramente cómo funciona el proceso.

¿Se está compilando el código javascript en un código binario (qué compilador se utiliza entonces?), O ¿se ha transformado en algún formato de datos especial y se ha interpretado en una aplicación en ejecución?

Actualización:

Esto es lo que puedo ver en un directorio de construcción/androide 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 me veía en app.apk antes, todo lo que podía ver eran estos archivos de clase correspondientes a cada uno de los archivos javascript. Por lo tanto, asumí que en Android se está compilando javascript para JVM. ¿Por qué no se pueden encontrar estos en app.apk?

Answer 1

Titanium no es un envoltorio alrededor de una vista web como se indicó anteriormente (aunque eso explica con precisión cómo funciona Phonegap). La respuesta de Jeff, vinculado en la cuestión, es una explicación técnicamente correcta de cómo funciona titanio, pero aquí es la mejor versión que he escuchado hasta ahora, desde Marshall Culpepper:

Es cierto que Titanio móvil utiliza la vista web (tanto en Android y iOS) en los pre-1.0 días. Sin embargo, esto ya no es así y no lo ha sido desde que lanzamos 1.0 en marzo de 2010.

Desde 1.0, hemos enviado dos tiempos de ejecución de Javascript por separado con nuestras aplicaciones, y estamos ejecutando el código Javascript directamente sin un WebView. Toda su aplicación de principio a fin ahora está controlada por JS, y ofrecemos un conjunto completo de API nativas que lo habilitan. Todo, desde widgets de interfaz de usuario (sí, incluido WebView), API principales como redes, sistema de archivos, base de datos, hasta elementos específicos de sistema operativo como actividades de JS en Android. En el frente de tiempo de ejecución de JS, estamos enviando una versión bifurcada de 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 es dependiente de la plataforma, pero por lo general se rompe de esta manera:

• Fuente se analiza de forma estática para encontrar referencias a los módulos de titanio
• cadenas de localización (strings.xml), App los metadatos (tiapp.xml) y las imágenes específicas de densidad generan análogos específicos de la plataforma.
• En iOS:
  • Un XCode proyecto/configuración se genera
  • JS fuente es base64'd y inline como una variable en un archivo de C generado
  • xcodebuild se utiliza para generar los binarios finales
  • perfiles de aprovisionamiento, etc claves de firma se aplican
  • iTunes y algún otro pegamento se utiliza para enviar la IPA a su dispositivo iOS
• En Android: se genera
  proyecto
  • un androide/Eclipse
  • En el modo de "desarrollo", la fuente de JS se empaqueta como activos APK
  • En el modo de "Distribución" (producción), cuando esté listo para enviar la aplicación, compilamos el bytecode JS a Java usando 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 de Android SDK se utilizan para generar y generar el APK final
  • BAD y herramienta de claves se utilizan para empujar el APK a cabo en el emulador y/o dispositivo

Hay muchos más detalles que podía sumergirse en concreto en cada uno de estos puntos, pero el punto que Quería volver a casa porque ya no usamos WebView como nuestro motor Javascript. Usted puede sin embargo, todavía incorporamos WebViews, y proporcionamos una integración simple que le permite llamar a API de Titanium desde un WebView incrustado.

Answer 2

Lo que jhaynie está diciendo 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 código nativo asociado (tal vez C++) internamente. Por ejemplo, el navegador podría decir: "Este script se está ejecutando getElementById(), así que voy a ejecutar mis propios métodos C++ para lograr eso". Lo que Titanium está haciendo es averiguar qué tendría JS-> C++ (o en este caso, JS-> Objective-C) de antemano, y compilar eso. 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 que se parezca a lo que escribió originalmente en su secuencia de comandos. Todo lo que debe dejarse a un intérprete se procesa y convierte, y sus símbolos cambiarán (por ejemplo, una llamada a myTestFunction() se puede convertir a A(), o 10001101001101: P).

---

El habitual uso de Javascript es que sea interpretado en tiempo real mediante un programa en ejecución. Eso no es lo que sucede aquí, y es por eso que no puedes ver ningún rastro de tu script.

, JavaScript es pre-procesada

titanio realiza la interpretación de la secuencia de comandos como cualquier otro programa haría (por ejemplo, un navegador web). Se da cuenta de las dependencias que tiene tu script en la API de Titanium y lo establece. A continuación, asigna sus símbolos directamente en (en el caso del iPhone) Objective-C.

Un programa generalmente leería en su script (que es simplemente un String), lo interpretará y ejecutará el código C para lograr lo que su script solicitó.Titanium hace esto de antemano para descubrir qué código C debe ejecutarse, y realiza la conversión por adelantado.

El código se compila en lo posible

Sobre la base de la interpretación de su código y sus dependencias en la API de titanio, se da cuenta de lo que el código puede ser compilado directamente, y lo que no debe ser compilado con el fin para permitirles una dinámica completa de Javascript. No sé cómo se elige lo que se compila y lo que no se compila, pero se puede consultar la fuente si se quiere saber tanto detalle.

El código que aún se debe interpretar (a la izquierda como una secuencia de comandos) se sigue convirtiendo en símbolos que dan como resultado una asignación más eficiente al código nativo. Por lo tanto, sigue siendo un script interpretado, pero eso no significa que siga siendo 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 compilación C se compila con GCC para crear un binario nativo.

Usted tiene una aplicación ejecutable *

Ahora usted tiene una aplicación que se puede ejecutar en el 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 la velocidad del rayo. : P

Espero que esto tenga sentido ahora, porque es todo lo que tengo! : D