各種 JsBridge 調用效率的對比
以前在項目中需要實現一個在在WebView的H5頁面中點擊一個關鍵字跳轉到Native端的指定頁面的功能。當時Google了一下就采用了重載ShouldOverrideUrlLoading方法來實現這個功能。后來要優(yōu)化這一部分的功能，就專門用了一段時間來做了一些測試，對比?，F在把數據和結論放上來給大家參考參考。
現在大家常用的Web頁面和Native端通信的方式大概有6種，下面會針對這6種方式做下性能測試來選出最優(yōu)方案。
參測機型與系統版本：
- Moto Nexus6 OS:6.0.1
- 魅族3S OS:5.1.1
- 紅米1 OS:4.2.2
測試用例：
在 web 頁面上發(fā)起請求時記下當前的時間t,并通過 JsBridge偽協議將時間 t 傳遞給 Native端，Native端收到請求時記錄下當前系統時間t2。將t2-t所得的時候就是這次 web 端和 Native端通信的耗時。同樣操作執(zhí)行20次，通過平均時間來比較性能。
測試函數
1.ShouldOverrideUrlLoading
頁面請求代碼：
Native端通過重載ShouldOverrideUrlLoading方法進行攔截主資源請求，解析 JsBridge偽協議來獲得相關數據。
2.ShouldInterceptRequest
頁面請求代碼：
Native端通過重載ShouldInterceptRequest方法進行攔截子資源請求，解析 JsBridge偽協議來獲得相關數據。
Android 5.0以下系統版本提供的攔截方法：
Android 5.0及以上系統版本提供的攔截方法可以獲得更為豐富的頁面信息。在WebResourceRequest有如下方法：getUrl()，isForMainFrame(),hasGesture(),getMethod(),getRequestHeaders()；其中getRequestHeaders()方法可以獲得的請求信息最多了。
3.Prompt方式
頁面請求代碼：
Native端重寫WebChromeClient的onJsPrompt方法拉處理偽協議請求：
4.Alert方式
頁面請求代碼：
Native端重寫WebChromeClient的onJsAlert方法拉處理偽協議請求：
5.Confirm方式
頁面請求代碼：
Native端重寫WebChromeClient的onJsConfirm方法拉處理偽協議請求：
6.Console方式
頁面請求代碼：
Native端重寫WebChromeClient的onConsoleMessage方法拉處理偽協議請求：
測試結果
數據如下圖：
測試結論
對比上圖數據，我們發(fā)現使用Confirm方式基本上是耗時最短和最穩(wěn)定的。如果你不需要更詳細的 web 端的信息，使用Confirm方式是性能最好的。但是如果你需要讀取 web 端的請求頭信息，以及是否是主 frame 發(fā)起的請求，你就必須使用子資源攔截方式（intercept方式）了。這些豐富的請求信息對以后權限控制拓展是必須的。
關于addJavascriptInterface
這篇文章從一開始就沒打算把 addJavascriptInterface 方式添加到對比的數據中，因為它在 Android4.2 之前的版本存在嚴重的安全漏洞。谷歌在 Android4.2 之后的版本才通過添加 @JavascriptInterface 注解的方式解決了該問題。這兩天又換了個角度思考了一下，該方式作為谷歌官方的 Webview 和 JavaScript 解決方案，肯定會比其他交互方式優(yōu)秀的地方。歷史的車輪滾滾向前，目前大多數用戶的系統版本都集中在4.4.2以上了，所以今天還是把這個方式做了個測試。測試數據也證實我的猜測，其時間間隔是最短的。所以，如果你的 App 只打算支持 Android4.2 版本以上的，就可以考慮這個官方解決方案了。
下集預告
下一篇會寫基于Confirm方式以及intercept方式的完整的 JS 交互，即包含了 Native調用 web 端的方法。
下篇已出，Android WebView：我是怎么和 JavaScript 互撩的？
