incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Grieve (JIRA)" <>
Subject [jira] [Commented] (CB-638) Slow native bridge (especially android)
Date Wed, 22 Aug 2012 14:53:42 GMT


Andrew Grieve commented on CB-638:

I've checked in the first round of changes for this. Modes can be tested in the mobile-spec
exec() benchmark.

    jsToNativeModes = {
        PROMPT: 0,
        JS_OBJECT: 1,
        LOCATION_CHANGE: 2  // Not yet implemented
    nativeToJsModes = {
        // Polls for messages using the prompt() bridge.
        POLLING: 0,
        // Does an XHR to a local server, which will send back messages. This is
        // broken on ICS when a proxy server is configured.
        HANGING_GET: 1,
        // For LOAD_URL to be viable, it would need to have a work-around for
        // the bug where the soft-keyboard gets dismissed when a message is sent.
        LOAD_URL: 2,
        // For the ONLINE_EVENT to be viable, it would need to intercept all event
        // listeners (both through addEventListener and window.ononline) as well
        // as set the navigator property itself.
        ONLINE_EVENT: 3,
        // Uses reflection to access private APIs of the WebView that can send JS
        // to be executed.
        // Requires Android 3.2.4 or above.
        PRIVATE_API: 4

-I've not implemented the any keyboard work-arounds for LOAD_URL
-I've not added a workaround for hiding online/offline events from changing
-JS_OBJECT probably needs a better enable/disable detection. Right now it's disabled only
for the 2.3 emulator instead of checking for JSC (via

Some initial benchmark results from my Galaxy Nexus (echos per second, bigger is better, payload
size=500 bytes):

Sync JS->Native:

Using JS_OBJECT for JS->Native and async Native->Response:
Native->JS HANGING_GET: 75-90
Native->JS LOAD_URL: 160
Native->JS PRIVATE_API: 340

ONLINE_EVENT being faster than LOAD_URL surprised me. Especially since it can be made even
a bit faster if it uses JS_OBJECT to retrieve the message instead of PROMPT.

Still to do:
-Implement LOCATION_CHANGE JS->Native mode
-Add detection logic for JS_OBJECT support (this will involve loading a test page to run some
-Add hiding of ONLINE_EVENTS changes from the app via cordova.addWindowEventHandler() and
navigator.__defineGetter__('onLine', ...)
-Make POLLING and ONLINE_EVENT be able to use JS_OBJECT instead of always PROMPT.
-Make POLLING & HANGING_GET retrieve all pending messages in one call instead of one at
a time
-Add mobile-spec test that ensures all modes work (when expected to)

Final Steps:
-Discuss changing the default bridge mode, as well as how to implement fall-back modes.
> Slow native bridge (especially android)
> ---------------------------------------
>                 Key: CB-638
>                 URL:
>             Project: Apache Cordova
>          Issue Type: Improvement
>          Components: Android
>            Reporter: Lee Crossley
>            Assignee: Andrew Grieve
>            Priority: Critical
>              Labels: 2.1.0
> Doing many native callbacks (such as writing files) has a significant overhead.
>'s native bridge is more than 5 times faster than Cordova (on Android).
> I'd love to see similar performance stats in Cordova.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message