各种 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方式
