各种 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方式）了。这些丰富的请求信息对以后权限控制拓展是必须的。
关于addJavascriptInterface
这篇文章从一开始就没打算把 addJavascriptInterface 方式添加到对比的数据中，因为它在 Android4.2 之前的版本存在严重的安全漏洞。谷歌在 Android4.2 之后的版本才通过添加 @JavascriptInterface 注解的方式解决了该问题。这两天又换了个角度思考了一下，该方式作为谷歌官方的 Webview 和 JavaScript 解决方案，肯定会比其他交互方式优秀的地方。历史的车轮滚滚向前，目前大多数用户的系统版本都集中在4.4.2以上了，所以今天还是把这个方式做了个测试。测试数据也证实我的猜测，其时间间隔是最短的。所以，如果你的 App 只打算支持 Android4.2 版本以上的，就可以考虑这个官方解决方案了。
下集预告
下一篇会写基于Confirm方式以及intercept方式的完整的 JS 交互，即包含了 Native调用 web 端的方法。
下篇已出，Android WebView：我是怎么和 JavaScript 互撩的？
