Qu'advient-il du code JavaScript après la compilation de l'application avec Titanium Mobile ?

Question

J'ai installé Titanium depuis appcelerator et construit l'application d'exemple "KitchenSink".

Tout fonctionne bien, je me demande simplement où se trouve le code javascript dans une application construite.

J'ai fait un grep sur le projet Xcode et aussi sur l'application résultat telle que je l'ai trouvée dans Library/Application Support/iPhone Simulator/....KitchenSink.app mais je ne trouve pas de noms de fonctions de .js ni même les chaînes de caractères utilisées dans l'application.

L'information la plus proche que j'ai trouvée est une réponse ici : Comment fonctionne Appcelerator Titanium Mobile ? mais je ne comprends pas clairement comment le processus fonctionne.

Le code javascript est-il compilé en un code binaire (quel compilateur est alors utilisé ?), ou est-il simplement transformé en un format de données spécial et interprété dans une application en cours d'exécution ?

Mise à jour :

C'est ce que je peux voir dans un répertoire 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

Je n'ai pas regardé dans app.apk avant, tout ce que j'ai pu voir, ce sont ces fichiers de classe correspondant à chacun des fichiers javascript. J'ai donc supposé que sur Android, le javascript est compilé pour la JVM. Pourquoi ne les trouve-t-on pas dans app.apk ?

Answer 1

Titanium n'est pas une enveloppe autour d'une vue Web comme indiqué précédemment (bien que cela explique précisément le fonctionnement de Phonegap). La réponse de Jeff, dont le lien figure dans la question, est une explication techniquement correcte du fonctionnement de Titanium, mais voici la meilleure version que j'ai entendue jusqu'à présent, de la part de Marshall Culpepper :

Il est vrai que Titanium Mobile utilisait le WebView (à la fois dans Android et iOS) dans les jours précédant la version 1.0. Cependant, ce n'est plus vrai et ce depuis notre version 1.0 de mars 2010.

Depuis la version 1.0, nous fournissons deux moteurs d'exécution Javascript distincts avec nos applications, et nous exécutons le code Javascript directement. sans une WebView. L'ensemble de votre application, du début à la fin, est désormais contrôlé par JS, et nous fournissons un ensemble complet d'API natives qui le permettent. Tout va des widgets d'interface utilisateur (oui, y compris WebView), des API de base comme le réseau, le système de fichiers, la base de données, jusqu'aux éléments spécifiques au système d'exploitation comme les activités JS dans Android. En ce qui concerne le moteur d'exécution JS, nous fournissons une version bifurquée de JavaScriptCore de WebKit pour iOS et un instantané de Rhino 1.7 R3 CVS pour Android. Ce que nous faisons réellement avec votre source javascript dépend de la plateforme, mais généralement, cela se décompose comme suit :

• La source est analysée statiquement pour trouver les références aux modules Titanium.
• Les chaînes de localisation (strings.xml), les métadonnées des applications (tiapp.xml) et les images spécifiques à la densité génèrent toutes des analogues spécifiques à la plate-forme.
• Dans iOS :
  • Un projet / une configuration XCode est généré(e)
  • La source JS est traitée en base64 et intégrée en tant que variable dans un fichier C généré.
  • xcodebuild est utilisé pour générer les binaires finaux
  • les profils de provisionnement, les clés de signature, etc. sont appliqués
  • iTunes et quelques autres collets sont utilisés pour envoyer l'IPA à votre appareil iOS
• Dans Android :
  • Un projet Android / Eclipse est généré
  • En mode "Développement", la source JS est emballée en tant que ressource APK.
  • En mode "Distribution" (production), lorsque vous êtes prêt à expédier l'application, nous compilons le JS en bytecode Java à l'aide du compilateur Rhino JSC. Vous pouvez également activer cette fonction en mode développement en définissant "ti.Android.compilejs" à "true" dans tiapp.xml, voir : http://developer.appcelerator.com/question/100201/enable-Android-byte-code-compile
  • dex, aapt, et d'autres outils Android SDK sont utilisés pour construire et générer l'APK final.
  • adb et keytool sont utilisés pour pousser l'APK vers l'émulateur et/ou le dispositif.

Il y a beaucoup plus de détails que je pourrais approfondir spécifiquement sur chacun de ces points, mais le point que je voulais faire passer est que nous n'utilisons plus le WebView comme notre moteur Javascript. Vous pouvez consulter le site peut Cependant, les WebViews sont toujours intégrées, et nous fournissons une intégration simple qui vous permet d'appeler les API Titanium à partir d'une WebView intégrée.

Answer 2

Ce que dit jhaynie dans sa question, c'est que Titanium interprète votre code JS et le convertit en quelque chose de presque identique à l'Objective-C.

Dans une application web, le navigateur lit et interprète votre Javascript et exécute en interne le code natif associé (peut-être C++). Par exemple, le navigateur pourrait dire "Ce script est en train d'exécuter getElementById() alors je vais utiliser mes propres méthodes C++ pour y parvenir." Ce que Titanium fait, c'est déterminer à l'avance ce que serait ce JS->C++ (ou dans ce cas, JS->Objective-C) et le compiler. Il laisse toujours un interpréteur ouvert si nécessaire pour votre code dynamique, mais il convertit et compile ce qu'il peut.

Cela signifie que vous ne trouverez rien qui ressemble à ce que vous avez écrit à l'origine dans votre script. Tout ce qui doit être laissé à un interpréteur est encore traité et converti, et vos symboles changeront (par exemple, un appel à myTestFunction() pourrait être converti en A() ou 10001101001101 :P).

---

Le site habituel L'utilisation de Javascript consiste à le faire interpréter en temps réel par un programme en cours d'exécution. Ce n'est pas ce qui se passe ici, et c'est pourquoi vous ne voyez aucune trace de votre script.

• Javascript est prétraité

  Titanium effectue l'interprétation de votre script comme le ferait tout autre programme (tel qu'un navigateur web). Il détermine les dépendances de votre script par rapport à l'API de Titanium et configure ces éléments. Il fait ensuite correspondre vos symboles directement en Objective-C (dans le cas de l'iPhone).

  En général, un programme lit votre script (qui est simplement une chaîne de caractères), l'interprète et exécute du code C pour accomplir ce que votre script a demandé. Titanium effectue cette opération à l'avance pour déterminer quel code C doit être exécuté, et effectue la conversion à l'avance.

• Le code est compilé lorsque cela est possible

  Sur la base de l'interprétation de votre code et de ses dépendances à l'égard de l'API Titanium, Titanium détermine le code qui peut être directement compilé et celui qui ne doit pas l'être afin de permettre la pleine dynamique de Javascript. Je ne sais pas comment il choisit ce qui doit être compilé et ce qui ne doit pas l'être, mais vous pouvez consulter les sources si vous voulez connaître tous ces détails.

  Le code qui doit encore être interprété (laissé comme un script) est encore converti en symboles qui permettent un mappage plus efficace vers le code natif. C'est donc toujours un script interprété, mais cela ne signifie pas que c'est toujours du Javascript. Cela signifie que ces parties de votre script s'exécuteront toujours plus rapidement que le Javascript habituel.

  Pour l'iPhone, le C compilable est compilé avec GCC pour créer un binaire natif.

• Vous avez une application exécutable*.

  Vous avez maintenant une application que vous pouvez exécuter sur votre appareil mobile. Votre code compilable a été compilé et s'exécute à la vitesse de l'éclair, tandis que le reste est converti et toujours interprété d'une manière plus efficace qui s'exécute à une vitesse proche de celle de l'éclair. :P

J'espère que cela a un sens maintenant, parce que c'est tout ce que j'ai ! :D