各種 JsBridge 調用效率的對比
以前在項目中需要實現一個在在WebView的H5頁面中點擊一個關鍵字跳轉到Native端的指定頁面的功能。當時Google了一下就采用了重載ShouldOverrideUrlLoading方法來實現這個功能。后來要優化這一部分的功能，就專門用了一段時間來做了一些測試，對比。現在把數據和結論放上來給大家參考參考。
現在大家常用的Web頁面和Native端通信的方式大概有6種，下面會針對這6種方式做下性能測試來選出最優方案。
參測機型與系統版本：
Moto Nexus6 OS:6.0.1
魅族3S OS:5.1.1
紅米1 OS:4.2.2
測試用例：
在 web 頁面上發起請求時記下當前的時間t,并通過 JsBridge偽協議將時間 t 傳遞給 Native端，Native端收到請求時記錄下當前系統時間t2。將t2-t所得的時候就是這次 web 端和 Native端通信的耗時。同樣操作執行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方法拉處理偽協議請求：
測試結果
數據如下圖：
測試結論
對比上圖數據，我們發現使用Confirm方式基本上是耗時最短和最穩定的。如果你不需要更詳細的 web 端的信息，使用Confirm方式是性能最好的。但是如果你需要讀取 web 端的請求頭信息，以及是否是主 frame 發起的請求，你就必須使用子資源攔截方式（intercept方式）了。這些豐富的請求信息對以后權限控制拓展是必須的。
回歸應用本身下面原先采用的是Prompt方式后改進為Confirm方式
?
