Appcelerator Titanium Mobile如何工作?

Titanium会获取您的javascript代码,对其进行分析和预处理,然后将其预编译为一组符号,这些符号是根据您的Titanium API应用程序的使用而解析的。从这个符号层次结构中,我们可以构建一个符号依赖矩阵,该矩阵映射到基础的钛库符号,以了解您的应用程序具体需要哪些API(以及相关的依赖项、框架等)。我用了一种半通用的方式来使用单词符号,因为基于语言,它有点不同。在iPhone中,符号映射到真正的C符号,最终映射到为ARM/i386体系结构编译的.o文件。对于Java来说,它或多或少是一个.class文件等。一旦前端可以理解你的依赖矩阵,那么我们调用SDK编译器(即GCC for iPhone,Android的Java),然后将你的应用程序编译成最终的本地二进制文件。

因此,一个简单的思考方法是,您的JS代码几乎是一对一地编译成本地的代表性符号。仍然有一个解释器在解释模式下运行,否则像动态代码这样的东西将无法工作。但是,它速度更快,更紧凑,而且尽可能接近纯本地映射。

很明显,我们仍有足够的空间来改进这一点,并继续努力。到目前为止,在我们最新的1.0测试中,它几乎无法与同一个Objective-C直接代码区分开来(因为在大多数情况下,它都是精确映射到这个代码上的)。然而,从compsci的观点来看,我们现在可以开始优化人类真正不容易做到的事情——就像GCC编译器今天已经做的那样。

正如Jhaynie所说,应用程序被编译成本地代码,但是仍然有一个解释器可以运行一些JavaScript,这使得应用程序非常动态。

appcelerator titanium

如果我打包我的简单的示例代码,我会得到一个大约80MB的gzip归档文件(原始代码~1KB)。在这个包中,您可以找到我的源HTML和JS文件。 包中还提供了许多库(例如SSL)(因为您可以在这个框架中对很多东西进行低级访问)。

我认为他们会把你的代码和一些解释器软件和库放在一起。 在我的例子中,我将HTML和JS代码打包到一个只显示我的站点的小浏览器旁边。

不管怎样,只要代码以同样的方式在每个受支持的系统上工作,这是件好事。