Learn the operating mechanism of jsBridge in one article

Our company's APP is a typical hybrid development APP, which embeds front-end pages. To achieve the same effect as the native ones, the front-end pages cannot avoid calling some native methods. jsBridge is the bridge between js and原生communication. This article does not talk about conceptual things, but analyzes the jsBridge source code in our project to understand how it is implemented from the front-end perspective.

js calling method

Let's take a look at how js calls a native method. First, the window.WebViewJavascriptBridge.init method is called during initialization:

window.WebViewJavascriptBridge.init()

Then if you want to call a native method, you can use the following function:

function native (funcName, args = {}, callbackFunc, errorCallbackFunc) {
    // Check if the parameters are valid if (args && typeof args === 'object' && Object.prototype.toString.call(args).toLowerCase() === '[object object]' && !args.length) {
        args = JSON.stringify(args);
    } else {
        throw new Error('args does not conform to the specification');
    }
    // Determine whether it is a mobile phone environment if (getIsMobile()) {
        //Call the callHandler method of the window.WebViewJavascriptBridge object window.WebViewJavascriptBridge.callHandler(
            funcName,
            args,
            (res) => {
                res = JSON.parse(res);
                if (res.code === 0) {
                    return callbackFunc(res);
                } else {
                    return errorCallbackFunc(res);
                }
            }
        );
    }
}

Just pass in the method name, parameters and callback to be called. It first verifies the parameters and then calls the window.WebViewJavascriptBridge.callHandler method.

In addition, callbacks can be provided for native calls:

window.WebViewJavascriptBridge.registerHandler(funcName, callbackFunc);

Next, let’s take a look at what window.WebViewJavascriptBridge object is.

Android

The WebViewJavascriptBridge.js file contains a self-executing function, which first defines some variables:

// define variable var messagingIframe;
var sendMessageQueue = [];// Queue for sending messages var receiveMessageQueue = [];// Queue for receiving messages var messageHandlers = {};// Message handler var CUSTOM_PROTOCOL_SCHEME = 'yy';// Custom protocol var QUEUE_HAS_MESSAGE = '__QUEUE_MESSAGE__/';

var responseCallbacks = {}; // Response callback var uniqueId = 1;

I have simply translated it according to the variable name, and the specific use will be analyzed next. Next, the WebViewJavascriptBridge object is defined:

var WebViewJavascriptBridge = window.WebViewJavascriptBridge = {
    init: init,
    send: send,
    registerHandler: registerHandler,
    callHandler: callHandler,
    _fetchQueue: _fetchQueue,
    _handleMessageFromNative: _handleMessageFromNative
};

You can see that it is an ordinary object with some methods mounted on it. I will not look at the specific methods for now, and continue below:

var doc = document;
_createQueueReadyIframe(doc);

The _createQueueReadyIframe method is called:

function _createQueueReadyIframe (doc) {
    messagingIframe = doc.createElement('iframe');
    messagingIframe.style.display = 'none';
    doc.documentElement.appendChild(messagingIframe);
}

This method is very simple, just create a hidden iframe and insert it into the page, and continue:

// Create an event object of Events type (basic event module) var readyEvent = doc.createEvent('Events');
// Define the event name as WebViewJavascriptBridgeReady
readyEvent.initEvent('WebViewJavascriptBridgeReady');
//Trigger the event through documentdoc.dispatchEvent(readyEvent);

A custom event is defined here and dispatched directly. Other places can listen to this event just like listening to native events:

document.addEventListener(
    'WebViewJavascriptBridgeReady',
    function () {
        console.log(window.WebViewJavascriptBridge)
    },
    false
);

The purpose here, as I understand it, is that if the jsBridge file is introduced after other code, it is necessary to ensure that the previous code knows when the window.WebViewJavascriptBridge object is available. If it is stipulated that the jsBridge must be introduced first, then this processing is not required.

The self-executing function ends here. Next, let's take a look at the initial init method:

function init (messageHandler) {
    if (WebViewJavascriptBridge._messageHandler) {
        throw new Error('WebViewJavascriptBridge.init called twice');
    }
    // No parameters are passed when init is called, so messageHandler=undefined
    WebViewJavascriptBridge._messageHandler = messageHandler;
    // Currently receiveMessageQueue is just an empty array var receivedMessages = receiveMessageQueue;
    receiveMessageQueue = null;
    for (var i = 0; i < receivedMessages.length; i++) {
        _dispatchMessageFromNative(receivedMessages[i]);
    }
}

From an initialization perspective, this init method seems to do nothing. Next, let's look at callHandler method to see how to call Android's method:

function callHandler (handlerName, data, responseCallback) {
    _doSend({
        handlerName: handlerName,
        data: data
    }, responseCallback);
}

After processing the parameters, the _doSend method is called again:

function _doSend (message, responseCallback) {
    // If a callback is provided if (responseCallback) {
        // Generate a unique callback id
        var callbackId = 'cb_' + (uniqueId++) + '_' + new Date().getTime();
        // The callback is stored in the responseCallbacks object by id responseCallbacks[callbackId] = responseCallback;
        // Add the callback id to the message to be sent to native message.callbackId = callbackId;
    }
    //Add the message to the message queue sendMessageQueue.push(message);
    messagingIframe.src = CUSTOM_PROTOCOL_SCHEME + '://' + QUEUE_HAS_MESSAGE;
}

This method first generates a unique id for the callback function when calling the native method and saves it to the responseCallbacks object defined at the beginning, and then adds the id to the information to be sent, so the structure of a message is as follows:

{
    handlerName,
    data,
    callbackId
}

Then add the message to the sendMessageQueue array defined at the beginning, and finally set src attribute of iframe : yy://__QUEUE_MESSAGE__/ , which is actually a custom protocol url . I did a simple search and found that native will intercept this url to do corresponding processing. We can't go on here because we don't know what native has done. After a simple search, I found this library: WebViewJavascriptBridge. Our company should have modified it based on this library. After combining some articles on the Internet, I roughly know that after native intercepts this url , it will call js 's window.WebViewJavascriptBridge._fetchQueue method:

function _fetchQueue () {
    // Convert the message queue we want to send into a string var messageQueueString = JSON.stringify(sendMessageQueue);
    // Clear the message queue sendMessageQueue = [];
    // Android cannot read the returned data directly, so it still communicates with Java through the iframe's src messagingIframe.src = CUSTOM_PROTOCOL_SCHEME + '://return/_fetchQueue/' + encodeURIComponent(messageQueueString);
}

After Android intercepts url , it knows that js has sent a message to Android, so it actively calls the _fetchQueue method of js to take out the message previously added to the queue. Because it cannot directly read the data returned by js method, the formatted message is added to url and sent again through iframe . At this time, the native will intercept the url yy://return/_fetchQueue/ , then take out the subsequent message, parse the native method name and parameters to be executed, and execute the corresponding native method. When the native method is executed, it will actively call window.WebViewJavascriptBridge._handleMessageFromNative method of js :

function _handleMessageFromNative (messageJSON) {
    // According to the logic of the previous init method, we know that receiveMessageQueue will be set to null, so we will go to the else branch if (receiveMessageQueue) {
        receiveMessageQueue.push(messageJSON);
    } else {
        _dispatchMessageFromNative(messageJSON);
    }
}

Take a look at what the _dispatchMessageFromNative method does:

function _dispatchMessageFromNative (messageJSON) {
    setTimeout(function () {
        // The original message sent back is of string type, converted to json
        var message = JSON.parse(messageJSON);
        var responseCallback;
        // The java call is completed, and the responseId sent back is the callbackId we sent to it before
        if (message.responseId) {
            // Get the callback method associated with the id from the responseCallbacks object responseCallback = responseCallbacks[message.responseId];
            if (!responseCallback) {
                return;
            }
            // Execute callback, js calls Android method and successfully receives the message responseCallback(message.responseData);
            delete responseCallbacks[message.responseId];
        } else {
            // ...
        }
    });
}

messageJSON is the message sent back by the native method. In addition to the relevant information returned after the native method is executed, it also carries callbackId we passed to it before, so we can use this id to find the associated callback in responseCallbacks and execute it. This time, the process of js calling the native method ends. However, there is obviously a branch in the function when id does not exist. What is it used for? What we introduced earlier are all js calling native methods, but obviously, native can also send messages to js directly, such as the common interception of the return key function. When the native listens to the return key event, it will actively send information to tell the front-end page, and the page can execute the corresponding logic. This else branch is used to handle this situation:

function _dispatchMessageFromNative (messageJSON) {
    setTimeout(function () {
        if (message.responseId) {
            // ...
        } else {
            // Just like the message we send to the native can have an id, the message sent to us by the native can also have an id, and the native internal will also associate a callback with this id if (message.callbackId) {
                var callbackResponseId = message.callbackId;
                //If the frontend needs to reply to the native device, it should include the id sent by the native device before, so that the native device can find the corresponding callback through the id and execute it. responseCallback = function (responseData) {
                    _doSend({
                        responseId: callbackResponseId,
                        responseData: responseData
                    });
                };
            }
            // We did not set a default _messageHandler, so it is undefined
            var handler = WebViewJavascriptBridge._messageHandler;
            // The message sent natively contains the name of the processing method if (message.handlerName) {
                // Use the method name to find out whether there is a corresponding processing method in the messageHandlers object handler = messageHandlers[message.handlerName];
            }
            try {
                //Execute the processing method handler(message.data, responseCallback);
            } catch (exception) {
                if (typeof console !== 'undefined') {
                    console.log('WebViewJavascriptBridge: WARNING: javascript handler threw.', message, exception);
                }
            }
        }
    });
}

For example, if we want to listen to the native return key event, we first register it through the method of the window.WebViewJavascriptBridge object:

window.WebViewJavascriptBridge.registerHandler('onBackPressed', () => {
    // Do something...
})

registerHandler method is as follows:

function registerHandler (handlerName, handler) {
    messageHandlers[handlerName] = handler;
}

It's very simple. We store the event name and method we want to monitor in messageHandlers object. Then, if the native monitor receives the return key event, it will send a message with the following structure:

{
    handlerName: 'onBackPressed'
}

In this way, we can find the function we registered through handlerName and execute it.

At this point, the logic of mutual calls between js and native in the Android environment has ended. To sum up:

1.js calls native

Generate a unique id , save the callback and id , then add the information to be sent (with the unique id generated this time) to a queue, and then send a custom protocol request through iframe . After the native interception, call a method of the js window.WebViewJavascriptBridge object to obtain the queue information, parse the request and parameters, and execute the corresponding native method, and then pass the response (with the id sent by the front end) to the front end by calling the specified method of js window.WebViewJavascriptBridge . The front end then finds the previously stored callback through id and executes it.

2. Native call js

First, the front end needs to register the events to be monitored in advance, save the event name and callback, and then the native will call the specified method of js window.WebViewJavascriptBridge object at a certain time. The front end finds the registered callback according to the event name of the return parameter for execution. At the same time, the native will also pass an id . If the front end needs to send a message to the native after executing the corresponding logic, then the id must be brought back, and the native will find the corresponding callback for execution based on the id .

As you can see, the logic on both js and native sides is consistent.

ios

ios and Android are basically the same, with some differences in details. First of all, the protocols are different. ios one is like this:

var CUSTOM_PROTOCOL_SCHEME_IOS = 'https';
var QUEUE_HAS_MESSAGE_IOS = '__wvjb_queue_message__';

Then when ios initializes and creates iframe , it sends a request:

var BRIDGE_LOADED_IOS = '__bridge_loaded__';
function _createQueueReadyIframe (doc) {
    messagingIframe = doc.createElement('iframe');
    messagingIframe.style.display = 'none';
    if (isIphone()) {
        // This should be the bridge that iOS needs to load first
        messagingIframe.src = CUSTOM_PROTOCOL_SCHEME_IOS + '://' + BRIDGE_LOADED_IOS;
    }
    doc.documentElement.appendChild(messagingIframe);
}

Then, when ios gets our message queue, it does not need to go through iframe . It can directly get the data returned by executing the js function:

function _fetchQueue () {
    var messageQueueString = JSON.stringify(sendMessageQueue);
    sendMessageQueue = [];
    return messageQueueString; // Return directly without going through iframe
}

Everything else is the same.

Summarize

This article analyzes the source code of jsBridge and finds that it is actually a very simple thing. However, you may not have studied it seriously in normal times. You always want to do something "big", so you become a "high-minded" person. I hope you will not be like me.

This is the end of this article about learning the operating mechanism of jsBridge in one article. For more relevant content about the operating mechanism of jsBridge, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!