Appcelerator Titanium Mobile如何工作？ [英] How Does Appcelerator Titanium Mobile Work?

问题描述

我正在使用Titanium Mobile 1.0构建iPhone应用程序，我发现它可以编译为本机iPhone二进制文件。这是如何运作的？似乎需要花费大量精力来分析JavaScript代码并直接翻译成Objective-C，而不需要像280 North的Objective-J和Cappuccino这样的超集语言。

I'm working on building an iPhone app with Titanium Mobile 1.0 and I see that it compiles down to a native iPhone binary. How does this work? Seems like it would take a lot of heavy lifting to analyze the JavaScript code and do a direct translation into Objective-C without having a superset language like 280 North's Objective-J and Cappuccino.

推荐答案

Titanium接受您的Javascript代码，对其进行分析和预处理，然后将其预编译为一组符号，这些符号将根据您对Titanium API的应用程序使用情况进行解析。从这个符号层次结构，我们可以构建一个符号依赖矩阵，映射到底层的Titanium库符号，以了解您的应用程序需要哪些API（以及相关的依赖项，框架等）。我以半通用方式使用单词符号，因为它根据语言略有不同。在iPhone中，符号映射到真正的C符号，该符号最终映射到已为ARM / i386体系结构编译的已编译.o文件。对于Java，它或多或少是.class文件等。一旦前端可以理解你的依赖矩阵，我们然后调用SDK编译器（即iPhone的GCC，Android的Java）然后将你的应用程序编译到最后原生二进制。

Titanium takes your Javascript code, analyzes and preprocesses it and then pre-compiles it into a set of symbols that are resolved based on your applications uses of Titanium APIs. From this symbol hierarchy we can build a symbol dependency matrix that maps to the underlying Titanium library symbols to understand which APIs (and related dependencies, frameworks, etc) specifically your app needs. I'm using the word symbol in a semi-generic way since it's a little different based on the language. In iPhone, the symbol maps to a true C symbol that ultimately maps to a compiled .o file that has been compiled for ARM/i386 architectures. For Java, well, it's more or less a .class file, etc. Once the front end can understand your dependency matrix, we then invoke the SDK compiler (i.e. GCC for iPhone, Java for Android) to then compile your application into the final native binary.

因此，考虑它的一个简单方法是将您的JS代码几乎一对一地编译到nativeland中的代表符号中。还有一个解释器在解释模式下运行，否则像动态代码这样的东西就行不通。然而，它更快，更紧凑，并且接近纯粹的原生映射，你可以得到。

So, a simple way to think about it is that your JS code is compiled almost one to one into the representative symbols in nativeland. There's still an interpreter running in interpreted mode otherwise things like dynamic code wouldn't work. However, its much faster, much more compact and it's about as close to pure native mapping as you can get.

我们显然仍有足够的空间来改善这一点并继续努力。到目前为止，在我们最新的1.0测试中，它几乎与同一个目标-c直接代码无法区分（因为在大多数情况下，它完全映射到那个）。从CompSci的角度来看，我们现在可以开始优化人类真正无法轻易做到的事情 - 就像今天的GCC编译器一样。

We're obviously still got plenty of room to improve this and working on that. So far in our latest 1.0 testing, it's almost indistinguishable from the same objective-c direct code (since in most cases it's exactly mapped to that). From a CompSci standpoint, we can now however start to optimize things that a human really couldn't easily do that - much like the GCC compiler already does today.

这篇关于Appcelerator Titanium Mobile如何工作？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！