随手记Android JS与Native交互实践

1,739 阅读10分钟
原文链接: mp.weixin.qq.com

前言

在移动开发中,开发的需求和节奏都越来越快,而Native App在这种节奏中略显笨拙,开发周期长、用户升级慢、应用市场审核时间长都深受开发者弊病。而这时候很多开发者都提出了Hybrid App的概念,这种开发模式有着迭代灵活、多端统一、开发周期短、快速上线等优势。但是Hybrid App也有其不足的地方,在性能很难到达Native App的水平,在访问设备上的硬件时也不是那么得心应手。对于这些问题,现在已经有较多的解决方案,比较重的框架有Facebook的React Native,轻量级别也有ionic。如果是已经成熟的产品,Web页面较多迁移比较困难,也可以使用VasSonic来提升WebView体验,然后通过JS调用Native。目前公司项目中由于历史原因采用后者的方式来实现,但是在使用过程中由于没有统一的管理,存在了通讯方式多样、调用混乱和安全性差等几个问题。下文主要讲述如何通过重新设计JS调用框架来解决以上问题。

Android WebView JS交互

首先介绍一下WebView中JS和Native相互调用的方式、相互之间的差异。

Android调用JS

WebView调用JS有以下两种方式:

  • 通过WebView.loadUrl()

  • 通过WebView.evaluateJavascript()

在API 19之前是只能通过WebView.loadUrl()进行调用JavaScript。在API 19的时候新提供了WebView.evaluateJavascript(),它的运行效率会比loadUrl()高,还可以传入一个回调对象,方便获取Web端的回传信息。

webView.evaluateJavascript("fromAndroid()", new ValueCallback<String>() {       @Override    public void onReceiveValue(String value) {            //do something    }});

JS调用Android代码

JS调用Native代码有以下三种方式:

  • 通过WebView.addJavascriptInterface()

  • 通过WebViewClient.shouldOverrideUrlLoading()

  • 通过WebChromeClient.onJsAlert()、onJsConfirm()、onJsPrompt()

WebView.addJavascriptInterface()是官方推荐的做法,在默认情况下WebView是关闭了JavaScript的调用,需要调用WebSetting.setJavaScriptEnabled(true)来进行开启。这个方法需要一个Object类型的JavaScript Interface,然后通过@JavascriptInterface来标注提供的JS调用的方法,下面是一个Google官方提供的例子:

public class AppJavaScriptProxy {    private Activity activity = null;    public AppJavaScriptProxy(Activity activity) {        this.activity = activity;    }    @JavascriptInterface    public void showMessage(String message) {        Toast toast = Toast.makeText(this.activity.getApplicationContext(),                message,                Toast.LENGTH_SHORT);        toast.show();    }}
webView.addJavascriptInterface(new AppJavaScriptProxy(this),“androidAppProxy”);
// JS代码调用if(typeof androidAppProxy !== "undefined"){    androidAppProxy.showMessage("Message from JavaScript");} else {    alert("Running outside Android app");}

这样就可以实现JS调用Android代码,使用者只需要关注被JS调用方法的实现,对调用的过程是不可知的。使用的时候有几个要注意的地方:

  1. 提供用于JS调用的方法必须为public类型

  2. 在API 17及以上,提供用于JS调用的方法必须要添加注解@JavascriptInterface

  3. 这个方法不是在主线程中被调用的

WebViewClient.shouldOverrideUrlLoading()是通过拦截Url的方式来实现与JS的交互。shouldOverrideUrlLoading()返回true时,代表拦截这次请求,让我们自己处理。shouldOverrideUrlLoading()返回false时,代表不拦截这次请求,让WebView去处理这次请求。

WebChromeClient.onJsAlert()、onJsConfirm()、onJsPrompt()三种方式和WebViewClient.shouldOverrideUrlLoading()类似,都是通过拦截请求的方式达到交互功能。

总结:这三种方式实际上可以归纳成两种:JavascriptInterface和拦截请求,两者之间各有好坏。

  • JavascriptInterface是系统提供的方式,在效率和可靠性上肯定是优于后者的,而且以后会一直持续维护和优化。缺点在于扩展性和管理方面不太强,在Android 4.2以下存在漏洞,需要移除掉系统提供的一些接口,并小心处理提供的接口。

  • 拦截请求的方式优点是便于管理和扩展,可以按照自身的业务进行设计,方便应对复杂的逻辑,而且可以在安全性上有所保证。缺点主要是官方对这种方式不提供支持,以后高版本有需要迁移整个逻辑的可能性。还有就是效率不高,H5快速调用多个请求时会有丢失的可能。

JS调用框架设计

为了解决前言中提到的通讯方式多样、调用混乱和安全性差等几个问题,需要重新设计JS调用框架,将整个流程从WebView中剥离出来,达到低耦合的目的。综合考虑后,决定沿用项目中之前的解决方式,通过拦截WebView请求的方式来实现。拦截性的方式在设计框架之前还需要考虑到通讯协议的问题。

协议设计

如上图所示,通过设计通讯协议达到多端统一通讯。协议上面可以参考现有的通讯协议,或者根据项目需求和前端设计一套通用协议。这里推荐一种简单的现有的协议:统一资源标志符。

jsbridge://method1?a=123&b=345&jsCall=jsMethod1"

该种标识允许用户对网络中(一般指万维网)的资源通过特定的协议进行交互操作,在这里不用完全使用,只使用了其中的三个字段。scheme定义为jsbridge,用于区分别的网络请求。authority用来定义JS需要访问的方法。后面的query用来传参数,如果需要客户端回调信息给前端,就可以加个参数jsCall=jsMethod1,然后客户端处理完后就可以通过WebView进行回调。

WebView.loadUrl("javascript:jsMethod1(result=1)")

这样就定义了一种简单的交互方式,能让JS和Native拥有基础的交互能力。如果需要传文件,可以通过将文件流转成Base64然后在通讯,当然如果文件太大,这种方式会有内存方面的风险。这里还有另外一种方式,拦截WebView的资源请求,将文件以流的形式进行通讯:

webView.setWebViewClient(new WebViewClient(){     @Override     public WebResourceResponse shouldInterceptRequest(WebView view, String url) {             return new WebResourceResponse("image/jpeg", "UTF-8", new FileInputStream(new File("xxxx");     }}

框架设计

在设计中,主要考虑了以下几点:

  1. 安全性: 防止第三方网站获取用户私密信息和通讯被第三方截取信息。(域名白名单、数据加密)

  2. 易用性: 设计框架都需要考虑易用性,方便实用。如Android的JavascriptInterface方式,使用者只用关注被调用方法的实现。(参考Android的JavascriptInterface方式)

  3. 可移植性: 现在Android系统日新月异,每个版本都有较大改动和优化,如果出现更好的方案或者特性时,要方便迁移整个JsBridge方案。(设计中要职责分明)

  4. 扩展性: 方便业务逻辑扩展。(添加中间件)

通过分析整个通讯的流程,结合项目中的需要,大体抽象出通讯流程中的五个角色:

  1. JsBridge: 整个Js框架的管理,提供对外的接口,连接Processor和JsProvider。

  2. JsCall: 抽象一次请求,包含一次请求的内容和环境,拥有回调信息给前端的接口。

  3. IProcessor: 协议的抽象体。由于项目原因需要多套协议兼容,所以抽象出协议,负责请求的分类和解析。

  4. JsProvider: Js方法的提供者,本身是Object类型,方便现有代码迁移,而且和JavascriptInterface方式一致,也方便以后迁移。

  5. @JsMethod: Js方法的一个注解,类似@JavascriptInterface。

这样的模式和系统提供的JavascriptInterface方式基本一致,但是我们可以做的事情比JavascriptInterface方式更多,而且整个系统解耦清晰,但是这个结构实际上还缺乏较多的东西,无法达到设计的目标,整个流程中缺乏扩展性,没有拦截和二次处理机制。

可以在执行JsMethod之前添加一个拦截器,增强扩展性。

安全性方面也可以通过添加拦截器的方式来实现,将JS请求拦截在执行JsMethod之前,而每个JsMethod的安全级别可以通过扩展注解参数来标注。例如下面代码,添加permission字段来标示方法的安全级别。

 @JsMethod(permission = "high") public void requestInfo(IJsCall jsCall) {         // do something }

框架骨架搭建好了后,还需要一些优化性的设计:

  1. 日志系统:添加日志开关,打印关键性的日志。

  2. 线程转换:由于WebViewClient.shouldOverrideUrlLoading是在主线程里面执行,可以参考Android做法,将JS方法都放到其它线程去做,不影响页面流畅度。

  3. 异常机制:将框架中发生的异常统一管理后,抛出给框架调用者。

  4. ... (结合业务设计)

实现效果

最后,框架大体设计完毕,实现都是比较简单的。现在来看看使用的时候,首先是JS发起一个请求:

  var iframe = document.createElement('iframe');  iframe.setAttribute('src', 'jsbridge://method1?a=123&b=345');  document.body.appendChild(iframe);  iframe.parentNode.removeChild(iframe);  iframe = null;

客户端只需要简单的对WebView的请求做拦截。

    @Override    public boolean shouldOverrideUrlLoading(WebView webView, String url) {        boolean handle = super.shouldOverrideUrlLoading(webView, url);        if (!handle) {            handle = JSBridge.parse(activity, webView, url);        }        return handle;    }

创建一个解析当前协议的对象,这个是以后都可以复用的:

public class JsProcessor implements IProcessor {    public static final int TYPE_PROCESSOR = 1;    /**     * 协议编号     * @return     */    @Override    public int getType() {        return TYPE_PROCESSOR;    }    /**     * 判断请求是不是属于这个协议     * @param url     * @return     */    @Override    public boolean isProtocol(String url) {        return !TextUtils.isEmpty(url) && url.startsWith("jsbridge");    }    /**     * 解析协议     * @param context     * @param webView     * @param url     * @param webViewContext WebView的环境     * @return     */    @Override    public IJsCall parse(Context context, WebView webView, final String url, Object webViewContext) {        return new IJsCall<RequestBean, ResponseBean>() {            private String mMethodName;            @Override            public void callback(ResponseBean data, WebView webView) {                JSBridge.callback(data, webView);            }            @Override            public String url() {                return null;            }            @Override            public RequestBean parseData() {                if (TextUtils.isEmpty(url)) {                    return null;                }                Uri uri = Uri.parse(url);                String methodName = uri.getPath();                methodName = methodName.replace("/", "");                mMethodName = methodName;                return new RequsetBean(url);            }            @Override            public String method() {                return mMethodName;            }        };    }}

创建一个提供JS方法的对象,在对外提供的方法上加入注解@JsMethod,并标注调用该方法的协议编号、方法名称和权限级别,方法中所需要的信息都通过IJsCall获取,处理完成后,通过IJsCall回调信息给JS。

public class JsProvider {    @JsMethod(processorType = JsProcessor.TYPE_PROCESSOR, name = "method1", permission = "high")    public void method1(IJsCall jsCall) {        // do anything        // ...        // ...        // ...        jsCall.callback("xxxx");    }}

以上就完成了一次JS和Native的通讯。整个通讯的细节不对外开放,使用者只用关注方法的开发,方法的信息通过注解来承载,解析注解时可以通过编译时生成代码来提高效率。白名单和数据加密直接通过拦截器来实现。整个系统完美的解决了之前项目中问题,而且也方便以后的业务发展。

总结

Hybrid App是以后的趋势,JS和Native之间业务逻辑也会越来越重,所以项目中这块的设计也非常重要,需要不断的根据业务来调整,保证其稳定性的同时,又有很强的扩展能力。

参考链接

https://www.jianshu.com/p/93cea79a2443https://zh.wikipedia.org/zh-hans/%E7%BB%9F%E4%B8%80%E8%B5%84%E6%BA%90%E6%A0%87%E5%BF%97%E7%AC%A6