Hybrid 開發:JsBridge - Web 和客戶端的橋

三水清發表於2017-03-19

Hybrid開發中,web頁面往往會跟native進行互動,而JSBridge就是web頁面和native進行通訊的橋樑,通過JSBridge可以實現web呼叫native的方法,native可以通過webview.loadUrl之類的方法,將javascript:xxx程式碼放在頁面執行,這有點類似在瀏覽器位址列直接輸入:javascript:xxx

本文較長,先把目錄列出來:

  • JSBridge多種形式
    • js Interface 直接注入到window物件
    • 改寫瀏覽器原有物件:alert/console/prompt
    • URL scheme
  • 喚起APP技術
    • intent
    • localserver
    • scheme:deeplink/applink/Universal link
    • smart app banner
  • JSBridge安全
  • JSBridge的最佳實踐
    • 協議規範
    • 回撥函式
    • 預留升級/統計能力
    • 簡單JSBridge呼叫封裝

JSBridge多種形式

web和native進行通訊,方法有很多,接下來一一列舉一下JSBridge的多種形式,及其利弊。

JavaScriptInterface

JSInterface是安卓4.2-官方推薦的解決方案,原理是通過WebView提供的addJavascriptInterface方法給瀏覽器window注入一個名稱空間,然後給Web增加一些可以操作Java的反射。

// Android java程式碼
mWebView.addJavascriptInterface(new Class(), 'android');  

public class Class(){
  @JavascriptInterface
  public void method(){

  }
} 
// js 程式碼
window.android.method();複製程式碼

JSInterface在4.2之前的版本都可以,但是存在嚴重的安全隱患,容易被利用提權,從而呼叫各種Java的類和許可權,甚至頁面可以掛馬。在我們實際產品(手機百度)開始階段,用過這個方法,不過現在已經不使用了。

改寫瀏覽器原有物件

這個方法主要是通過修改原來瀏覽器的window某些方法,然後攔截固定規則的引數,然後分發給Java對應的方法去處理。這裡常用的是以下四個方法:

  • alert,可以被webview的onJsAlert監聽
  • confirm,可以被webview的onJsConfirm監聽
  • console.log,可以被webview的onConsoleMessage監聽
  • prompt,可以被webview的onJsPrompt監聽

prompt簡單舉例說明,Web頁面通過呼叫prompt()方法,安卓客戶端通過監聽onJsPrompt事件,攔截傳入的引數,如果引數符合一定協議規範,那麼就解析引數,扔給後續的Java去處理。這種協議規範,最好是跟iOS的協議規範一樣,這樣跨端調起協議是一致的,但具體實現不一樣而已。比如:hybrid://action?arg1=1 這樣的協議,而其他格式的prompt引數,是不會監聽的,即除了hybrid://action?arg1=1 這樣的規範協議,prompt還是原來的prompt

這四個方法也是各有利弊,比如:

  • alert/console.log是除錯最常用的,如果你要看看協議是不是寫錯了,但是傳入協議卻被攔截了。。
  • confirmprompt都帶返回值,prompt是四個裡面唯一可以自定義返回值,可以做同步的互動,要比寫各種回撥更「順」,但是一旦序列呼叫了,就要罵爹了

prompt是我們目前安卓用的比較多的JSBridge解決方案。

URL scheme

這個叫法不是特別貼切,scheme是URI的一種格式,上文提到的hybrid://action?arg1=1 就是一個scheme協議,這裡說的scheme(或者schema)泛指安卓和iOS的schema協議,因為它通用。

安卓和iOS都可以通過攔截跳頁URL請求,然後解析這個scheme協議,符合約定規則的就扔個Native的方法處理。安卓和iOS分別用到攔截URL請求的方法是:

  • 安卓:shouldOverrideUrlLoading方法
  • iOS:UIWebView的delegate函式

喚起APP技術

上文介紹到的JSBridge是在APP內的Web頁面跟APP進行交換,還有一種特別多的需求,就是在APP外(瀏覽器、微信等)調起APP自己,給APP進行導流。這時候就要用到APP的喚起技術。這裡有一下幾種方法:

  • intent:安卓
  • localserver:安卓
  • Universal links:iOS 9+
  • Deep link/Applink:安卓
  • smart app banner:iOS

安卓intent

intent格式示例如下:

intent:
   HOST/URI-path // Optional host 
   #Intent; 
      package=[string]; 
      action=[string]; 
      category=[string]; 
      component=[string]; 
      scheme=[string]; 
      S.xxx=xxx
   end;複製程式碼
  • 第一部分:host和path是跟url無異
  • 第二部分:#intent到end是完整的intent,包含了調起的app包名,action等是常用的配置項

因為Intent不僅僅是調起APP,而是安卓客戶端內部模組通訊也會用,所以許可權很大,一般瀏覽器都給封掉了,?

安卓localserver

這是一個黑科技?,早前安卓允許在本地啟動一個本地server,這個server是在後臺守候的,通過這個localserver都可以進行各種需求:app間通訊、app調起、收集資料、基礎服務。百度的moplus就是這樣的一個localserver。

舉例說明:啟動一個本地server,埠號是:8888,那麼在手機上,網頁就可以通過:http://127.0.0.1:8888 訪問這個server,server接收到請求就可以進行一些native的操作,對於需要回撥資料的,就通過返回請求內容來執行,比如:

  1. 獲取個定位資訊,js執行$.get('http://127.0.0.1:8888/getGeoLocation?callback=cbname')
  2. server收到請求之後,呼叫native方法,獲取GPS的定位資訊,然後將資料通過response:window.cbname&&cbname({xxx})給頁面返回定位資料

如果控制不好許可權,因為localserver是一直後臺守候的,容易被利用,比如提權獲取通訊錄、甚至給通訊錄發簡訊、容易造成蠕蟲攻擊,感興趣的可以搜下moplus的文章。另外安卓各種安全軟體,都會清理記憶體和後臺程式,很容易被幹掉程式。瀏覽器也會封殺本地server調起,碰見127.0.0.1的請求就直接攔截。

這三個是官方推薦的調起方法,調起協議格式也是可以統一的,比如前文提到的hybrid://action?arg1=xxx這類scheme協議就是。這樣可以統一安卓和iOS調起和JSBridge通訊。

其實簡單來說,這三個出發點是想給應用做分發,但是如果使用者手機沒有安裝這個APP,那麼就調起失敗,這時候直接不管不問,肯定體驗不好,而且浪費了點選資源,那麼做成分發吧!將調起協議做成一個調起頁面,放到一個域名下,點選這個URL就可以開啟這個頁面,頁面執行程式碼調起APP,如果調起失敗就展現APP的介紹,做分發。

Universal links / Deep link / Applink,就是這樣的一個過程,通過這個域名授權,把URL分發給APP進行處理,唯一不同的是:如果使用者安裝了APP,那麼就不用開啟這個分發頁面了。

iOS 9新出的一個功能,需要在App內宣告一個https域名(ul.test.com),然後在該網站根目錄放置apple-app-site-association檔案,檔案指明瞭轉發規則,例如:

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": “xxx.com.baidu.SomeApp”,
        "paths": ["*"]
      }
    ]
  }
}複製程式碼

當APP安裝成功之後,會下載這個檔案,明確知道遇見ul.test.com的域名的URL時候,會把這個URL扔給你的APP,讓你去解析,APP拿到這個URL就可以解析出來需要做什麼事情。

Universal Link是iOS 9+的底層實現,所以在任何地方都可以直接調起APP,不受微信這類封閉APP的限制。

Deep link 是安卓一開始推出的,主要用於搜尋調起APP,後來推出 Applink,實際是Deep link的升級版。

這裡需要提到微信的APPlink,畢竟微信作為SuperApp,是很大的分發資源,微信有自己的分發方法,安卓內可以申請微信的APPlink,跟Universal link一樣,也是一個域名下面的URL,符合一定規則就由微信(ios是底層系統)扔個對應的域名APP進行解析。

smart app banner

在頁面的head中新增下面meta,在Safari瀏覽器中就會出現下面的banner

<meta name="apple-itunes-app" content="app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL">複製程式碼

Hybrid 開發:JsBridge - Web 和客戶端的橋

JSBridge安全

在APP內JSBridge可以實現Web和Native的通訊,但是如果APP開啟一個惡意的頁面,頁面可以任意呼叫JSBridge方法,獲取各種隱私的資料,就會引起安全問題。

JSBridge的安全有兩個方法:通過Native進行白名單配置,通過Server雲端授權。Server的雲端授權這塊,放到後續JSSDK的設計部分進行詳細講解。本文主要說下通過Native的方式來控制JSBridge的安全。

假設JSBridge的協議格式如下:

hybrid://action/method?arg1=xxx&arg2=xxx複製程式碼

可以通過下面方式進行安全設定:

  1. 配置某些方法的使用範圍,比如固定的Webview,固定的domain
  2. 通過正則來設定細化的許可權,比如:baidu.com網頁可以使用*,hao123.com可以使用:hybrid://hao123/*

JSBridge的最佳實踐

介紹了這麼多,什麼是最佳實踐的JSBridge呢?結合文章內容,要求JSBridge做到以下幾點:

  • 官方認可,不走「歪門邪道」
  • 跨平臺通用
  • APP內和APP外規範通用
  • 安全可靠
  • 約定大於配置的原則

綜合上文介紹的內容,JSBridge的最佳實踐是:

  1. 協議規範都使用:hybrid://action/method?arg1=xxx&arg2=xxx
  2. iOS使用Universal Link和UIWebview的delegate
  3. 安卓使用shouldOverrideUrlLoading和Applink

規範和約定

先貼個URL scheme的圖片,理解下URL的組成部分:

Hybrid 開發:JsBridge - Web 和客戶端的橋

約定我們的規範如下:

yourappscheme://module/action?arg1=x&arg2=x&ios_version=xxx&andr_version=xxx&upgrade=1/0&callback=xxx&sendlog=1/0複製程式碼
  • 整體小寫
  • yourappscheme:就是你的scheme,可辨識,別衝突,通過這個可以進行Universal Link和Applink的分發
  • module和action:某個模組元件的某個方法
  • ?後面是querystring,這裡預定了幾個特殊的引數:
    • ios_version/andr_version:非必須,iOS和安卓的最小版本,即本協議從哪個版本開始支援的,低版本不支援則忽略,配合upgrade使用進行APP升級
    • upgrade:是否強制升級,即當版本低於設定的ios/andr_version是否彈出提示使用者升級的對話方塊(yourappscheme已經可以調起app,只不過功能可能因為版本低不支援,這時候可以引導使用者升級)
    • callback:非同步回撥函式,下面詳細樹下callback的最佳實踐
    • sendlog:調起後是否打點傳送日誌

舉例:

# 賬號相關
## 開啟使用者個人主頁
fb://account/userprofile?id=xxx
## 開啟登入介面
fb://account/login?callback=xxx
# 工具類
## 獲取定位
fb://utils/getgeolocation?callback=xx複製程式碼

callback的設計

當native操作成功之後,會將處理結束後的結果或者資料通過callback回撥傳給Web,當然有成果就又失敗,callback的引數設計有兩種方式:

錯誤優先

即下面的回撥方法格式:

function callback(error, data){
  if(error){
    throw error
  }
  console.log(data)
}複製程式碼
JSON API式

即回撥方法只接收一個JSON物件,JSON格式如下:

{
  error_code: 0,
  data: {}
}複製程式碼

預留升級/日誌能力

做APP開發經常會遇見下面的問題:

  1. 功能/端能力是從某個版本開始的,低版本用不了,但是scheme還是會調起APP(APP懵逼。。
  2. 對於低版本,PM希望提示使用者升級
  3. 統計調起成功率,分發次數之類的統計需求

scheme的querystring部分由 ios_version/andr_version和upgrade這三個成對的引數,可以解決升級問題,sendlog解決日誌統計問題。

  • ios_version/andr_version:是標示該協議的最低支援版本,如果低於這個版本可能因為功能並未實現而能識別。
  • upgrade:是是否強制低版本彈出升級對話方塊
  • sendlog:當為1的時候,則傳送調起成功失敗之類的統計需求

簡單JSBridge呼叫封裝

簡單封裝下JSBridge呼叫的方法,引數如下:

  • module:類名稱,如果account
  • action:具體操作方法,如login
  • args:非必須,協議引數,支援string和物件
  • callback:非必須,回撥單獨提出來,方便全域性方法命名

具體程式碼如下

function invoke (module, action, args, callback) {
  let scheme = `yourappscheme://${module}/${action}?`
  if (isFunction(args)) {
    callback = args
    args = null
  }
  // 處理下引數
  if (isString(args)) {
    scheme += args
  } else if (isObject(args)) {
    each(args, (k, v) => {
      if (isObject(v) || isArray(v)) {
        v = JSON.stringify(v)
      }
      scheme += `${k}=${v}`
    })
  }
  // callback獨立傳,方便全域性函式名命名
  if (isFunction(callback)) {
    var funcName = '_jsbridge_cb_' + getId()
    window[funcName] = function () {
      callback.apply(window, ([]).slice.call(arguments, 0))
    }
    scheme += (!~scheme.indexOf('?') ? '&' : '?') + `callback=${funcName}`
  }

  if (os.ios && versionCompare(os.version, '9.0') >= 0) {
    window.location.href = scheme
  } else {
    var $node = document.createElement('iframe')
    $node.style.display = 'none'
    $node.src = scheme
    var body = document.body || document.getElementsByTagName('body')[0]
    body.appendChild($node)
    setTimeout(function () {
      body.removeChild($node)
      $node = null
    }, 10)
  } 
}複製程式碼

打完收工

今天寫的有點多,介紹了JSBridge常用的方法,然後介紹了APP外如何喚起APP,還介紹了scheme協議,最後比較了優缺點,做個最佳實踐。希望有用~

--eof--
@三水清
未經允許,請勿轉載
本文使用MPEditor(js8.in/mpeditor)編輯…

感覺有用,歡迎關注我的公眾號

Hybrid 開發:JsBridge - Web 和客戶端的橋
關注三水清

相關文章