一文搞懂jsBridge的运行机制

简介: 一文搞懂jsBridge的运行机制

我司的APP是一个典型的混合开发APP,内嵌的都是前端页面,前端页面要做到和原生的效果相似,就避免不了调用一些原生的方法,jsBridge就是js原生通信的桥梁,本文不讲概念性的东西,而是通过分析一下我司项目中的jsBridge源码,来从前端角度大概了解一下它是怎么实现的。



js调用方式


先来看一下,js是怎么来调用某个原生方法的,首先初始化的时候会调用window.WebViewJavascriptBridge.init方法:


window.WebViewJavascriptBridge.init()


然后如果要调用某个原生方法可以使用下面的函数:


function native (funcName, args = {}, callbackFunc, errorCallbackFunc) {
    // 校验参数是否合法
    if (args && typeof args === 'object' && Object.prototype.toString.call(args).toLowerCase() === '[object object]' && !args.length) {
        args = JSON.stringify(args);
    } else {
        throw new Error('args不符合规范');
    }
    // 判断是否是手机环境
    if (getIsMobile()) {
        // 调用window.WebViewJavascriptBridge对象的callHandler方法
        window.WebViewJavascriptBridge.callHandler(
            funcName,
            args,
            (res) => {
                res = JSON.parse(res);
                if (res.code === 0) {
                    return callbackFunc(res);
                } else {
                    return errorCallbackFunc(res);
                }
            }
        );
    }
}


传入要调用的方法名、参数和回调即可,它先校验了一下参数,然后会调用window.WebViewJavascriptBridge.callHandler方法。


此外也可以提供回调供原生调用:


window.WebViewJavascriptBridge.registerHandler(funcName, callbackFunc);


接下来看一下window.WebViewJavascriptBridge对象到底是啥。


安卓


WebViewJavascriptBridge.js文件内是一个自执行函数,首先定义了一些变量:


// 定义变量
var messagingIframe;
var sendMessageQueue = [];// 发送消息的队列
var receiveMessageQueue = [];// 接收消息的队列
var messageHandlers = {};// 消息处理器
var CUSTOM_PROTOCOL_SCHEME = 'yy';// 自定义协议
var QUEUE_HAS_MESSAGE = '__QUEUE_MESSAGE__/';
var responseCallbacks = {};// 响应的回调
var uniqueId = 1;


根据变量名简单翻译了一下,具体用处接下来会分析。接下来定义了WebViewJavascriptBridge对象:


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


可以看到就是一个普通的对象,上面挂载了一些方法,具体方法暂时不看,继续往下:


var doc = document;
_createQueueReadyIframe(doc);


调用了_createQueueReadyIframe方法:


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


这个方法很简单,就是创建了一个隐藏的iframe插入到页面,继续往下:


// 创建一个Events类型(基础事件模块)的事件(Event)对象
var readyEvent = doc.createEvent('Events');
// 定义事件名为WebViewJavascriptBridgeReady
readyEvent.initEvent('WebViewJavascriptBridgeReady');
// 通过document来触发该事件
doc.dispatchEvent(readyEvent);


这里定义了一个自定义事件,并直接派发了,其他地方可以像通过监听原生事件一样监听该事件:


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


这里的用处我理解就是当该jsBridge文件如果是在其他代码之后引入的话需要保证之前的代码能知道window.WebViewJavascriptBridge对象何时可用,如果规定该jsBridge必须要最先引入的话那么就不需要这个处理了。


到这里自执行函数就结束了,接下来看一下最开始的init方法:


function init (messageHandler) {
    if (WebViewJavascriptBridge._messageHandler) {
        throw new Error('WebViewJavascriptBridge.init called twice');
    }
    // init调用的时候没有传参,所以messageHandler=undefined
    WebViewJavascriptBridge._messageHandler = messageHandler;
    // 当前receiveMessageQueue也只是一个空数组
    var receivedMessages = receiveMessageQueue;
    receiveMessageQueue = null;
    for (var i = 0; i < receivedMessages.length; i++) {
        _dispatchMessageFromNative(receivedMessages[i]);
    }
}


从初始化的角度来看,这个init方法似乎啥也没做。接下来我们来看callHandler方法,看看是如何调用安卓的方法的:


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


处理了一下参数又调用了_doSend方法:


function _doSend (message, responseCallback) {
    // 如果提供了回调的话
    if (responseCallback) {
        // 生成一个唯一的回调id
        var callbackId = 'cb_' + (uniqueId++) + '_' + new Date().getTime();
        // 回调通过id存储到responseCallbacks对象上
        responseCallbacks[callbackId] = responseCallback;
        // 把该回调id添加到要发送给native的消息里
        message.callbackId = callbackId;
    }
    // 消息添加到消息队列里
    sendMessageQueue.push(message);
    messagingIframe.src = CUSTOM_PROTOCOL_SCHEME + '://' + QUEUE_HAS_MESSAGE;
}


这个方法首先把调用原生方法时的回调函数通过生成一个唯一的id保存到最开始定义的responseCallbacks对象里,然后把该id添加到要发送的信息上,所以一个message的结构是这样的:


{
    handlerName,
    data,
    callbackId
}


接着把该message添加到最开始定义的sendMessageQueue数组里,最后设置了iframesrc属性:yy://__QUEUE_MESSAGE__/,这其实就是一个自定义协议的url,我简单搜索了一下,native会拦截这个url来做相应的处理,到这里我们就走不下去了,因为不知道原生做了什么事情,简单搜索了一下,发现了这个库:

WebViewJavascriptBridge,我司应该是在这个库基础上修改的,结合了网上的一些文章后大概知道了,原生拦截到这个url后会调用js

window.WebViewJavascriptBridge._fetchQueue方法:


function _fetchQueue () {
    // 把我们要发送的消息队列转成字符串
    var messageQueueString = JSON.stringify(sendMessageQueue);
    // 清空消息队列
    sendMessageQueue = [];
    // 安卓无法直接读取返回的数据,因此还是通过iframe的src和java通信
    messagingIframe.src = CUSTOM_PROTOCOL_SCHEME + '://return/_fetchQueue/' + encodeURIComponent(messageQueueString);
}


安卓拦截到url后,知道js给安卓发送消息了,所以主动调用js_fetchQueue方法,取出之前添加到队列里的消息,因为无法直接读取js方法返回的数据,所以把格式化后的消息添加到url上,再次通过iframe来发送,此时原生又会拦截到yy://return/_fetchQueue/这个url,那么取出后面的消息,解析出要其中要执行的原生方法名和参数后执行对应的原生方法,当原生方法执行完后又会主动调用jswindow.WebViewJavascriptBridge._handleMessageFromNative方法:


function _handleMessageFromNative (messageJSON) {
    // 根据之前的init方法的逻辑我们知道receiveMessageQueue是会被设置为null的,所以会走else分支
    if (receiveMessageQueue) {
        receiveMessageQueue.push(messageJSON);
    } else {
        _dispatchMessageFromNative(messageJSON);
    }
}


看一下_dispatchMessageFromNative方法做了什么:


function _dispatchMessageFromNative (messageJSON) {
    setTimeout(function () {
        // 原生发回的消息是字符串类型的,转成json
        var message = JSON.parse(messageJSON);
        var responseCallback;
        // java调用完成,发回的responseId就是我们之前发送给它的callbackId
        if (message.responseId) {
            // 从responseCallbacks对象里取出该id关联的回调方法
            responseCallback = responseCallbacks[message.responseId];
            if (!responseCallback) {
                return;
            }
            // 执行回调,js调用安卓方法后到这里顺利收到消息
            responseCallback(message.responseData);
            delete responseCallbacks[message.responseId];
        } else {
            // ...
        }
    });
}


messageJSON就是原生发回的消息,里面除了执行完原生方法后返回的相关信息外,还带着之前我们传给它的callbackId,所以我们可以通过这个id来在responseCallbacks里找到关联的回调并执行,本次js调用原生方法流程结束。


但是,明显函数里还有不存在id时的分支,这里是用来干啥的呢,我们前面介绍的都是js调用原生方法,但是显然,原生也可以直接给js发消息,比如常见的拦截返回键功能,当原生监听到返回键事件后它会主动发送信息告诉前端页面,页面就可以执行对应的逻辑,这个else分支就是用来处理这种情况:


function _dispatchMessageFromNative (messageJSON) {
    setTimeout(function () {
        if (message.responseId) {
            // ...
        } else {
            // 和我们传给原生的消息可以带id一样,原生传给我们的消息也可以带一个id,同时原生内部也会通过这个id关联一个回调
            if (message.callbackId) {
                var callbackResponseId = message.callbackId;
                //如果前端需要再给原生回消息的话那么就带上原生之前传来的id,这样原生就可以通过id找到对应的回调并执行
                responseCallback = function (responseData) {
                    _doSend({
                        responseId: callbackResponseId,
                        responseData: responseData
                    });
                };
            }
            // 我们并没有设置默认的_messageHandler,所以是undefined
            var handler = WebViewJavascriptBridge._messageHandler;
            // 原生发送的消息里面有处理方法名称
            if (message.handlerName) {
                // 通过方法名称去messageHandlers对象里查找是否有对应的处理方法
                handler = messageHandlers[message.handlerName];
            }
            try {
                // 执行处理方法
                handler(message.data, responseCallback);
            } catch (exception) {
                if (typeof console !== 'undefined') {
                    console.log('WebViewJavascriptBridge: WARNING: javascript handler threw.', message, exception);
                }
            }
        }
    });
}


比如我们要监听原生的返回键事件,我们先通过window.WebViewJavascriptBridge对象的方法注册一下:


window.WebViewJavascriptBridge.registerHandler('onBackPressed', () => {
    // 做点什么...
})


registerHandler方法如下:


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


很简单,把我们要监听的事件名和方法都存储到messageHandlers对象上,然后如果原生监听到返回键事件后会发送如下结构的消息:


{
    handlerName: 'onBackPressed'
}


这样就可以通过handlerName找到我们注册的函数进行执行了。

到此,安卓环境的js和原生互相调用的逻辑就结束了,总结一下就是:


1.js调用原生


生成一个唯一的id,把回调和id保存起来,然后将要发送的信息(带上本次生成的唯一id)添加到一个队列里,之后通过iframe发送一个自定义协议的请求,原生拦截到后调用jswindow.WebViewJavascriptBridge对象的一个方法来获取队列的信息,解析出请求和参数后执行对应的原生方法,然后再把响应(带上前端传来的id)通过调用jswindow.WebViewJavascriptBridge的指定方法传递给前端,前端再通过id找到之前存储的回调,进行执行。


2.原生调用js


首先前端需要事先注册要监听的事件,把事件名和回调保存起来,然后原生在某个时刻会调用jswindow.WebViewJavascriptBridge对象的指定方法,前端根据返回参数的事件名找到注册的回调进行执行,同时原生也会传过来一个id,如果前端执行完相应逻辑后还要给原生回消息,那么要把该id带回去,原生根据该id来找到对应的回调进行执行。


可以看到,js和原生两边的逻辑都是一致的。


ios


ios和安卓基本是一致的,部分细节上有点区别,首先是协议不一样,ios的是这样的:


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


然后ios初始化创建iframe的时候会发送一个请求:


var BRIDGE_LOADED_IOS = '__bridge_loaded__';
function _createQueueReadyIframe (doc) {
    messagingIframe = doc.createElement('iframe');
    messagingIframe.style.display = 'none';
    if (isIphone()) {
        // 这里应该是ios需要先加载一下bridge
        messagingIframe.src = CUSTOM_PROTOCOL_SCHEME_IOS + '://' + BRIDGE_LOADED_IOS;
    }
    doc.documentElement.appendChild(messagingIframe);
}


再然后是ios获取我们的消息队列时不需要通过iframe,它能直接获取执行js函数返回的数据:


function _fetchQueue () {
    var messageQueueString = JSON.stringify(sendMessageQueue);
    sendMessageQueue = [];
    return messageQueueString;// 直接返回,不需要通过iframe
}


其他部分都是一样的。


总结


本文分析了一下jsBridge的源码,可以发现其实是个很简单的东西,但是平时可能就没有去认真了解过它,总想做一些”大“的事情,以至于沦为了一个”好高骛远“的人,希望各位不要像笔者一样。


另外本文分析的只是笔者公司的jsBridge实现,可能有不一样、更好或更新的实现,欢迎留言探讨。




相关文章
|
23天前
|
前端开发 编译器 Android开发
构建高效Android应用:探究Kotlin协程的异步处理机制
【4月更文挑战第2天】在现代移动应用开发中,提供流畅且响应迅速的用户体验是至关重要的。随着Android平台的发展,Kotlin语言凭借其简洁性和功能性编程的特点成为了主流选择之一。特别地,Kotlin协程作为一种新型的轻量级线程管理机制,为开发者提供了强大的异步处理能力,从而显著提升了应用程序的性能和响应速度。本文将深入探讨Kotlin协程在Android中的应用,分析其原理、实现以及如何通过协程优化应用性能。
23 2
|
3月前
|
前端开发 JavaScript 安全
Promise/A+ 规范详解:打造健壮异步代码的必备知识(上)
Promise/A+ 规范详解:打造健壮异步代码的必备知识(上)
Promise/A+ 规范详解:打造健壮异步代码的必备知识(上)
|
23天前
|
API Android开发 开发者
构建高效安卓应用:探究Kotlin协程在网络请求中的应用
【4月更文挑战第3天】 随着移动应用开发的不断深入,对应用性能的要求也越来越高。在Android开发中,网络请求是一项常见的任务,但传统的线程和异步处理方式往往导致代码复杂且难以维护。Kotlin协程作为一种轻量级的线程管理方案,为简化异步编程提供了新思路。本文将深入探讨Kotlin协程在Android网络请求中的实现机制与优势,并通过实例分析其在提升应用性能方面的作用。
|
3月前
|
前端开发 安全
Promise/A+ 规范详解:打造健壮异步代码的必备知识(下)
Promise/A+ 规范详解:打造健壮异步代码的必备知识(下)
Promise/A+ 规范详解:打造健壮异步代码的必备知识(下)
|
10月前
|
前端开发 JavaScript
一篇文章搞懂前端事件监听
一篇文章搞懂前端事件监听
267 0
|
11月前
|
JSON 前端开发 数据可视化
umi3源码探究简析
作为蚂蚁金服整个生态圈最为核心的部分,umi可谓是王冠上的红宝石,因而个人认为对于整个umi架构内核的学习及设计哲学的理解,可能比如何使用要来的更为重要;作为一个使用者,希望能从各位大佬的源码中汲取一些养分以及获得一些灵感
188 0
|
消息中间件 Dart
|
JavaScript 前端开发
JS精髓中的精髓,事件进阶使用
1.事件监听器 如果要为一个元素添加多个相同的事件,该如何实现呢?这就需要用到另外一种添加事件的方式了,那就是——事件监听器 所谓的“事件监听器”,指的是使用addEventListener()方法为一个元素添加事件,我们又称之为“绑定事件” 案例:
89 0
JS精髓中的精髓,事件进阶使用
|
JavaScript
JS之用面向对象和传统过程式编程
改写成面向对象时,可先将普通函数变型,再改成面向对象。 普通方法变型 普通方法变型,变型有3个原则 1)尽量不要出现函数嵌套函数 2)可以用全局变量 3)把onload中不是赋值的语句放到单独函数中 如下代码中,完成了普通函数的变型。
78 0
JS之用面向对象和传统过程式编程
|
移动开发 开发框架 前端开发
一文搞懂ReactNative生命周期的进化
一文搞懂ReactNative生命周期的进化
364 0
一文搞懂ReactNative生命周期的进化