转载自 http://www.appcelerator.com/blog/2012/05/comparing-titanium-and-phonegap/
As we mentioned previously, a PhoneGap application is a “native-wrapped” web application. Let’s explore how the web application is “wrapped”.
Many native mobile development SDKs provide a web browser widget (a “web view”) as a part of their UI framework (iOS and Android, for example). In purely native applications, web view controls are used to display HTML content either from a remote server, or local HTML packaged along with the native application in some way. The native “wrapper” application generated by PhoneGap loads the end developer’s HTML pages into one of these web view controls, and displays the resulting HTML as the UI when the application is launched.
If JavaScript files are included in a page loaded by a web view, this code is evaluated on the page as normal. However, the native application which creates the web view is able to (in different ways, depending on the platform) asynchronously communicate with JavaScript code running inside of the web view. This technology is usually referred to as “the bridge” in the context of PhoneGap architecture – the “bridge” means something slightly different in Titanium, as we will see later.
PhoneGap takes advantage of this to create a JavaScript API inside a web view which is able to send messages to and receive messages from native code in the wrapper application asynchronously. The way the bridge layer is implemented is different per platform, but on iOS, when you call for a list of contacts, your native method invocation goes into a queue of requests to be sent over the bridge. PhoneGap will then create an iframe which loads a URI scheme (“gap://”) that the native app is configured to handle, at which point all the queued commands will be executed. Communication back into the web view is done by evaluating a string of JavaScript in the context of the web view from native code.
There is much more to PhoneGap than that, but the messaging from web view to native code via the bridge implementation is the key piece of technology which allows local web applications to call native code.
There’s quite a bit happening behind the scenes in a Titanium application. But basically, at runtime, your application consists of three major components – your JavaScript source code (inlined into a Java or Objective-C file and compiled as an encoded string), the platform-specific implementation of the Titanium API in the native programming language, and a JavaScript interpreter that will be used to evaluate your code at runtime (V8 (default) or Rhino for Android, orJavaScriptCore for iOS). Except in the browser, of course, where the built-in JavaScript engine will be used.
When your application is launched, a JavaScript execution environment is created in native code, and your application source code is evaluated. Injected into the JavaScript runtime environment of your application is what we call “proxy” objects – basically, a JavaScript object which has a paired object in native code. Colloquially we will often refer to “JavaScript land” and “native land” in a Titanium application, as they are kind of parallel universes to one another. The proxy object exists both in JavaScript land and native land, and serves as the “bridge” between the two.
In your JavaScript code, when you call a function on the global Titanium
or Ti
object, such as var b = Ti.UI.createButton({title:'Poke Me'});
, that will invoke a native method that will create a native UI object, and create a “proxy” object (b
) which exposes properties and methods on the underlying native UI object to JavaScript.
UI components (view proxies) can be arranged hierarchically to create complex user interfaces. Proxy objects which represent an interface to non-visual APIs (like filesystem I/O or database access) execute in native code, and synchronously (or asynchronously for APIs like network access) return a result to JavaScript.
Hopefully this helps directly address two common misconceptions about Titanium – at no point does Titanium require the use of a web view component. The developer can create a web view as a native UI widget, but the web view is not used to evaluate Titanium source code. Nor is JavaScript code cross-compiled to Objective-C or Java in Titanium. Your JavaScript source is evaluated at runtime.