Appcelerator 钛手机是如何工作的？

如果我将简单的示例代码打包，就会得到一个 ~ 80MB 的 gzip 归档文件(原始代码 ~ 1kB)。在这个包中，您可以找到我的源 html 和 js 文件。 包中还附带了很多库(例如 ssl)(因为您可以对该框架中的很多内容进行低级访问)。

我认为他们拿走你的代码，然后包装成某种解释软件和库。 在我的例子中，这就像是把 html 和 js 代码打包放在一个只显示我的站点的小浏览器旁边。

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

Titium 获取您的 Javascript 代码，对其进行分析和预处理，然后将其预编译为一组符号，这些符号根据您的应用程序使用 TitaniumAPI 的情况进行解析。从这个符号层次结构中，我们可以构建一个符号依赖矩阵，它映射到底层的钛库符号，以了解哪些 API (以及相关的依赖关系、框架等)特别是您的应用程序需要。我使用的单词符号在一个半泛型的方式，因为它有点不同的语言。在 iPhone 中，该符号映射到一个真正的 C 符号，最终映射到一个已编译的。已经为 ARM/i386架构编译的 o 文件。对于 Java 来说，它或多或少是一个。类别档案等。一旦前端能够理解您的依赖矩阵，我们就调用 SDK 编译器(例如，iPhone 的 GCC，Android 的 Java) ，然后将您的应用程序编译成最终的本机二进制文件。

所以，一种简单的思考方法是将您的 JS 代码几乎一对一地编译为 nativeland 中的代表符号。仍然有一个解释器在解释模式下运行，否则像动态代码这样的东西不会工作。然而，它的速度更快、更紧凑，而且它与纯本机映射非常接近。

我们显然还有很大的空间来改进这个和那个。到目前为止，在我们最新的1.0测试中，它几乎与相同的目标-c 直接代码没有什么区别(因为在大多数情况下，它都精确地映射到了 c 直接代码)。然而，从 CompSci 的观点来看，我们现在可以开始优化一些人类无法轻易做到的事情——就像 GCC 编译器今天已经做到的那样。

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

助推器钛合金