PhoneGap 2.2：新桥如何工作？ [英] PhoneGap 2.2: how does the new bridge work?

问题描述

今年年初，我写了一个实验性PhoneGap插件，名为 WebGLGap 。在理论上，它可以通过转发所有的JS调用到插件代码在PhoneGap应用程序中启用WebGL支持。不幸的是，我放弃了它，因为Javascript和插件之间的桥梁是一个巨大的瓶颈：一切（包括顶点数据）被串入一个巨大的字符串，传递到插件，然后解析回JSON，由本地插件代码读取。显然，这使它很无用。

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.

但是我正在阅读PhoneGap 2.2有一个新的桥梁，可以超过10倍更快。它如何工作？它避免字符串化吗？如果桥是足够高效的，它可能值得采取新的看看WebGLGap。

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.

推荐答案

它仍然是字符串。不同之处在于默认值为XHR_WITH_PAYLOAD，它使用带头参数的XMLHttpRequest，而不是使用XHR_NO_PAYLOAD（它使用XHR触发读取队列）或IFRAME_NAV，这是更快的方法之一，但与触摸滚动冲突

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.

在处理快速请求的错误已修复（ https://issues.apache.org/jira/browse/CB-1404 ）。然而，修复涉及回到一个稍慢的方法，如果桥仍然忙，所以虽然性能更好的正常使用，它不是你想要放在你的主渲染循环。

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.

对于一个不寻常的需求，一个自定义桥可能更有意义 - 有其他方法可用（例如XHR与请求和响应的主体内容），将更好地转移大量数据，但不会像标准网桥一样作为通用解决方案。

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.

这篇关于PhoneGap 2.2：新桥如何工作？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！