Qu'advient-il du code JavaScript après application est compilé en utilisant Titanium mobile
https://stackoverflow.com/questions/4217551
-
26-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
J'ai installé Titanium Appcelerator et construit l'exemple d'application "KitchenSink".
Tout fonctionne bien, je me demande d'où vient le code javascript se termine dans une application construite.
Je grep-ed du projet Xcode et aussi l'application de résultat que je l'ai trouvé dans Library/Application Support/iPhone Simulator/....KitchenSink.app, mais je ne peux pas trouver des noms de fonctions à partir de fichiers .js, pas même les textes de chaîne utilisés dans l'application.
information le plus proche, j'ai trouvé une réponse ici: COMMEnT Appcelerator Titanium travail mobile mais je ne comprends pas clairement comment le processus fonctionne.
Le code javascript compilé en un code binaire (quel compilateur est utilisé alors?), Ou est-il simplement transformé en quelque chose de particulier format de données et interprétées dans une application en cours d'exécution?
Mise à jour:
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 ne regardais pas dans app.apk avant, tout ce que je ne voyais que ces fichiers de classe correspondant à chacun des fichiers javascript. Par conséquent, je suppose que le javascript Android est en cours de compilation pour la JVM. Pourquoi ne peuvent-ils se trouvent dans app.apk?
La solution
Le titane est pas une enveloppe autour d'une vue Web comme indiqué précédemment (mais qui explique avec précision comment fonctionne Phonegap). La réponse de Jeff, liée à la question, est une explication techniquement correcte de la façon dont fonctionne le titane, mais voici la meilleure version que je l'ai entendu jusqu'à présent, Marshall Culpepper :
Il est vrai que titane mobile utilisé WebView (dans Android et iOS) dans les pré-1.0 jours. Toutefois, cela ne l'est plus et n'a pas été depuis notre version 1.0 est Mars de 2010.
Depuis 1.0, nous avons livré deux runtimes Javascript séparés avec nos applications, et nous courons le code Javascript directement sans WebView. Votre application du début à la fin est maintenant contrôlé par JS, et nous fournissons un ensemble complet d'API natives qui permettent cela. Tout de contrôles d'interface utilisateur (oui, y compris WebView), les API de base telles que les réseaux, systèmes de fichiers, base de données, tout le chemin à des choses spécifiques comme OS JS Activités Android. Sur le plan d'exécution JS, nous expédions une version fourchue de JavaScriptCore de WebKit dans 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 plate-forme, mais en général, il se brise comme ceci:
- Source est analysé de manière statique pour trouver des références aux modules titane
- Localisation (chaînes de strings.xml), les métadonnées de l'application (de tiapp.xml), et la densité des images spécifiques génèrent tous les analogues de la plate-forme spécifiques.
- Dans iOS:
- Un projet XCode / configuration est généré
- JS Source est base64'd et inline comme une variable dans un fichier C généré
- xcodebuild est utilisé pour générer les binaires finaux
- des profils d'approvisionnement, clés de signature, etc sont appliquées
- iTunes et une autre colle sont utilisés pour envoyer l'IPA à votre appareil iOS
- Dans Android:
- Un projet Applications / Eclipse est généré
- En mode "développement", la source JS est emballé comme des actifs APK
- En mode « Distribution » (production), lorsque vous êtes prêt à expédier l'application, nous compilons la JS à bytecode Java en utilisant le compilateur Rhino JSC. Vous pouvez également activer ce en mode de développement en mettant « 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 SDK Android sont utilisés pour construire et générer l'APK finale
- ADB et keytool sont utilisés pour pousser le APK hors de l'émulateur et / ou le dispositif
Il y a beaucoup plus de détails que je pouvais plonger dans spécifiquement sur chacun de ces points, mais le point que je voulais conduire à la maison est que nous utilisons plus WebView que notre moteur Javascript. Vous pouvez mais encore intégrer WebViews, et nous fournissons une intégration simple qui vous permet d'appeler les API de titane à partir d'un WebView intégré.
Autres conseils
Qu'est-ce que jhaynie dit dans votre question liée est que Titanium interprète votre code JS et le convertit en quelque chose qui est presque identique à Objective-C.
Dans une application web, le navigateur lit et interprète votre Javascript et fonctionne associé du code natif (peut-être C ++) en interne. Par exemple, le navigateur pourrait dire: « Ce script est en cours d'exécution getElementById(), donc je vais courir mes propres méthodes C ++ pour y parvenir. » Qu'est-ce que Titanium fait est de déterminer ce que JS-> C ++ (ou dans ce cas, JS-> Objective-C) serait à l'avance, et la compilation que. Il laisse encore un interprète ouvert si nécessaire pour votre code dynamique, mais il permet de convertir et compiler ce qu'elle 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ée à un interprète est toujours traité et converti, et vos symboles change (par exemple un appel à myTestFunction() peut être converti en A() ou 10001101001101: P).
habituelle utilisation de Javascript est de l'avoir interprété en temps réel par un programme en cours d'exécution. Ce n'est pas ce qui se passe ici, et qui est la raison pour laquelle vous ne pouvez pas voir aucune trace de votre script.
Titanium l'exécute d'interprétation de votre script comme tout autre programme ferait (comme un navigateur Web). Il figure sur quelles dépendances votre script a sur l'API de titane et ensembles ce genre de choses vers le haut. Il mappe ensuite vos symboles directement dans (dans le cas de l'iPhone) Objective-C.
Un programme serait généralement lu dans votre script (qui est simplement une chaîne), interprète et exécute le code C pour accomplir ce que votre script demandé. Le titane ne présente avant-main pour comprendre ce que le code C doit être exécuté, et effectue la conversion à l'avance.
Sur la base de l'interprétation de votre code et ses dépendances sur l'API titane, figure ce code peut être compilé directement, et ce qui ne doit pas être compilé afin de permettre qu'ils soient pleins dynamique de Javascript. Je ne sais pas comment il choisit ce qui fonctionne et ne soit pas compilé, mais vous pouvez vérifier la source si vous voulez savoir que plus de détails.
Le code qui doit encore être Interpretation d'(à gauche comme un script) est toujours transformé en symboles qui donnent lieu à une cartographie plus efficace du code natif. Il est donc encore un script interprété, mais cela ne veut pas dire qu'il est toujours Javascript. Cela signifie que ces parties de votre script encore courir plus vite que d'habitude. Javascript
Pour iPhone, le compilable C est compilé avec GCC pour créer un fichier binaire natif.
Maintenant, vous avez une application que vous pouvez exécuter sur votre appareil mobile. Votre code compilable a été compilé et fonctionne à une vitesse fulgurante, alors que le reste est converti et toujours interprété d'une manière plus efficace, qui fonctionne à une vitesse proche de la foudre. : P
J'espère que cela est logique maintenant, car il est tout ce que j'ai! : D
