听AppceleratorCEO谈Titanium如何架构

在stackoverflow上有人问到Titanium Mobile是如何运行的，AppceleratorCEO Jeff Haynie 给出了他的回答，这里给大家转过来看看！

[url=http://stackoverflow.com/questions/2444001/how-does-appcelerator-titanium-mobile-work]How Does Appcelerator Titanium Mobile Work?[/url]

[size=large][b]Question：[/b][/size]

[quote]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.[/quote]

[size=large][b]Haynie's Answer:[/b][/size]

[quote]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.

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.

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.[/quote]

[url=http://stackoverflow.com/questions/4217551/what-happens-to-javascript-code-after-app-is-compiled-using-titanium-mobile]http://stackoverflow.com/questions/4217551/what-happens-to-javascript-code-after-app-is-compiled-using-titanium-mobile[/url]

[size=large][b]Kevin Whinnery's Answer:[/b][/size]

[quote]Titanium is not a wrapper around a web view as stated before (though that accurately explains how Phonegap works). Jeff's answer, linked in the question, is a technically correct explanation of how Titanium works, but here's the best version I've heard so far, from Marshall Culpepper:

It's true that Titanium Mobile used the WebView (in both Android and iOS) in the pre-1.0 days. However, this is no longer true and hasn't been since our 1.0 release is March 2010.

Since 1.0, we've shipped two separate Javascript runtimes with our apps, and we are running the Javascript code directly without a WebView. Your entire app from start to finish is now controlled by JS, and we provide a comprehensive set of Native APIs that enable this. Everything from UI widgets (yes, including WebView), Core APIs like Networking, Filesystem, Database, all the way to OS-specific things like JS Activities in Android. On the JS runtime front, we're shipping a forked version of WebKit's JavaScriptCore in iOS and a snapshot of Rhino 1.7 R3 CVS for Android. What we actually do with your javascript source is dependent on the platform, but generally it breaks up like this:

Source is statically analyzed to find references to Titanium modules

Localization strings (strings.xml), App metadata (tiapp.xml), and density specific images all generate platform specific analogs.

In iOS:

An XCode project / configuration is generated

JS Source is base64'd and inlined as a variable into a generated C file

xcodebuild is used to generate the final binaries

provisioning profiles, signing keys etc are applied

iTunes and some other glue are used to send the IPA to your iOS device

In Android:

An Android / Eclipse project is generated

In "Development" mode, JS source is packaged as APK assets

In "Distribution" (production) mode, when you're ready to ship the app, we compile the JS to Java bytecode using the Rhino JSC compiler. You can also enable this during development mode by setting "ti.android.compilejs" to "true" in tiapp.xml, see: http://developer.appcelerator.com/question/100201/enable-android-byte-code-compile

dex, aapt, and other Android SDK tools are used to build and generate the final APK

adb and keytool are used for pushing the APK out to the emulator and/or device

There are many more details that I could dive into specifically on each of these points, but the point I wanted to drive home is that we no longer use the WebView as our Javascript engine. You can however still embed WebViews, and we provide some simple integration that allows you to call Titanium APIs from an embedded WebView.

-Kevin Dev Relations Manager

[/quote]