Appcelerator Titanium Mobileはどのように機能するのですか？

質問

Titanium Mobile 1.0を使ってiPhoneアプリを構築していますが、iPhoneネイティブのバイナリにコンパイルされることがわかります。 これはどのように機能するのでしょうか？ 280 NorthのObjective-JやCappuccinoのようなスーパーセット言語がなければ、JavaScriptコードを解析してObjective-Cに直接翻訳するには、多くの重労働が必要になるように思われます。

どのように解決するのか？

TitaniumはあなたのJavascriptコードを取り、それを分析し、前処理し、そしてあなたのアプリケーションのTitanium APIの使用に基づいて解決されるシンボルのセットにそれをプリコンパイルします。 このシンボル階層から、アプリケーションに必要なAPI（および関連する依存関係、フレームワークなど）を理解するために、基礎となるTitaniumライブラリのシンボルにマッピングするシンボル依存マトリックスを構築することができます。 シンボルという言葉は、言語によって少し異なるので、私は半官半民で使っています。 iPhoneの場合、シンボルは、最終的にARM/i386アーキテクチャ用にコンパイルされた.oファイルにマップされる真のCシンボルにマップされます。 Javaでは、まあ、多かれ少なかれ、.classファイルなどです。 フロントエンドが依存関係マトリックスを理解できたら、次に SDK コンパイラー (たとえば、iPhone 用の GCC、Android 用の Java) を呼び出して、アプリケーションを最終的なネイティブ バイナリにコンパイルします。

つまり、単純に考えると、JS コードは、ネイティブランドの代表的なシンボルにほぼ 1 対 1 でコンパイルされます。 解釈モードではまだインタプリタが動作しており、そうでなければ動的コードのようなものは動作しないでしょう。しかし、はるかに速く、はるかにコンパクトで、純粋なネイティブ マッピングに限りなく近いものです。

私たちは明らかにまだこれを改善する余地をたくさん持っており、それに取り組んでいます。 これまでのところ、最新の 1.0 テストでは、同じ objective-c 直接コードとほとんど区別がつきません (ほとんどの場合、正確にマッピングされるからです)。 CompSci の観点からは、人間が本当に簡単にできなかったことを最適化し始めることができます - 今日 GCC コンパイラーがすでに行っているのと同じように。