JSB 原理與實踐

什麼是 JSB

我們開發的 h5 頁面運行在端上的 WebView 容器之中，很多業務場景下 h5 需要依賴端上提供的信息 / 能力，這時我們需要一個可以連接原生運行環境和 JS 運行環境的橋樑 。 這個橋樑就是 JSB，JSB 讓 Web 端和 Native 端得以實現雙向通信。

WebView 概述

WebView 是移動端中的一個控件，它爲 JS 運行提供了一個沙箱環境。WebView 能夠加載指定的 url，攔截頁面發出的各種請求等各種頁面控制功能，JSB 的實現就依賴於 WebView 暴露的各種接口。由於歷史原因，安卓和 iOS 均有高低兩套版本的 WebView 內核：

K3utk7

PS: 下文中出現的高版本均代指 iOS 8+ 或 Android 4.4+，低版本則相反。

JSB 原理

要實現雙向通信自然要依次實現 Native 向 Web 發送消息和 Web 向 Native 發送消息。

Native 向 Web 發送消息

Native 向 Web 發送消息基本原理上是在 WebView 容器中動態地執行一段 JS 腳本，通常情況下是調用一個掛載在全局上下文的方法。Android 和 iOS 均提供了不同的接口來實現這一過程。

方法

kICwVx

5eQMXV

實踐

下面我們通過一個小 Demo 來看一下在 iOS 端實現 Native 向 Web 端發消息的實際效果：

（本文所有 Demo 均運行在 iOS14.5 模擬器中，WebView 容器採用 WKWebView 內核）

頁面上半部分的 UI 是由 HTML + CSS 渲染所得，是一個純靜態的 webpage，中間的輸入框和按鈕是 Native 原生控件，直接覆蓋在 WebView 容器之上。在 Native 按鈕上綁定了一個點擊事件：將文本框輸入的字符視爲 JS 字符串並調用相關 API 直接執行。

可以看到當我們在文本框中輸入下列字符並點擊按鈕後，h5 頁面中 id 爲 test 的 p 標籤內容被修改了。

document.querySelector('#test').innerHTML = 'I am from native';

敏銳同學到這一步其實就已經知道我們在日常使用 JSB 時客戶端是如何調用前端 JS 代碼了，我們在剛剛的靜態 html 文件中添加幾行 JS 代碼：

function evaluateByNative(params) {
    const p = document.createElement('p');
    p.innerText = params;
    document.body.appendChild(p);
    return 'Hello Bridge!';
}

在文本框中輸入 evaluateByNative(23333)，來看一下調用的結果：

可以看到 Native 端可以直接調用掛載在 window 上的全局方法並傳入相應的函數執行參數，並且在函數執行結束後 Native 端可以直接拿到執行成功的返回值。

Web 向 Native 發送消息

Web 向 Native 發送消息本質上就是某段 JS 代碼的執行端上是可感知的，目前業界主流的實現方案有兩種，分別是攔截式和注入式。

攔截式

和瀏覽器類似 WebView 中發出的所有請求都是可以被 Native 容器感知到的（是不是想到了 Gecko），因此攔截式具體指的是 Native 攔截 Web 發出的 URL 請求，雙方在此之前約定一個 JSB 請求格式，如果該請求是 JSB 則進行相應的處理，若不是則直接轉發。

Native 攔截請求的鉤子方法：

Kah4xL

攔截式的基本流程如下：

上述流程存在幾個問題：

  1. 通過何種方式發出請求？

Web 端發出請求的方式非常多樣，例如 <a/> 、iframe.src、location.href、ajax 等，但 <a/> 需要用戶手動觸發，location.href 可能會導致頁面跳轉，安卓端攔截 ajax 的能力有所欠缺，因此絕大多數攔截式實現方案均採用iframe 來發送請求。

  1. 如何規定 JSB 的請求格式？

一個標準的 URL 由 <scheme>://<host>:<port><path> 組成，相信大家都有過從微信或手機瀏覽器點擊某個鏈接意外跳轉到其他 App 的經歷，如果有仔細留意過這些鏈接的 URL 你會發現目前主流 App 都有其專屬的一個 scheme 來作爲該應用的標識，例如微信的 URL scheme 就是 weixin://。JSB 的實現借鑑這一思路，定製業務自身專屬的一個 URL scheme 來作爲 JSB 請求的標識，例如字節內部實現攔截式 JSB 的 SDK 中就定義了 bytedance:// 這樣一個 scheme。

// Web 通過動態創建 iframe，將 src 設置爲符合雙端規範的 url scheme
const CUSTOM_PROTOCOL_SCHEME = 'prek'

function web2Native(event) {    
    const messagingIframe = document.createElement('iframe');
    messagingIframe.style.display = 'none';
    messagingIframe.src = CUSTOM_PROTOCOL_SCHEME + '://' + event;
    document.documentElement.appendChild(messagingIframe);

    setTimeout(() => {
        document.documentElement.removeChild(messagingIframe);
    }, 200)
}

攔截式在雙端都具有非常好的向下兼容性，曾經是最主流的 JSB 實現方案，但目前在高版本的系統中已經逐漸被淘汰，理由是它有如下幾個劣勢：

實踐案例

同樣用一個簡單的 Demo2 來看一下如何使用攔截式實現 Web 向 Native 發送消息，這裏實現了在 Web 端喚起 Native 的相冊。

遵循上述實現方式，Web 發送消息的代碼如下：

const CUSTOM_PROTOCOL_SCHEME = 'prek' // 自定義 url scheme

function web2Native(event_name) {
    const messagingIframe = document.createElement('iframe')
    messagingIframe.style.display = 'none'
    messagingIframe.src = CUSTOM_PROTOCOL_SCHEME + '://' + event_name
    document.documentElement.appendChild(messagingIframe)
    setTimeout(() => {
        document.documentElement.removeChild(messagingIframe)
    }, 0)
}

const btn = document.querySelector('#btn')

btn.onclick = () => {
    web2Native('openPhotoAlbum')
}

Native 側通過 decidePolicyForNavigationAction 這一 delegate 實現請求攔截，解析 URL 參數，若 URL scheme 是 prek 則認爲該請求是一個來自 Web 的 JSB 調用：

- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler {
  NSURL *url = navigationAction.request.URL;
  NSLog(@"攔截到 Web 發出的請求 = %@", url);

  if ([self isSchemeMatchPrek:url]) {
    NSString* host = url.host.lowercaseString;
    if ([host isEqualToString: @"openphotoalbum"]) {
      [self openCameraForWeb]; // 打開相冊
      NSLog(@"打開相冊");
    }
    decisionHandler(WKNavigationActionPolicyCancel);
    return;
  } else {
    decisionHandler(WKNavigationActionPolicyAllow);
  }
}

爲了更清晰地看到 Native 攔截的結果，在上述代理方法中打個斷點：

繼續執行，Congratulation！模擬器的相冊被打開了！

注入式

注入式的原理是通過 WebView 提供的接口向 JS 全局上下文對象（window）中注入對象或者方法，當 JS 調用時，可直接執行相應的 Native 代碼邏輯，從而達到 Web 調用 Native 的目的。

Native 注入 API 的相關方法：

RxXyx7

JSContext *context = [webView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"];

context[@"getAppInfo"] = ^(msg) {
    return @"ggl_2693";
};
window.getAppInfo(); // 'ggl_2693'

這種方法簡單而直觀，並且不存在參數長度限制和性能瓶頸等問題，目前主流的 JSB SDK 都將注入式方案作爲優先使用的對象。注入式的實現非常簡單，這裏不做案例展示。

兩種方案對比

爲了更清晰地表達這兩種方式的區別，這裏貼一個對比表格：

2iAnHP

如何執行回調

通過上述介紹我們已經知道如何實現雙端互相發送消息，但上述兩個通信過程缺少了 “迴應” 這一動作，原因就是上述步驟缺少了回調函數的執行。以攔截式爲例，常見的一個 JSB 調用是 Web 獲取當前 App 信息， Native 攔截到 bytedance://getAppInfo這樣一個請求後將獲取當前 App 信息，那獲取完成後如何讓 Web 端拿到該信息呢？

一個最簡單的做法是類比 JSONP 的實現，我們可以在請求的 URL 上拼接回調方法的事件名，將該事件掛載在全局 window 上，由於 Native 端可以輕鬆執行 JS 代碼，因此在完成端邏輯後直接執行該事件名對應的回調方法即可。以 getAppInfo 爲例：

// Web
const uniqueID = 1 // 爲防止事件名衝突，給每個 callback 設置一個唯一標識
function webCallNative(event, params, callback) {
    if (typeof callback === 'Function') {
        const callbackID = 'jsb_cb_' + (uniqueID++) + '_' + Date.now();
        window[callbackID] = callback
    }
    const params = {callback: callbackID}
    // 構造 url scheme
    const src = 'bytedance://getAppInfo?' + JSON.stringify(params)
    ...
}

// Native
1. 解析傳入的參數 'getAppInfo' 得知 Web 希望獲取 AppInfo
2. 執行端邏輯獲取 AppInfo
3. 執行參數中掛載在全局的 callback 方法，AppInfo 作爲回調方法的參數

因此只要把相應的回調方法掛載在全局對象上，Native 即可把每次調用後的響應通過動態執行 JS 方法的形式傳遞到 Web 端，這樣一來整個通信過程就實現了閉環。

串聯雙端通信的過程

現在我們已經知道如何實現兩端互相發送消息以及執行回調了，但看起來並不好用：首先調用 JSB 時需要在方法名後拼接參數和對應的回調函數，其次回調函數還需要一個一個地掛載在全局對象上。

我們期望的使用方式其實是這樣：

// Web
web.call('event1', {param1}, (res) => {...}) // 觸發 native event1 執行
web.on('event2', (res) => {...})

// Native 
// 這裏用 js 代替，理解大致意思即可
native.call('event2', {param2}, (res) => {...}) // 觸發 web event2 執行
native.on('event1', (res) => {...})

這裏的 JSB 就像是一個跨越兩端的 EventEmitter，因此需要 Web 和 Native 遵循同一套調度機制。

上圖給出了 Web 調用 -> Native 監聽的執行過程，同理 Native 調用 -> Web 監聽也是同樣的邏輯，只是把兩邊的實現調換一種語言，這裏不贅述了。

貼一張其他同學畫的時序圖，幫助理解整個通信過程

Demo3 基於開源的 WebViewJavascriptBridge 演示了一套完整的通訊流程是怎樣進行的，有興趣的同學請自行戳源碼地址 JSB_Demo 自行體驗。（需要使用 Xcode 打開，會涉及一些客戶端的知識，請配合文檔和 Google 使用）。

一點感受

筆者所在業務使用的 bridge 即司內目前最新的 SDK，沒有歷史包袱、使用體驗也非常良好。得益於客戶端遵循該 SDK 配套的實現機制，即使完全不瞭解 JSB 原理的同學在與端上對接 bridge 時也幾乎沒有遇到障礙。倘若拋開公司完備的基礎建設，想實現一個通用且好用的 JSB 並非易事，因此瞭解其中的門道還是非常有益的。（巨人的肩膀站久了，確實巴適得很🐶)

參考文獻

深入淺出 JSBridge[4]

JSB 實戰 [5]

[1] JSONP: https://en.wikipedia.org/wiki/JSONP

[2] WebViewJavascriptBridge: https://github.com/marcuswestin/WebViewJavascriptBridge

[3] JSB_Demo: https://code.byted.org/caocheng.viccc/JSB_Demo

[4] 深入淺出 JSBridge: https://juejin.cn/post/6936814903021797389#heading-8

[5] JSB 實戰: https://juejin.cn/post/6844903702721986568

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/XU-6TilxI7i2AX6KpP_aCA

猜你喜歡