現(xiàn)在市面上App，迭代變更比較頻繁，為了滿足業(yè)務(wù)需求，基本上都采用了Hybrid混編，來實(shí)現(xiàn)業(yè)務(wù)的快速上下線。H5靈活開發(fā)的特點(diǎn)和線上熱更新的機(jī)制是非常適合業(yè)務(wù)頻繁迭代的，我們需要一套完整的Hybrid技術(shù)架構(gòu)方案來充分利用 H5 強(qiáng)大的開發(fā)和迭代能力，又能賦予 H5 強(qiáng)大的底層能力和用戶體驗(yàn)，同時(shí)能復(fù)用現(xiàn)有的成熟 Native組件。

Hybrid技術(shù)原理

Hybrid 最核心的點(diǎn)就是如何處理 Native端 與 H5端 之間的雙向通訊層，其實(shí)這里也可以理解為我們需要一套跨語言通訊方案，來完成 Native(Java/Objective-c/…) 與 JavaScript 的通訊。也就是我們所說的 JSBridge。Hybrid App 實(shí)現(xiàn)的關(guān)鍵就是作為容器的Webview,使用WebView 作為容器直接承載 Web頁面。

Web容器是連接Native和H5的紐帶，這里又分為JavaScript 給Native發(fā)通知和Native通知JavaScript。

JavaScript 通知Native

• API注入，原理其實(shí)就是 Native 獲取 JavaScript環(huán)境上下文，并直接在上面掛載對象或者方法，使 js 可以直接調(diào)用，Android 與 IOS 分別擁有對應(yīng)的掛載方式。
• WebView 中的 prompt/console/alert 攔截，通常使用 prompt，因?yàn)檫@個(gè)方法在前端中使用頻率低，比較不會出現(xiàn)沖突；
• WebView URL Scheme 跳轉(zhuǎn)攔截

第二三種機(jī)制的原理是類似的，都是通過對 WebView 信息傳遞的攔截，從而達(dá)到通訊的，接下來我們主要從 原理-定制協(xié)議-攔截協(xié)議-參數(shù)傳遞-回調(diào)機(jī)制 5個(gè)方面詳細(xì)闡述下第三種方案 – URL攔截方案。

實(shí)現(xiàn)原理

在 WebView 中發(fā)出的網(wǎng)絡(luò)請求，客戶端都能進(jìn)行監(jiān)聽和捕獲

協(xié)議的定制

我們需要制定一套URL Scheme規(guī)則，通常我們的請求會帶有對應(yīng)的協(xié)議開頭，例如常見的 https://xxx.com 或者 file://1.jpg，代表著不同的含義。我們這里可以將協(xié)議類型的請求定制為:

xxcommand://xxxx?param1=1&param2=2
這里有幾個(gè)需要注意點(diǎn)的是:

(1) xxcommand:// 只是一種規(guī)則，可以根據(jù)業(yè)務(wù)進(jìn)行制定，使其具有含義，例如我們定義 xxcommand:// 為公司所有App系通用，為通用工具協(xié)議：

xxcommand://getProxy?h=1
而定義 xxapp:// 為每個(gè)App單獨(dú)的業(yè)務(wù)協(xié)議。

xxapp://openCamera?h=2
不同的協(xié)議頭代表著不同的含義，這樣便能清楚知道每個(gè)協(xié)議的適用范圍。

(2) 這里不要使用 location.href 發(fā)送，因?yàn)槠渥陨頇C(jī)制有個(gè)問題是同時(shí)并發(fā)多次請求會被合并成為一次，導(dǎo)致協(xié)議被忽略，而并發(fā)協(xié)議其實(shí)是非常常見的功能。我們會使用創(chuàng)建 iframe 發(fā)送請求的方式。

(3) 通常考慮到安全性，需要在客戶端中設(shè)置域名白名單或者限制，避免公司內(nèi)部業(yè)務(wù)協(xié)議被第三方直接調(diào)用。

協(xié)議的攔截

客戶端可以通過 API 對 WebView 發(fā)出的請求進(jìn)行攔截：

IOS上: shouldStartLoadWithRequest
Android: shouldOverrideUrlLoading
當(dāng)解析到請求 URL 頭為制定的協(xié)議時(shí)，便不發(fā)起對應(yīng)的資源請求，而是解析參數(shù)，并進(jìn)行相關(guān)功能或者方法的調(diào)用，完成協(xié)議功能的映射。

協(xié)議回調(diào)

由于協(xié)議的本質(zhì)其實(shí)是發(fā)送請求，這屬于一個(gè)異步的過程，因此我們便需要處理對應(yīng)的回調(diào)機(jī)制。這里我們采用的方式是JS的事件系統(tǒng)，這里我們會用到 window.addEventListener 和 window.dispatchEvent這兩個(gè)基礎(chǔ)API；

發(fā)送協(xié)議時(shí)，通過協(xié)議的唯一標(biāo)識注冊自定義事件，并將回調(diào)綁定到對應(yīng)的事件上。
客戶端完成對應(yīng)的功能后，調(diào)用 Bridge 的dispatch API，直接攜帶 data 觸發(fā)該協(xié)議的自定義事件。
通過事件的機(jī)制，會讓開發(fā)更符合我們前端的習(xí)慣，例如當(dāng)你需要監(jiān)聽客戶端的通知時(shí)，同樣只需要在通過 addEventListener 進(jìn)行監(jiān)聽即可。

Tips: 這里有一點(diǎn)需要注意的是，應(yīng)該避免事件的多次重復(fù)綁定，因此當(dāng)唯一標(biāo)識重置時(shí)，需要removeEventListener對應(yīng)的事件。

參數(shù)傳遞方式

由于 WebView 對 URL 會有長度的限制，因此常規(guī)的通過 search參數(shù) 進(jìn)行傳遞的方式便具有一個(gè)問題，既 當(dāng)需要傳遞的參數(shù)過長時(shí)，可能會導(dǎo)致被截?cái)?#xff0c;例如傳遞base64或者傳遞大量數(shù)據(jù)時(shí)。

因此我們需要制定新的參數(shù)傳遞規(guī)則，我們使用的是函數(shù)調(diào)用的方式。這里的原理主要是基于:

Native 可以直接調(diào)用 JS 方法并直接獲取函數(shù)的返回值。
我們只需要對每條協(xié)議標(biāo)記一個(gè)唯一標(biāo)識，并把參數(shù)存入?yún)?shù)池中，到時(shí)客戶端再通過該唯一標(biāo)識從參數(shù)池中獲取對應(yīng)的參數(shù)即可。

Native 通知 Javascript
由于 Native 可以算作 H5 的宿主，因此擁有更大的權(quán)限，上面也提到了 Native 可以通過 WebView API直接執(zhí)行 Js 代碼。這樣的權(quán)限也就讓這個(gè)方向的通訊變得十分的便捷。

IOS: stringByEvaluatingJavaScriptFromString// Swift webview.stringByEvaluatingJavaScriptFromString("alert('NativeCall')")

Android: loadUrl (4.4-)
// 調(diào)用js中的JSBridge.trigger方法
// 該方法的弊端是無法獲取函數(shù)返回值；

webView.loadUrl("javascript:JSBridge.trigger('NativeCall')")

Tips: 當(dāng)系統(tǒng)低于4.4時(shí)，evaluateJavascript 是無法使用的，因此單純的使用 loadUrl 無法獲取 JS 返回值，這時(shí)我們需要使用前面提到的 prompt 的方法進(jìn)行兼容，讓 H5端 通過 prompt 進(jìn)行數(shù)據(jù)的發(fā)送，客戶端進(jìn)行攔截并獲取數(shù)據(jù)。

Android: evaluateJavascript (4.4+)
// 4.4+后使用該方法便可調(diào)用并獲取函數(shù)返回值；

mWebView.evaluateJavascript（"javascript:JSBridge.trigger('NativeCall')", new ValueCallback<String>() {@Overridepublic void onReceiveValue(String value) {//此處為 js 返回的結(jié)果} });

基于上面的原理，我們已經(jīng)明白 JSBridge 最基礎(chǔ)的原理，并且能實(shí)現(xiàn) Native <=> H5 的雙向通訊機(jī)制了。

JSBridge 的接入

接下來，我們來理下代碼上需要的資源。實(shí)現(xiàn)這套方案，從上圖可以看出，其實(shí)可以分為兩個(gè)部分:

JS部分(bridge): 在JS環(huán)境中注入 bridge 的實(shí)現(xiàn)代碼，包含了協(xié)議的拼裝/發(fā)送/參數(shù)池/回調(diào)池等一些基礎(chǔ)功能。
Native部分(SDK)：在客戶端中 bridge 的功能映射代碼，實(shí)現(xiàn)了URL攔截與解析/環(huán)境信息的注入/通用功能映射等功能。
我們這里的做法是，將這兩部分一起封裝成一個(gè) Native SDK，由客戶端統(tǒng)一引入。客戶端在初始化一個(gè) WebView 打開頁面時(shí)，如果頁面地址在白名單中，會直接在 HTML 的頭部注入對應(yīng)的 bridge.js。這樣的做法有以下的好處：

雙方的代碼統(tǒng)一維護(hù)，避免出現(xiàn)版本分裂的情況。有更新時(shí)，只要由客戶端更新SDK即可，不會出現(xiàn)版本兼容的問題；
App的接入十分方便，只需要按文檔接入最新版本的SDK，即可直接運(yùn)行整套Hybrid方案，便于在多個(gè)App中快速的落地；
H5端無需關(guān)注，這樣有利于將 bridge 開放給第三方頁面使用。
這里有一點(diǎn)需要注意的是，協(xié)議的調(diào)用，一定是需要確保執(zhí)行在bridge.js 成功注入后。由于客戶端的注入行為屬于一個(gè)附加的異步行為，從H5方很難去捕捉準(zhǔn)確的完成時(shí)機(jī)，因此這里需要通過客戶端監(jiān)聽頁面完成后，基于上面的回調(diào)機(jī)制通知 H5端，頁面中即可通過window.addEventListener(‘bridgeReady’, e => {})進(jìn)行初始化。

App中 H5 的接入方式

將 H5 接入 App 中通常有兩種方式：

(1) 在線H5，這是最常見的一種方式。我們只需要將H5代碼部署到服務(wù)器上，只要把對應(yīng)的 URL地址 給到客戶端，用 WebView 打開該URL，即可嵌入。該方式的好處在于:

獨(dú)立性強(qiáng)，有非常獨(dú)立的開發(fā)/調(diào)試/更新/上線能力；資源放在服務(wù)器上，完全不會影響客戶端的包體積；接入成本很低，完全的熱更新機(jī)制。

但相對的，這種方式也有對應(yīng)的缺點(diǎn):
完全的網(wǎng)絡(luò)依賴，在離線的情況下無法打開頁面；
首屏加載速度依賴于網(wǎng)絡(luò)，網(wǎng)絡(luò)較慢時(shí)，首屏加載也較慢；
通常，這種方式更適用在一些比較輕量級的頁面上，例如一些幫助頁、提示頁、使用攻略等頁面。這些頁面的特點(diǎn)是功能性不強(qiáng)，不太需要復(fù)雜的功能協(xié)議，且不需要離線使用。在一些第三方頁面接入上，也會使用這種方式，例如我們的頁面調(diào)用微信JS-SDK。

(2) 內(nèi)置包H5，這是一種本地化的嵌入方式，我們需要將代碼進(jìn)行打包后下發(fā)到客戶端，并由客戶端直接解壓到本地儲存中。通常我們運(yùn)用在一些比較大和比較重要的模塊上。

其優(yōu)點(diǎn)是:
由于其本地化，首屏加載速度快，用戶體驗(yàn)更為接近原生；可以不依賴網(wǎng)絡(luò)，離線運(yùn)行；
但同時(shí)，它的劣勢也十分明顯:
開發(fā)流程/更新機(jī)制復(fù)雜化，需要客戶端，甚至服務(wù)端的共同協(xié)作；會相應(yīng)的增加 App 包體積；
這兩種接入方式均有自己的優(yōu)缺點(diǎn)，應(yīng)該根據(jù)不同場景進(jìn)行選擇。

參考自：https://segmentfault.com/a/1190000015678155
Android：WebView與Javascript交互（相互調(diào)用參數(shù)、傳值）

如果你也熱衷技術(shù)歡迎加群一起進(jìn)步：230274309 。 一起分享，一起進(jìn)步！少劃水，多曬干貨！！歡迎大家！！！(進(jìn)群潛水者勿加)

點(diǎn)擊鏈接加入群聊【編程之美】：https://jq.qq.com/?_wv=1027&k=h75BfFCg

或者掃碼

總結(jié)

以上是生活随笔為你收集整理的Hybrid App实现原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。