Titanium берет ваш код Javascript, анализирует и предварительно обрабатывает его, а затем предварительно компилирует его в набор символов, которые разрешаются на основе ваших приложений, использующих API-интерфейсы Titanium. Из этой иерархии символов мы можем построить матрицу зависимостей символов, которая сопоставляется с символами библиотеки Titanium, чтобы понять, какие API (и связанные с ними зависимости, платформы и т. Д.) Конкретно нужны вашему приложению. Я использую слово «слово» в полуобобщенном виде, поскольку оно немного отличается в зависимости от языка. В iPhone этот символ отображается на настоящий символ C, который в конечном итоге отображается на скомпилированный файл .o, скомпилированный для архитектур ARM / i386. Что касается Java, то это более или менее файл .class и т. Д. После того, как внешний интерфейс сможет понять вашу матрицу зависимостей, мы затем вызываем компилятор SDK (т. Е. GCC для iPhone, Java для Android), чтобы затем скомпилировать ваше приложение в финальный родной двоичный файл
Итак, простой способ думать об этом - это то, что ваш JS-код скомпилирован почти один в один в репрезентативные символы на родной земле. По-прежнему работает интерпретатор в интерпретируемом режиме, иначе такие вещи, как динамический код, не будут работать. Тем не менее, он намного быстрее, гораздо более компактен и настолько близок к чистому нативному отображению, насколько это возможно.
У нас, очевидно, еще есть много возможностей, чтобы улучшить это и работать над этим. До сих пор в нашем последнем тестировании 1.0 он почти не отличался от того же прямого кода Objective-C (поскольку в большинстве случаев он точно соответствует этому). Однако с точки зрения CompSci мы можем теперь приступить к оптимизации вещей, которые на самом деле не мог бы сделать человек, как это делает сегодня компилятор GCC.