Hybrid App技術解析 -- 原理篇

郭東東發表於2018-07-19

引言

隨著 Web 技術和移動裝置的快速發展,Hybrid 技術已經成為一種最主流最常見的方案。一套好的 Hybrid架構方案 能讓 App 既能擁有極致的體驗和效能,同時也能擁有 Web技術 靈活的開發模式、跨平臺能力以及熱更新機制,想想是不是都雞凍不已。。?。本系列文章是公司在這方面實踐的一個總結,包含了原理解析、方案選型與實現、實踐優化等方面。

大家可以到github上和我進行討論哈!

第二篇實戰篇

現有混合方案

Hybrid App,俗稱混合應用,即混合了 Native技術 與 Web技術 進行開發的移動應用。現在比較流行的混合方案主要有三種,主要是在UI渲染機制上的不同:

  1. 基於 WebView UI 的基礎方案,市面上大部分主流 App 都有采用,例如微信JS-SDK,通過 JSBridge 完成 H5 與 Native 的雙向通訊,從而賦予H5一定程度的原生能力。

  2. 基於 Native UI 的方案,例如 React-Native、Weex。在賦予 H5 原生API能力的基礎上,進一步通過 JSBridge 將js解析成的虛擬節點樹(Virtual DOM)傳遞到 Native 並使用原生渲染。

  3. 另外還有近期比較流行的小程式方案,也是通過更加定製化的 JSBridge,並使用雙 WebView 雙執行緒的模式隔離了JS邏輯與UI渲染,形成了特殊的開發模式,加強了 H5 與 Native 混合程度,提高了頁面效能及開發體驗。

以上的三種方案,其實同樣都是基於 JSBridge 完成的通訊層,第二三種方案,其實可以看做是在方案一的基礎上,繼續通過不同的新技術進一步提高了應用的混合程度。因此,JSBridge 也是整個混合應用最關鍵的部分,例如我們在設定微信分享時用到的 JS-SDK,wx物件 便是我們最常見的 JSBridge:

Hybrid App技術解析 -- 原理篇

方案選型

任何技術方案的選型,其實都應該基於使用場景和現有條件。基於公司現有情況的幾點考慮,在方案一上進一步優化,更加適合我們的需求。

  • 需求 Web技術 快速迭代、靈活開發的特點和線上熱更新的機制。

  • 產品的核心能力是強大的拍照與底層圖片處理能力,因此單純的 H5技術能做的事非常有限,不能滿足需求,通過 Hybrid 技術來強化H5,便是一種必需。

  • 公司業務上,並沒有非常複雜的UI渲染需求,而且 App 中的一系列原生 UI元件 已經非常成熟,因此我們並不強需類似 RN 這樣的方案。

因此,如何既能利用 H5 強大的開發和迭代能力,又能賦予 H5 強大的底層能力和使用者體驗,同時能複用現有的成熟 Native元件,便成為了我們最大的需求點 -- 一套完整又強大的 Hybrid技術架構方案。?

Hybrid技術原理

Hybrid App的本質,其實是在原生的 App 中,使用 WebView 作為容器直接承載 Web頁面。因此,最核心的點就是 Native端 與 H5端 之間的雙向通訊層,其實這裡也可以理解為我們需要一套跨語言通訊方案,來完成 Native(Java/Objective-c/...) 與 JavaScript 的通訊。這個方案就是我們所說的 JSBridge,而實現的關鍵便是作為容器的 WebView,一切的原理都是基於 WebView 的機制。

Hybrid App技術解析 -- 原理篇

(一) JavaScript 通知 Native

基於 WebView 的機制和開放的 API, 實現這個功能有三種常見的方案:

  • API注入,原理其實就是 Native 獲取 JavaScript環境上下文,並直接在上面掛載物件或者方法,使 js 可以直接呼叫,Android 與 IOS 分別擁有對應的掛載方式。

  • WebView 中的 prompt/console/alert 攔截,通常使用 prompt,因為這個方法在前端中使用頻率低,比較不會出現衝突;

  • WebView URL Scheme 跳轉攔截

第二三種機制的原理是類似的,都是通過對 WebView 資訊冒泡傳遞的攔截,從而達到通訊的,接下來我們主要從 原理-定製協議-攔截協議-引數傳遞-回撥機制 5個方面詳細闡述下第三種方案 -- URL攔截方案。

1. 實現原理

在 WebView 中發出的網路請求,客戶端都能進行監聽和捕獲

2. 協議的定製

我們需要制定一套URL Scheme規則,通常我們的請求會帶有對應的協議開頭,例如常見的 xxx.com 或者 file://1.jpg,代表著不同的含義。我們這裡可以將協議型別的請求定製為:

xxcommand://xxxx?param1=1&param2=2

這裡有幾個需要注意點的是:

(1) xxcommand:// 只是一種規則,可以根據業務進行制定,使其具有含義,例如我們定義 xxcommand:// 為公司所有App系通用,為通用工具協議:

xxcommand://getProxy?h=1

而定義 xxapp:// 為每個App單獨的業務協議。

xxapp://openCamera?h=2

不同的協議頭代表著不同的含義,這樣便能清楚知道每個協議的適用範圍。

(2) 這裡不要使用 location.href 傳送,因為其自身機制有個問題是同時併發多次請求會被合併成為一次,導致協議被忽略,而併發協議其實是非常常見的功能。我們會使用建立 iframe 傳送請求的方式。

(3) 通常考慮到安全性,需要在客戶端中設定域名白名單或者限制,避免公司內部業務協議被第三方直接呼叫。

3.協議的攔截

客戶端可以通過 API 對 WebView 發出的請求進行攔截:

  • IOS上: shouldStartLoadWithRequest

  • Android: shouldOverrideUrlLoading

當解析到請求 URL 頭為制定的協議時,便不發起對應的資源請求,而是解析引數,並進行相關功能或者方法的呼叫,完成協議功能的對映。

4.協議回撥

由於協議的本質其實是傳送請求,這屬於一個非同步的過程,因此我們便需要處理對應的回撥機制。這裡我們採用的方式是JS的事件系統,這裡我們會用到 window.addEventListenerwindow.dispatchEvent這兩個基礎API;

  • 1.傳送協議時,通過協議的唯一標識註冊自定義事件,並將回撥繫結到對應的事件上。

  • 2.客戶端完成對應的功能後,呼叫 Bridge 的dispatch API,直接攜帶 data 觸發該協議的自定義事件。

Hybrid App技術解析 -- 原理篇

通過事件的機制,會讓開發更符合我們前端的習慣,例如當你需要監聽客戶端的通知時,同樣只需要在通過 addEventListener 進行監聽即可。

Tips: 這裡有一點需要注意的是,應該避免事件的多次重複繫結,因此當唯一標識重置時,需要removeEventListener對應的事件。

5.引數傳遞方式

由於 WebView 對 URL 會有長度的限制,因此常規的通過 search引數 進行傳遞的方式便具有一個問題,既 當需要傳遞的引數過長時,可能會導致被截斷,例如傳遞base64或者傳遞大量資料時。

因此我們需要制定新的引數傳遞規則,我們使用的是函式呼叫的方式。這裡的原理主要是基於:

Native 可以直接呼叫 JS 方法並直接獲取函式的返回值。

我們只需要對每條協議標記一個唯一標識,並把引數存入引數池中,到時客戶端再通過該唯一標識從引數池中獲取對應的引數即可。

(二) Native 通知 Javascript

由於 Native 可以算作 H5 的宿主,因此擁有更大的許可權,上面也提到了 Native 可以通過 WebView API直接執行 Js 程式碼。這樣的許可權也就讓這個方向的通訊變得十分的便捷。

  • IOS: stringByEvaluatingJavaScriptFromString
// Swift
webview.stringByEvaluatingJavaScriptFromString("alert('NativeCall')")
複製程式碼
  • Android: loadUrl (4.4-)
// 呼叫js中的JSBridge.trigger方法
// 該方法的弊端是無法獲取函式返回值;
webView.loadUrl("javascript:JSBridge.trigger('NativeCall')")
複製程式碼

Tips: 當系統低於4.4時,evaluateJavascript 是無法使用的,因此單純的使用 loadUrl 無法獲取 JS 返回值,這時我們需要使用前面提到的 prompt 的方法進行相容,讓 H5端 通過 prompt 進行資料的傳送,客戶端進行攔截並獲取資料。

  • Android: evaluateJavascript (4.4+)
// 4.4+後使用該方法便可呼叫並獲取函式返回值;
mWebView.evaluateJavascript("javascript:JSBridge.trigger('NativeCall')", 	 new ValueCallback<String>() {
    @Override
    public void onReceiveValue(String value) {
        //此處為 js 返回的結果
    }
});
複製程式碼

基於上面的原理,我們已經明白 JSBridge 最基礎的原理,並且能實現 Native <=> H5 的雙向通訊機制了。

Hybrid App技術解析 -- 原理篇

(三) JSBridge 的接入

接下來,我們來理下程式碼上需要的資源。實現這套方案,從上圖可以看出,其實可以分為兩個部分:

  • JS部分(bridge): 在JS環境中注入 bridge 的實現程式碼,包含了協議的拼裝/傳送/引數池/回撥池等一些基礎功能。

  • Native部分(SDK): 在客戶端中 bridge 的功能對映程式碼,實現了URL攔截與解析/環境資訊的注入/通用功能對映等功能。

我們這裡的做法是,將這兩部分一起封裝成一個 Native SDK,由客戶端統一引入。客戶端在初始化一個 WebView 開啟頁面時,如果頁面地址在白名單中,會直接在 HTML 的頭部注入對應的 bridge.js。這樣的做法有以下的好處:

  • 雙方的程式碼統一維護,避免出現版本分裂的情況。有更新時,只要由客戶端更新SDK即可,不會出現版本相容的問題;

  • App的接入十分方便,只需要按文件接入最新版本的SDK,即可直接執行整套Hybrid方案,便於在多個App中快速的落地;

  • H5端無需關注,這樣有利於將 bridge 開放給第三方頁面使用。

這裡有一點需要注意的是,協議的呼叫,一定是需要確保執行在bridge.js 成功注入後。由於客戶端的注入行為屬於一個附加的非同步行為,從H5方很難去捕捉準確的完成時機,因此這裡需要通過客戶端監聽頁面完成後,基於上面的事件回撥機制通知 H5端,頁面中即可通過window.addEventListener('bridgeReady', e => {})進行初始化。

(四) App中 H5 的接入方式

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

(1) 線上H5,這是最常見的一種方式。我們只需要將H5程式碼部署到伺服器上,只要把對應的 URL地址 給到客戶端,用 WebView 開啟該URL,即可嵌入。該方式的好處在於:

  • 獨立性強,有非常獨立的開發/除錯/更新/上線能力;
  • 資源放在伺服器上,完全不會影響客戶端的包體積;
  • 接入成本很低,完全的熱更新機制。

但相對的,這種方式也有對應的缺點:

  • 完全的網路依賴,在離線的情況下無法開啟頁面;
  • 首屏載入速度依賴於網路,網路較慢時,首屏載入也較慢;

通常,這種方式更適用在一些比較輕量級的頁面上,例如一些幫助頁、提示頁、使用攻略等頁面。這些頁面的特點是功能性不強,不太需要複雜的功能協議,且不需要離線使用。在一些第三方頁面接入上,也會使用這種方式,例如我們的頁面呼叫微信JS-SDK。

(2) 內建包H5,這是一種本地化的嵌入方式,我們需要將程式碼進行打包後下發到客戶端,並由客戶端直接解壓到本地儲存中。通常我們運用在一些比較大和比較重要的模組上。其優點是:

  • 由於其本地化,首屏載入速度快,使用者體驗更為接近原生;
  • 可以不依賴網路,離線執行;

但同時,它的劣勢也十分明顯:

  • 開發流程/更新機制複雜化,需要客戶端,甚至服務端的共同協作;
  • 會相應的增加 App 包體積;

這兩種接入方式均有自己的優缺點,應該根據不同場景進行選擇。

總結

本文主要解析了現在Hybrid App的發展現狀和其基礎原理,包含了

  • JavaScript 通知 Native
  • Native 通知 Javascript
  • JSBridge 的接入
  • H5 的接入

只有在瞭解了其最本質的實現原理後,才能對這套方案進行實現以及進一步的優化。接下來,我們將基於上面的理論,繼續探討如何把這套方案的真正程式碼實現以及方案優化方案,請繼續第二篇實戰篇。歡迎大家一起討論!更多文章內容請關注下面公眾號或到github。感謝!?

Hybrid App技術解析 -- 原理篇

相關文章