问题
Earlier this year I wrote an experimental PhoneGap plugin called WebGLGap. In theory it could enable WebGL support in PhoneGap apps by forwarding all the JS calls to the plugin code. Unfortunately I abandoned it because the bridge between Javascript and the plugin was a huge bottleneck: everything (including vertex data) was stringified in to a giant string, passed to the plugin, then parsed back to JSON to be read by the native plugin code. Obviously this made it pretty useless.
However I'm reading PhoneGap 2.2 has a new bridge, which can be over 10 times faster. How does it work exactly? Does it avoid stringifying? If the bridge is efficient enough, it may well be worth taking a new look at WebGLGap.
回答1:
It's still all strings. The difference is that the default is now XHR_WITH_PAYLOAD, which uses an XMLHttpRequest with parameters in the headers rather than XHR_NO_PAYLOAD, which uses the XHR to trigger reading a queue, or IFRAME_NAV, which was one of the faster methods available but conflicts with touch scrolling in iOS 5 due to a safari bug.
XHR_WITH_PAYLOAD was set as the default in 2.2 after a bug with handling rapid requests was fixed ( https://issues.apache.org/jira/browse/CB-1404 ). However, the fix involves falling back to a slightly slower method if the bridge is still busy, so while the performance is better for normal usage, it isn't something you want to put in your main render loop.
For an unusual requirement like that, a custom bridge might make more sense - there are other methods available (eg XHR with body content for both request and response) that would be much better for transferring lots of data, but wouldn't really work as a generic solution like the standard bridges.
来源：https://stackoverflow.com/questions/13422138/phonegap-2-2-how-does-the-new-bridge-work