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

所以，一个简单的思考方式是，你的JS代码几乎是一对一的编译成本土的代表符号。仍然有一个解释器在解释模式下运行，否则动态代码之类的东西将无法工作。然而，它更快，更紧凑，并且尽可能接近纯原生映射。

显然，我们仍有足够的空间来改进和努力。到目前为止，在我们最新的 1.0 测试中，它与相同的 Objective-c 直接代码几乎没有区别（因为在大多数情况下它完全映射到那个）。然而，从 CompSci 的角度来看，我们现在可以开始优化人类确实不容易做到的事情——就像今天的 GCC 编译器已经做到的那样。

就像 jhaynie 所说，应用程序被编译成本地代码，但仍然有一个解释器来运行一些 javascript，这使得应用程序非常动态。

appcelerator 钛

如果我打包我的简单代码，我会得到一个 ~80MB 的 gzip 存档（原始代码 ~1kB）。在包中 - 除其他外 - 您可以找到我的源 html 和 js 文件。包中还附带了很多库（例如 ssl）（因为您可以对这个框架内的很多东西进行低级访问）。

我认为他们会使用您的代码并封装某种解释器软件和库。在我的情况下，就像我将我的 html 和 js 代码放在一个只显示我的网站的微型浏览器旁边一样。

然而，只要代码以相同的方式在每个受支持的系统上工作，它就是一件好事。