Introduction
Add your content here.
Details
The three different methods for calling into Objective-C from Javascript have some significant performance implications.
Underlying Mechanisms
Native Obj-C bridge:
- Uses standard WebKit methods which are not yet documented/exposed in the iPhone 2.1 OS SDK
- Relies upon the native WebKit Objective-C / Javascript bridging capabilities
- (Presumably) allows reference counting between language domains, which is a huge win
- Can translate simple data types (NSString, NSNumber) and wraps others in WebScriptObject
- Allows synchronous and asynchronous operation
UIWebView URL loading hook:
- Relies only upon documented and iPhone-kosher UIWebView delegate and UIWebView methods
- Semantics of setting window.location are unclear, but no return value comes from a set of window.location
- Only allows data types which can be expressed as JSON (or other string form)
- Allows only asynchronous operation.
XMLHTTPRequest / Ajax:
- Relies upon documented and iPhone-kosher networking APIs
- Has a relatively large code footprint due to embedded HTTP server
- High latency, but better handling of large or binary data sets
- Only allows data types which can be expressed as JSON (or other string form)
- Could theoretically be used for distributed RPC between iPhones
- Allows both synchronous and asynchronous operation
Benchmarking Invocation Methods
All tests were performed with NSLog nullified to reduce overhead.
There's a much steeper performance curve on the Simulator than on actual hardware. However, it looks like at least a 4-5x overhead increase from the fastest method to the Ajax / XMLHTTPRequest method used by Nitrox.
Performance on first-gen iPhone Hardware, OS 2.1
| Method | Time | |:-------|:-----| | native Obj-C bridge | 10.26 ms | | URL loading hook | 16.92 ms | | XMLHTTPRequest / Ajax | 65.18 ms |
Performance on Macbook Pro, Simulator, OS 2.1
| Method | Time | |:-------|:-----| | native Obj-C bridge | 0.04 ms | | URL loading hook | 0.54 ms | | XMLHTTPRequest / Ajax | 2.16 ms |