Titanium Mobile を使用してアプリをコンパイルした後、JavaScript コードはどうなるか
-
26-09-2019 - |
質問
appcelerator から Titanium をインストールし、「KitchenSink」サンプル アプリケーションを構築しました。
すべて正常に動作していますが、ビルドされたアプリの中で JavaScript コードがどこに配置されるのか疑問に思っています。
Xcodeプロジェクトと結果のアプリケーションをgrepしました。 Library/Application Support/iPhone Simulator/....KitchenSink.app
, 、しかし、から関数名が見つかりません .js
ファイルだけでなく、アプリケーション内で使用される文字列テキストも含まれません。
私が見つけた最も近い情報はここにあります: Appcelerator Titanium Mobile はどのように機能しますか? しかし、そのプロセスがどのように機能するのか明確に理解できません。
JavaScript コードはバイナリ コードにコンパイルされていますか (その場合、どのコンパイラが使用されますか?)、それとも特別なデータ形式に変換され、実行中のアプリケーションで解釈されるだけですか?
アップデート:
これは、KitchenSink の build/android ディレクトリにあるものです。
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
以前は app.apk を調べていませんでした。確認できたのは、各 JavaScript ファイルに対応するこれらのクラス ファイルだけでした。したがって、Android では JavaScript が JVM 用にコンパイルされていると仮定しました。これらが app.apk で見つからないのはなぜですか?
解決
前に述べたように、Titanium は Web ビューのラッパーではありません (ただし、これは Phonegap がどのように機能するかを正確に説明しています)。質問にリンクされているジェフの答えは、Titanium がどのように機能するかに関する技術的に正しい説明ですが、これは私がこれまでに聞いた中で最高のバージョンです。 マーシャル・カルペッパー:
Titanium Mobile が 1.0 以前の時代に WebView (Android と iOS の両方で) を使用していたのは事実です。しかし、これはもはや真実ではなく、2010 年 3 月の 1.0 リリース以来そうではありません。
1.0 以降、アプリには 2 つの別々の Javascript ランタイムが同梱されており、JavaScript コードを直接実行しています。 それなし WebView。アプリ全体が最初から最後まで JS によって制御されるようになり、これを可能にするネイティブ API の包括的なセットが提供されます。UI ウィジェット (はい、WebView を含む)、ネットワーキング、ファイルシステム、データベースなどのコア API、Android の JS アクティビティなどの OS 固有のものに至るまで、あらゆるものが含まれます。JS ランタイムの面では、iOS 向け WebKit の JavaScriptCore のフォーク バージョンと Android 向け Rhino 1.7 R3 CVS のスナップショットを出荷しています。JavaScript ソースで実際に何を行うかはプラットフォームによって異なりますが、一般的には次のように分割されます。
- ソースは静的に分析され、Titanium モジュールへの参照が検出されます。
- ローカリゼーション文字列 (strings.xml)、アプリ メタデータ (tiapp.xml)、および密度固有の画像はすべて、プラットフォーム固有の類似物を生成します。
- iOSの場合:
- XCodeプロジェクト/構成が生成されます
- JS ソースは Base64 化され、生成された C ファイルに変数としてインライン化されます。
- xcodebuild は最終バイナリを生成するために使用されます
- プロビジョニングプロファイル、署名キーなどが適用されます
- IPA を iOS デバイスに送信するには、iTunes およびその他の接着剤が使用されます。
- Android の場合:
- Android/Eclipseプロジェクトが生成される
- 「開発」モードでは、JS ソースが APK アセットとしてパッケージ化されます
- 「配布」(本番) モードでは、アプリを出荷する準備ができたら、Rhino JSC コンパイラーを使用して JS を Java バイトコードにコンパイルします。tiapp.xml で「ti.android.compilejs」を「true」に設定することで、開発モード中にこれを有効にすることもできます。以下を参照してください。 http://developer.appcelerator.com/question/100201/enable-android-byte-code-compile
- dex、aapt、およびその他の Android SDK ツールは、最終的な APK のビルドと生成に使用されます
- adb と keytool は、APK をエミュレータやデバイスにプッシュするために使用されます
これらの各点について、具体的に掘り下げて説明できる詳細はたくさんありますが、私が強調したい点は、Javascript エンジンとして WebView を使用しなくなったということです。あなた できる ただし、WebView は依然として埋め込まれており、埋め込まれた WebView から Titanium API を呼び出すことができるいくつかの簡単な統合が提供されています。
他のヒント
リンクされた質問で jhaynie が言っていることは、Titanium が JS コードを解釈し、それを Objective-C とほぼ同じものに変換するということです。
Web アプリケーションでは、ブラウザーが Javascript を読み取って解釈し、関連するネイティブ コード (おそらく C++) を内部で実行します。たとえば、ブラウザは「このスクリプトは実行されています」と言うかもしれません。 getElementById()
, なので、それを達成するために独自の C++ メソッドを実行します。」 Titanium が行っていることは、JS->C++ (またはこの場合は JS->Objective-C) がどのようなものになるかを事前に把握し、それをコンパイルすることです。動的コードに必要な場合はインタプリタを開いたままにしますが、可能なものは変換してコンパイルします。
つまり、最初にスクリプトに書いたものと似たものは見つからないということです。インタプリタに任せなければならないものはすべて処理および変換され、シンボルは変更されます (例:への電話 myTestFunction()
に変換される可能性があります A()
, 、 または 10001101001101
:P)。
の いつもの Javascript の使用は、実行中のプログラムによってリアルタイムに解釈されるようにすることです。ここで起こっていることはそうではありません。それが、スクリプトの痕跡がまったく表示されない理由です。
Titanium は、他のプログラム (Web ブラウザなど) と同じようにスクリプトの解釈を実行します。スクリプトが Titanium API に対してどのような依存関係を持っているかを把握し、それを設定します。次に、シンボルを (iPhone の場合) Objective-C に直接マッピングします。
通常、プログラムはスクリプト (単なる文字列) を読み取り、それを解釈し、C コードを実行して、スクリプトが要求したことを実行します。Titanium はこれを事前に実行して、どの C コードを実行すべきかを判断し、事前に変換を行います。
Titanium は、コードの解釈と Titanium API への依存関係に基づいて、JavaScript の完全なダイナミクスを可能にするために、どのコードが直接コンパイル可能で、どのコードがコンパイルできないかを判断します。コンパイルされるものとコンパイルされないものをどのように選択するのかはわかりませんが、詳細を知りたい場合はソースをチェックしてください。
引き続き解釈する必要がある (スクリプトとして残される) コードは、ネイティブ コードへのマッピングがより効率的に行われるシンボルに変換されます。したがって、これはまだ解釈されたスクリプトですが、それはまだ Javascript であるという意味ではありません。これは、スクリプトのこれらの部分が通常の JavaScript よりも高速に実行されることを意味します。
iPhone の場合、コンパイル可能な C は GCC でコンパイルされ、ネイティブ バイナリが作成されます。
これで、モバイルデバイス上で実行できるアプリが完成しました。コンパイル可能なコードはコンパイルされ、超高速で実行されますが、残りのコードは変換され、さらに効率的な方法で解釈され、超高速に近い速度で実行されます。:P
私が持っているのはこれだけなので、これで理解できるといいのですが。:D