Android Js和Native的各种互撩

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