Co dzieje się z kodem JavaScript po kompilacji aplikacji za pomocą Titanium Mobile

Question

Zainstalowałem Titanium z aplikacji Appcelerator i zbudowałem przykładową aplikację "KitchenSink".

Wszystko działa dobrze, po prostu zastanawiam się, gdzie znajduje się kod javascript w zbudowanej aplikacji.

I grep-ed projektu Xcode, a także aplikacji wyników, jak znalazłem go w Library/Application Support/iPhone Simulator/....KitchenSink.app, ale nie mogę znaleźć żadnych nazw funkcji z .js plików, nawet tekstów ciąg używanych w aplikacji.

Najbliższa informacja, którą znalazłem, to odpowiedź tutaj: How Does Appcelerator Titanium Mobile Work?, ale nie rozumiem jasno, w jaki sposób działa ten proces.

Czy kod javascript jest kompilowany w kod binarny (który to kompilator jest używany?), Czy jest po prostu przekształcany w specjalnym formacie danych i interpretowany w działającej aplikacji?

Aktualizacja:

To co widzę w katalogu/Android kompilacji z 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 

I nie wyglądało na app.apk zanim mógłby widzę byłeś te pliki klas odpowiadające każdemu z plików javascript. Dlatego założyłem, że w systemie Android javascript jest kompilowany dla JVM. Dlaczego nie można ich znaleźć w app.apk?

Answer 1

Tytan nie jest opakowaniem w widoku sieciowym, jak podano wcześniej (chociaż to dokładnie wyjaśnia działanie Phonegap). Odpowiedź Jeffa, powiązana z pytaniem, jest technicznie poprawnym wyjaśnieniem tego, jak działa Titanium, ale oto najlepsza wersja, jaką do tej pory słyszałem, od Marshall Culpepper:

To prawda, że ​​Titanium Mobile używał WebView (zarówno na Androidzie jak i iOS) w okresie poprzedzającym 1.0 dni. Jednak nie jest to już prawdą i nie było od 1,0 nasza wersja jest marzec 2010.

Od 1,0, my wysyłają dwa oddzielne czasy pracy JavaScript z naszych aplikacji i prowadzimy kodu JavaScript bezpośrednio bez WebView. Twoja cała aplikacja od początku do końca jest teraz kontrolowana przez JS, a my zapewniamy pełny zestaw Natywnych API, które to umożliwiają. Wszystko od widżetów interfejsu użytkownika (tak, w tym WebView), podstawowych interfejsów API, takich jak praca w sieci, system plików, baza danych, aż po specyficzne dla systemu operacyjnego rzeczy, takie jak działania JS w systemie Android. W środowisku uruchomieniowym JS dostarczamy rozproszoną wersję aplikacji JavaScriptCore WebKit w systemie iOS oraz migawkę Rhino 1.7 R3 CVS na Androida. Co tak naprawdę zrobić z javascript źródła jest zależne od platformy, ale ogólnie to zrywa tak:

• Źródło statycznie analizowane znaleźć odnośniki do modułów Titanium
• ciągi Lokalizacja (strings.xml), app metadane (tiapp.xml) i obrazy o określonej gęstości tworzą wszystkie analogi specyficzne dla platformy.
• w IOS:
  • XCode projektu/konfiguracji jest generowany
  • JS źródła jest base64'd i wstawiane jako zmienną w wygenerowanego pliku C
  • xcodebuild służy do wytwarzania końcowych binarne
  • profile rezerw, podpisywanie kluczy itp stosuje
  • iTunes oraz niektórych innych kleju służą do wysyłania IPA na swoim urządzeniu z iOS
• W Androidzie:
  projekt
  • z Androidem/Eclipse jest generowany
  • w trybie „rozwoju”, źródło JS jest pakowany jako aktywa APK
  • W trybie „dystrybucja” (produkcji), gdy jesteś gotowy aby wysłać aplikację, kompilujemy kod JS do kodu Java za pomocą kompilatora JS Rhino. Możesz włączyć to również w trybie programowania, ustawiając "ti.android.compilejs" na "true" w tiapp.xml, zobacz: http://developer.appcelerator.com/question/100201/enable-android-byte-code-compile
  • Narzędzia do tworzenia dokumentów i narzędzi Androida SDK służą do budowania i generowania końcowego pliku APK
  • adb i keytool służą do pchania APK się do emulatora i/lub urządzenie

Istnieje wiele innych szczegółów, które mógłbym Zanurz się w szczególności na każdy z tych punktów, ale chodzi mi chcieliśmy pojechać do domu, ponieważ nie używamy już WebView jako naszego silnika Javascript. You can nadal jednak osadzić WebViews, a my zapewniamy prostą integrację, która pozwala na wywoływanie Titanium API z wbudowanego WebView.

Answer 2

Co jhaynie mówi w twoim połączonym pytaniu, to że Titanium interpretuje twój kod JS i przekształca go w coś, co jest prawie identyczne z Objective-C.

W aplikacji internetowej przeglądarka odczytuje i interpretuje JavaScript i uruchamia wewnętrzny kod źródłowy (być może C++) wewnętrznie. Na przykład przeglądarka może powiedzieć: "Ten skrypt wykonuje getElementById(), więc poprowadzę moje własne metody C++, aby to osiągnąć." To, co robi Titanium, to ustalenie, co to JS-> C++ (lub w tym przypadku JS-> Objective-C) będzie z góry i skompilowanie tego. W razie potrzeby pozostawia on otwarty interpreter dla kodu dynamicznego, ale będzie on konwertował i kompilował, co może.

Oznacza to, że nie znajdziesz niczego, co wygląda podobnie do tego, co pierwotnie napisałeś w swoim skrypcie. Wszystko, co musi zostać pozostawione interpreterowi, jest nadal przetwarzane i konwertowane, a symbole będą się zmieniać (np. Połączenie z myTestFunction() może zostać przekonwertowane na A() lub 10001101001101: P).

---

zwykle wykorzystanie JavaScript, aby został on interpretowany w czasie rzeczywistym przez program. To nie jest to, co się tutaj dzieje, i dlatego nie widać żadnego śladu w twoim skrypcie.

Javascript jest wstępnie przetwarzane

tytanu wykonuje interpretację skryptu jak każdy inny program zrobi (takich jak przeglądarka WWW). Dowiesz się, jakie zależności ma twój skrypt od Titanium API i ustawia te rzeczy. Następnie mapuje symbole bezpośrednio do (w przypadku iPhone'a) Objective-C.
Program zazwyczaj byłby odczytywany w twoim skrypcie (który jest po prostu ciągiem), interpretuje go i uruchamia kod C, aby osiągnąć to, o co prosił twój skrypt.Titanium robi to z wyprzedzeniem, aby dowiedzieć się, jaki kod C powinien zostać uruchomiony, i dokonuje konwersji z wyprzedzeniem.

kod jest kompilowany w miarę możliwości

podstawie interpretacji kodu i jego zależności na API Titanium, Titanium domyśla się, jaki kod może być bezpośrednio skompilowany, a co nie może być zestawiane w celu aby umożliwić im pełną dynamikę JavaScript. Nie wiem, w jaki sposób wybiera to, co robi i nie jest kompilowane, ale możesz sprawdzić źródło, jeśli chcesz poznać tak wiele szczegółów.
Kod, który nadal musi być interpretowany (pozostawiony jako skrypt), jest nadal konwertowany na symbole, które powodują bardziej wydajne odwzorowywanie na kod natywny. Więc nadal jest to interpretowany skrypt, ale to nie znaczy, że wciąż jest Javascriptem. Oznacza to, że te części skryptu będą nadal działać szybciej niż zwykłe Javascript.

Dla iPhone'a, kompilowany C jest skompilowany z GCC, aby utworzyć natywny plik binarny.

Masz runnable aplikację *

Teraz masz app, który można uruchomić na swoim urządzeniu mobilnym. Twój kompilowalny kod został skompilowany i działa z prędkością błyskawicy, podczas gdy reszta jest przekształcana i nadal interpretowana w bardziej efektywny sposób, który działa z prędkością bliską prędkości błyskawicy. : P

Mam nadzieję, że teraz ma to sens, ponieważ to wszystko, co mam! : D