JSBridge 技術(shù)原理分析
-? ? ?JSBridge的起源? ? -
PhoneGap（Codova 的前身）作為 Hybrid 鼻祖框架，是一個(gè)開(kāi)源的移動(dòng)開(kāi)發(fā)框架，允許你用標(biāo)準(zhǔn)的web技術(shù)-HTML5,CSS3和JavaScript做跨平臺(tái)的Hybird WebUI開(kāi)發(fā)，應(yīng)該是最先被開(kāi)發(fā)者廣泛認(rèn)知的 JSBridge 的應(yīng)用場(chǎng)景。而對(duì)于 JSBridge 的應(yīng)用在國(guó)內(nèi)真正興盛起來(lái)，則是因?yàn)闅⑹旨?jí)應(yīng)用微信的出現(xiàn)。
JSBridge 是一種JS 實(shí)現(xiàn)的Bridge，連接著橋兩端的 Native 和 H5。簡(jiǎn)單來(lái)講，它在APP 內(nèi)方便地讓Native 調(diào)用JS，JS 調(diào)用Native ，是雙向通信的通道。JSBridge 主要提供了JS 調(diào)用Native 代碼的能力，實(shí)現(xiàn)原生功能如查看本地相冊(cè)、打開(kāi)攝像頭、指紋支付等。
既然是『簡(jiǎn)單來(lái)講』，那么 JSBridge 的用途肯定不只『調(diào)用 Native 功能』這么簡(jiǎn)單寬泛。實(shí)際上，JSBridge 就像其名稱中的『Bridge』的意義一樣，是 Native 和非 Native 之間的橋梁，它的核心是 構(gòu)建 Native 和非 Native 間消息通信的通道，而且是雙向通信的通道。
微信、頭條等小程序基于 Web UI，但是為了追求運(yùn)行效率，對(duì) UI 展現(xiàn)邏輯和業(yè)務(wù)邏輯的 JavaScript 進(jìn)行了隔離。
-? ? ?JSBridge的實(shí)現(xiàn)原理? ? -
JavaScript 是運(yùn)行在一個(gè)單獨(dú)的 JS Context 中（例如，WebView 的 Webkit 引擎、JSCore）。由于這些 Context 與原生運(yùn)行環(huán)境的天然隔離，我們可以將這種情況與 RPC（Remote Procedure Call，遠(yuǎn)程過(guò)程調(diào)用）通信進(jìn)行類比，將 Native 與 JavaScript 的每次互相調(diào)用看做一次 RPC 調(diào)用。
在 JSBridge 的設(shè)計(jì)中，可以把前端看做 RPC 的客戶端，把 Native 端看做 RPC 的服務(wù)器端，從而 JSBridge 要實(shí)現(xiàn)的主要邏輯就出現(xiàn)了：通信調(diào)用（Native 與 JS 通信） 和 句柄解析調(diào)用。（如果你是個(gè)前端，而且并不熟悉 RPC 的話，你也可以把這個(gè)流程類比成 JSONP 的流程）
通過(guò)以上的分析，可以清楚地知曉 JSBridge 主要的功能和職責(zé)，接下來(lái)就以 Hybrid 方案 為案例從這幾點(diǎn)來(lái)剖析 JSBridge 的實(shí)現(xiàn)原理。
JS 調(diào)用 Native
Hybrid 方案是基于 WebView 的，JavaScript 執(zhí)行在 WebView 的 Webkit 引擎中。因此，Hybrid 方案中 JSBridge 的通信原理會(huì)具有一些 Web 特性。
方式1：注入API
對(duì)于 iOS來(lái)說(shuō)，
UIWebView提供了
JavaScriptScore方法，支持 iOS 7.0 及以上系統(tǒng)WKWebview提供了?
window.webkit.messageHandlers?方法，支持 iOS 8.0 及以上系統(tǒng)。
對(duì)于Andriod來(lái)說(shuō)，
4.2 之前，Android 注入 JavaScript 對(duì)象的接口是?
addJavascriptInterface，但是這個(gè)接口有漏洞，可以被不法分子利用，危害用戶的安全，4.2 之后，Android引入新的接口?
@JavascriptInterface以解決安全問(wèn)題,所以 Android 注入對(duì)對(duì)象的方式是有兼容性問(wèn)題的。
方式2：攔截 URL SCHEME
URL SCHEME是一種類似于url的鏈接，是為了方便app直接互相調(diào)用設(shè)計(jì)的，形式和普通的 url 近似，主要區(qū)別是 protocol 和 host 一般是自定義的，例如:?qunarhy://hy/url?url=ymfe.tech，protocol 是 qunarhy，host 則是 hy。
攔截 URL SCHEME 的主要流程是：Web 端通過(guò)某種方式（例如 iframe.src）發(fā)送 URL Scheme 請(qǐng)求，之后 Native 攔截到請(qǐng)求并根據(jù) URL SCHEME（包括所帶的參數(shù)）進(jìn)行相關(guān)操作。
在實(shí)踐過(guò)程中，這種方式有一定的缺陷：
使用 iframe.src 發(fā)送 URL SCHEME 會(huì)有 url 長(zhǎng)度的隱患。
創(chuàng)建請(qǐng)求，需要一定的耗時(shí)，比注入 API 的方式調(diào)用同樣的功能，耗時(shí)會(huì)較長(zhǎng)。
但是這種方式的最重要優(yōu)勢(shì)是跨平臺(tái)兼容性，尤其是支持 iOS6，但考慮到終端覆蓋率，已經(jīng)不是主流方式。
方式3：重寫(xiě) prompt 等原生 JS 方法
WebView有一個(gè)方法，叫setWebChromeClient，可以設(shè)置WebChromeClient對(duì)象，而這個(gè)對(duì)象中有三個(gè)方法，分別是onJsAlert,onJsConfirm,onJsPrompt，當(dāng)js調(diào)用window對(duì)象的對(duì)應(yīng)的方法，即window.alert，window.confirm，window.prompt，WebChromeClient對(duì)象中的三個(gè)方法對(duì)應(yīng)的就會(huì)被觸發(fā)，我們是不是可以利用這個(gè)機(jī)制，自己做一些處理呢？答案是肯定的。
由于攔截上述方法會(huì)對(duì)性能造成一定影響，因此需要選擇使用頻率較低的方法，而在Android中，相比其它幾個(gè)方法，幾乎不會(huì)使用到prompt方法，因此占用prompt是最佳方案。
-? ? ?Native 調(diào)用 JS? ? -
Native 調(diào)用 JS 比較簡(jiǎn)單，只要 H5 將 JS 方法暴露在 Window 上給 Native 調(diào)用即可。
Android 中主要有兩種方式實(shí)現(xiàn)。
在 4.4 以前，通過(guò)?
loadUrl?方法，執(zhí)行一段 JS 代碼來(lái)實(shí)現(xiàn)。
loadUrl 方法使用起來(lái)方便簡(jiǎn)潔，但是效率低無(wú)法獲得返回結(jié)果且調(diào)用的時(shí)候會(huì)刷新 WebView 。在 4.4 以后，可以使用?
evaluateJavascript?方法實(shí)現(xiàn)。
該方法效率高獲取返回值方便，調(diào)用時(shí)候不刷新 WebView，但是只支持 Android 4.4+。
-? ? ?JSBridge 如何引用? ? -
對(duì)于 JSBridge 的引用，常用有兩種方式，各有利弊。
方式1：由 Native 端進(jìn)行注入
注入方式和 Native 調(diào)用 JavaScript 類似，直接執(zhí)行橋的全部代碼。
它的優(yōu)點(diǎn)在于：橋的版本很容易與 Native 保持一致，Native 端不用對(duì)不同版本的 JSBridge 進(jìn)行兼容；
它的缺點(diǎn)是：注入時(shí)機(jī)不確定，需要實(shí)現(xiàn)注入失敗后重試的機(jī)制，保證注入的成功率，同時(shí) JavaScript 端在調(diào)用接口時(shí)，需要優(yōu)先判斷 JSBridge 是否已經(jīng)注入成功。
方式2：由 JavaScript 端引用
與由 Native 端注入正好相反，它的優(yōu)點(diǎn)在于：JavaScript 端可以確定 JSBridge 的存在，直接調(diào)用即可；
缺點(diǎn)是：如果橋的實(shí)現(xiàn)方式有更改，JSBridge 需要兼容多版本的 Native Bridge 或者 Native Bridge 兼容多版本的 JSBridge。
作者：alex
來(lái)源：
https://blog.caogo.cn/2021/02/12/JSBridge%E6%8A%80%E6%9C%AF%E5%8E%9F%E7%90%86%E5%88%86%E6%9E%90/
