H5与原生混合开发总结 H5与原生混合开发总结

一、引言
本文主要针对H5与原生混合开发中的交互问题进行讨论，当然，这仅仅是鄙人的见解，求同存异。
本文主要针对以下问题进行总结：

如何实现JS与Andriod的交互？
针对WebView启动慢问题，如何优化？
如果存在多个H5模块包，如何实现模块包的完全更新与部分更新？
针对以上问题的，如何建立一个公用的工具集（框架？）？
遇到的问题及解决办法。

OK, 开始吧！
二、交互
关于如何实现JS与Android交互，其实看官方的 Building web apps in WebView 这篇文章就够了，如果你觉得英文不好理解，那也没关系，因为接下来的内容会覆盖这些技术点。

交互模型：

文章图片
交互模型1.png 其实这里可以进一步将Webview抽象化，那么就得到了如下图关系：

文章图片
交互模型2.png 显然这里的问题就是如何实现JsExecutor和JsInterfaces了。
对于JsExecutor而言（Android调用JS），其实是比较固定的写法,比如，如果我们想要动态获取网页中某个标签的html,那么会这么写：

// 先假设id参数为content Stirng elementId = "content"; String jsCode = "javascript:document.getElementById(\" + elementId +\").innerHtml"; webView.evaluateJavascript(jsCode, new ValueCallback() { @Override public void onReceiveValue(String html) { // ... } });

这种写法是固定的，但是方法参数比较多时就比较蛋疼了，拼凑方法名和多个参数是很烦人的，且容易出错，因而我们可以抽象出以下工具类：

/** * @Author horseLai * CreatedAt 2018/10/22 17:42 * Desc: JS 代码执行器，包含通过WebView执行JS代码的通用方法。 * Update: */ public final class JsExecutor {private static final String TAG = "JsExecutor"; private JsExecutor() { }/** * JS方法不带参，且无返回值时用此方法 * * @param webView * @param jsCode */ public static void executeJsRaw(@NonNull WebView webView, @NonNull String jsCode) { executeJsRaw(webView, jsCode, null); }/** * JS方法带参，且有返回值时用此方法 * * @param webView * @param jsCode * @param callback */ public static void executeJsRaw(@NonNull WebView webView, @NonNull String jsCode, @Nullable ValueCallback callback) { if (Build.VERSION.SDK_INT >= 19) { webView.evaluateJavascript(jsCode, callback); } else { // 注意这里，这种方式没有直接的结果回调，不过可以迂回解决，比如我们可以 // 执行JS的一个固定的方法，并传入类型参数，然后在JS方法中根据这个类型参 // 数去匹配方法并执行，执行完成后再调用我们注入的相应回调方法将结果传回 // 来，这样就可以解决结果回调问题了，如果要适配 Android 4.4 以下的版本则可以这么做。 webView.loadUrl(jsCode); } } /** * JS方法带参，且有返回值时用此方法 * * @param webView * @param methodName * @param callback * @param params */ public static void executeJs(@NonNull WebView webView, @NonNull CharSequence methodName, @Nullable ValueCallback callback, @NonNull CharSequence... params) {StringBuilder sb = new StringBuilder(); sb.append("javascript:") .append(methodName) .append("("); if (params != null && params.length > 0) { for (int i = 0; i < params.length; i++) { sb.append("\"") .append(params[i]) .append("\""); if (i < params.length - 1) sb.append(","); } } sb.append("); "); Log.i(TAG, "executeJs: " + sb); executeJsRaw(webView, sb.toString(), callback); }/** * JS方法带参，且无返回值时用此方法 * * @param webView * @param methodName * @param params */ public static void executeJs(@NonNull WebView webView, @NonNull CharSequence methodName, @NonNull CharSequence... params) { executeJs(webView, methodName, null, params); } }

这里直接将WebView视为我们执行JS代码的工具，如下示例是给H5传递当前网络类型，由于整合了JS代码的拼接过程，因此只需要传入具体方法名称和方法的字符串参数即可。

JsExecutor.executeJs(webView, "onNetStatusChanged", netType);

对于JsInterfaces(JS调用Android) , 我们需要在我们需要注入的方法前加上注解@JavascriptInterface才能将方法暴露出去，然后将包含此方法的类对象注入进去，如下一个实际场景, H5需要从Android原生中获取用户的账号信息，那么可以这么写：

先注入包含对应方法的H5JsStorage类对象：

H5JsStorage h5JsStorage = new H5JsStorage(this, mUser); webView.addJavascriptInterface(h5JsStorage, "h5JsStorage");

其中getUserAccountInfo的声明如下：

public class H5JsStorage implements IH5JsStorage {// ... @JavascriptInterface public String getUserAccountInfo(){ return String.format("{\"userAccount\":\"%s\", \"password\":\"%s\", \"userIncrId\":\"%s\", \"orgId\":\"%s\"}", mUser.getUserAccount(), mUser.getPassword(), mUser.getUserIncrId(), mUser.getOrgId()); }// ... }

以上便是H5与原生交互的交互过程，具体代码在文章末尾会给出GitHub地址。
三、WebView 启动速度优化、多模块包自动更新
1. WebView启动速度优化
我们先来做个实验，测试一下包含WebView的Activity在优化前后的启动速度，可以这么做：根据Activity的生命周期，在onCreate的第一行处记录下初始时间，在onStart最后一行记录下结束时间，然后计算时间差，作为衡量启动速度的参照，多次测试，记录时间差。结果如下：

//--------------------------------------------- // 不做任何处理， Mi6 android 8.0 I/Main2Activity: onStart: total cost:150 ms I/Main2Activity: onStart: total cost:44 ms I/Main2Activity: onStart: total cost:33 ms I/Main2Activity: onStart: total cost:54 ms I/Main2Activity: onStart: total cost:35 ms I/Main2Activity: onStart: total cost:34 ms I/Main2Activity: onStart: total cost:34 ms //优化后初始化耗时 I/MyWebViewHolder: prepareWebView: total cost: 131 ms I/MyWebViewHolder: prepareWebView: total cost: 121 ms I/MyWebViewHolder: prepareWebView: total cost: 121 ms I/MyWebViewHolder: prepareWebView: total cost: 117 ms I/MyWebViewHolder: prepareWebView: total cost: 110 ms I/MyWebViewHolder: prepareWebView: total cost: 116 ms I/MyWebViewHolder: prepareWebView: total cost: 116 ms // 之后耗时 I/Main2Activity: onStart: total cost:26 ms I/Main2Activity: onStart: total cost:20 ms I/Main2Activity: onStart: total cost:22 ms I/Main2Activity: onStart: total cost:17 ms I/Main2Activity: onStart: total cost:19 ms I/Main2Activity: onStart: total cost:21 ms//--------------------------------------------- // 模拟器 android 9.0 I/Main2Activity: onStart: total cost:292 ms I/Main2Activity: onStart: total cost:50 ms I/Main2Activity: onStart: total cost:49 ms I/Main2Activity: onStart: total cost:54 ms I/Main2Activity: onStart: total cost:43 ms I/Main2Activity: onStart: total cost:47 ms I/Main2Activity: onStart: total cost:39 ms I/Main2Activity: onStart: total cost:41 ms // 优化后初始化耗时 I/MyWebViewHolder: prepareWebView: total cost: 177 ms I/MyWebViewHolder: prepareWebView: total cost: 169 ms I/MyWebViewHolder: prepareWebView: total cost: 183 ms I/MyWebViewHolder: prepareWebView: total cost: 159 ms // 之后耗时 I/Main2Activity: onStart: total cost:40 ms I/Main2Activity: onStart: total cost:27 ms I/Main2Activity: onStart: total cost:34 ms I/Main2Activity: onStart: total cost:34 ms I/Main2Activity: onStart: total cost:33 ms I/Main2Activity: onStart: total cost:30 ms //--------------------------------------------- //MT6592 android 4.4 不做处理 I/Main2Activity: onStart: total cost:141 ms I/Main2Activity: onStart: total cost:46 ms I/Main2Activity: onStart: total cost:43 ms I/Main2Activity: onStart: total cost:42 ms I/Main2Activity: onStart: total cost:44 ms I/Main2Activity: onStart: total cost:46 ms // 优化后初始化耗时 I/MyWebViewHolder: prepareWebView: total cost: 182 ms I/MyWebViewHolder: prepareWebView: total cost: 50 ms I/MyWebViewHolder: prepareWebView: total cost: 54 ms I/MyWebViewHolder: prepareWebView: total cost: 53 ms I/MyWebViewHolder: prepareWebView: total cost: 54 ms I/MyWebViewHolder: prepareWebView: total cost: 56 ms // 之后耗时 I/Main2Activity: onStart: total cost:36 ms I/Main2Activity: onStart: total cost:34 ms I/Main2Activity: onStart: total cost:30 ms I/Main2Activity: onStart: total cost:31 ms I/Main2Activity: onStart: total cost:32 ms

根据以上结果可以看出，优化后要比优化前的启动速度快个10~20秒，且抖动较小。可以注意到其中包含一个叫做prepareWebView的时间差，据此，聪明的你肯定能想到我所谓的优化是做了什么操作。嗯~，其实就是使用WebView之前，在合适的地方和时机先将其初始化，之后复用这个创建好的实例，这里我是这么写的：

/** * @Author horseLai * CreatedAt 2018/12/10 10:11 * Desc: 用于持有MyWebView实例，减少每次都重新创建和销毁造成的开销 * Update: */ public final class MyWebViewHolder { private static final String TAG = "MyWebViewHolder"; private MyWebView mWebView; private static MyWebViewHolder sMyWebViewHolder; private View pageNoneNet; private boolean mShouldClearHistory = false; public boolean shouldClearHistory() { return mShouldClearHistory; }public void shouldClearHistory(boolean shouldClearHistory) { this.mShouldClearHistory = shouldClearHistory; } private MyWebViewHolder() { }public static MyWebViewHolder getHolder() { if (sMyWebViewHolder != null) return sMyWebViewHolder; synchronized (MyWebViewHolder.class) { if (sMyWebViewHolder == null) { sMyWebViewHolder = new MyWebViewHolder(); } } return sMyWebViewHolder; }/** * 务必在使用WebView前调用此方法进行初始化 * * @param context */ public void prepareWebView(Context context) { long start = System.currentTimeMillis(); if (mWebView != null) return; synchronized (this) { if (mWebView == null) { mWebView = new MyWebView(context); } } Log.i(TAG, "prepareWebView: total cost: " + (System.currentTimeMillis() - start) + " ms"); Log.d(TAG, "prepare MyWebView OK..."); }public MyWebView getMyWebView() { return mWebView; }public void detach() { if (mWebView != null) { Log.d(TAG, "detach MyWebView, but not destroy..."); ((ViewGroup) mWebView.getParent()).removeView(mWebView); mWebView.removeAllViews(); mWebView.clearAnimation(); mWebView.clearFormData(); // mWebView.clearHistory(); mShouldClearHistory = true; mWebView.getSettings().setJavaScriptEnabled(false); } }public void attach(ViewGroup parent, int index) { if (mWebView != null) { Log.d(TAG, "attach MyWebView, index of ViewGroup is " + index); WebSettings settings = mWebView.getSettings(); // 不加此配置会无法加载显示界面 settings.setDomStorageEnabled(true); settings.setSupportZoom(false); settings.setJavaScriptEnabled(true); settings.setUseWideViewPort(true); mWebView.setLayoutParams(new ViewGroup.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT, ViewGroup.LayoutParams.MATCH_PARENT)); mWebView.setVerticalScrollBarEnabled(false); mWebView.setHorizontalScrollBarEnabled(false); // 在WebView上层覆盖一个用于提示如错误等信息的布局层， FrameLayout frameLayout = new FrameLayout(parent.getContext()); frameLayout.setLayoutParams(new FrameLayout.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT, ViewGroup.LayoutParams.MATCH_PARENT)); frameLayout.addView(mWebView, new FrameLayout.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT, ViewGroup.LayoutParams.MATCH_PARENT)); pageNoneNet = LayoutInflater.from(parent.getContext()).inflate(R.layout.layout_null_net, frameLayout, false); frameLayout.addView(pageNoneNet); pageNoneNet.setVisibility(View.GONE); pageNoneNet.findViewById(R.id.btn_try).setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { pageNoneNet.setVisibility(View.GONE); mWebView.reload(); } }); parent.addView(frameLayout, index); } }public void showNoneNetPage() { if (pageNoneNet != null) pageNoneNet.setVisibility(View.VISIBLE); } public void hideNoneNetPage() { if (pageNoneNet != null) pageNoneNet.setVisibility(View.GONE); }public void attach(ViewGroup parent) { attach(parent, parent.getChildCount()); }public void destroy() { if (mWebView != null) { Log.d(TAG,"destroy MyWebView..."); mWebView.destroy(); } }public void pause() { if (mWebView != null) { Log.d(TAG,"pause MyWebView..."); mWebView.onPause(); } }public void resume() { if (mWebView != null) { Log.d(TAG,"resume MyWebView..."); mWebView.onResume(); } }public void removeJSInterfaces(String... names) { if (names == null || names.length == 0) return; for (String name : names) { Log.d(TAG,String.format("removeJSInterfaces:: %s ..", name)); mWebView.removeJavascriptInterface(name); } } }

然后在合适的地方初始化：

@Override protected void onCreate(Bundle savedInstanceState) { // ... MyWebViewHolder.getHolder().prepareWebView(this); }

添加到布局中：

LinearLayout parent= findViewById(R.id.parent); MyWebViewHolder.getHolder().attach(parent);

在onDestroy时从界面中解除绑定：

@Override protected void onDestroy() { // ... MyWebViewHolder.getHolder().detach(); }

2. 多模块包自动更新
支持多模块自动更新的目的是方便更新维护，减少用户升级所带来的流量开支，每个模块包之间可以是相互独立的，也方便于团队开发，仅需要和前端约定好文件目录即可。
先来看看H5模块的自动更新流程（完整更新）:

文章图片
H5模块完整包更新流程.png
上面是模块包的完整更新过程，还可以进行补丁更新，而所谓补丁更新就是，下载的更新包中仅仅包含需要更新的文件，因而对应于上面流程而言，就是少了删除本地旧版本文件的过程，而直接解压替换对应文件。这种更新方式有以下优缺点：

可以极大的减少更新时对用户的流量消耗，且速度极快。
但是需要前端明确抽取所更新的文件，否则会出现问题，可能这个过程会繁琐点。
如果使用类似于VueJs这种模板框架编写的界面，因为需要编译为JS代码，然后仅剩一个index.html入口，导致抽取定位繁琐，且每次编译出来的文件名可能不一样，因此不能使用补丁更新这种方式，只能分包，然后进行完整更新。

具体代码比较多，就补贴了，请看 github这里，其中H5ManagerSettings是H5Manager配置信息与无关逻辑的抽离类。
四、建立公用工具集
【H5与原生混合开发总结】上面已经逐个介绍了混合开发中交互与更新的逻辑，工具集已经放到 github的H5MixDevelopTools，感兴趣的童鞋可以看看，虽然这里我并没有把JS接口和html界面放上去。

文章图片
混合开发工具集.png
遇到的实际问题与解决办法：（以项目中使用VueJs作为模板引擎来编写H5页面为例）
1. 界面加载不出来，显示空白，怎么办？
解决办法：给WebView加上下面配置即可

mWebView.getSettings().setDomStorageEnabled(true);

2. 联调时发现总是找不到定义的交互接口方法，怎么办？
原因与解决办法：首先，默认情况下，VueJs在对代码进行混淆处理，因此如果你遇到了这个问题，那么请手动配置以关闭混淆（具体做法请自行查找吧）。如果已经不混淆了，但是依然找不到对应的方法，怎么办？我和我的小伙伴是将接口文件放到components中将其视作一个组件来使用的，然后具体到接口方法的话，将方法挂到window对象下，如下示例:

// 挂载方法 window.showToast = function(msg){ UI.showToast(msg); } // 挂载变量，挂载在window的变量可以在全局直接引用 window.userInfo = {name:"horseLai"}

3. 图片选择问题，怎么选择和预览图片？
先来个具体场景：比如说我们项目中有个评论功能，这个功能是用H5写的，然后每次评论时可以选择数量小于3张的评论图片，附带文字上传至服务器。
此时你会发现直接使用没法调用起系统相片图库和相机，更没法在旁边显示预览图，这时你可能需要这些配置：

settings.setJavaScriptEnabled(true); settings.setAllowFileAccess(true); settings.setAllowFileAccessFromFileURLs(true); settings.setAllowUniversalAccessFromFileURLs(true); settings.setAllowContentAccess(true);

接着就是选择图片有两种方案：

通过复写WebChromeClientc#onShowFileChooser和WebChromeClient#openFileChooser,但是openFileChooser方法已经变为系统Api了，所以没法直观的找到它，但是，即使找到了，你也会发现去适配不同的机型也是坑的很。可以先看看 android-4-4-webview-file-chooser-not-opening, 而因为我不是直接调用图库选择，而是先开启一个BottomSheetDialog来选择是通过相机还是图库取图，这样带来的问题就是，如果我仅仅是开启了BottomSheetDialog，然后不做任何选择地关闭掉它，不调用ValueCallback#onReceiveValue传值的话，那么只能启当一次弹窗，之后再点就没反应了，而如果我每次关闭BottomSheetDialog时通过ValueCallback#onReceiveValue传个null，那么连续启动两次后又会异常闪退，嗯，这坑我就不跳了，我选择第二种方案。
第二种方案就是直接建立JS交互接口，点击图片选择控件后调用建立好的原生图片选择接口取图，当我们选好图之后在onActivityResult方法中执行JS方法将图片的本地路径传给JS处理，嗯，到这里的话好说，这个流程咱都熟悉。那么来说说如何在上预览，以及如何将这个路径的图片作为文件上传。

下面是选完图片后我们将图片路径回调到JS的方法。

/** *相册中获取图片、相机拍照结果回调 * @param {Number} type类型： 0->图库， 1->相机 * @param {String} imgFilePath */ window.selectedImgFile = []; // 模拟选择文件后的存储形式，用于上传 window.selectedImgFileUrls = []; // 将图片路径转换成能够预览的路径 window.onPictureResult = function (type, imgFilePath) { // 注意这里 selectedImgFile.push(new File([""], imgFilePath, {type:"image/*"})); selectedImgFileUrls.push({ imgUrl: "file://" + imgFilePath }); }

上面selectedImgFile,selectedImgFileUrls这两个挂载到window的变量，这两个数组可以直接在全局引用了，记得在使用后清空，不然会影响到下次使用。
嗯，看起来很完美，选图、预览很完美，但很快你就会发现这实际是个BUG，BUG在哪里呢？注意到上面的new File([""], imgFilePath, {type:"image/*"})，这么使用会导致上传到服务器的图片大小为 0kb，为啥呢？因为第一个参数[""]实际是图片的实际数据（字节数组），它的长度代表着文件的大小，因此，上面这样做虽然能够预览，但是无法仅仅直接通过一个本地路径就读取到文件流数据，也就不能上传成功了。
怎么办呢？思考了很久，发现自己一直困在JS如何通过一个本地路径建立File并上传的思维当中，于是找前端和后台的小伙伴交流，最终确定的方案是：选择图片后先将图片编码成Base64字符串再注入到JS处理，JS端收到数据后进行图片数据绑定，以及上传到服务器，服务器端进行Base64解码处理，然后保存成本地图片。
于是可以稍微修改成这样：

window.selectedImgFile = []; window.selectedImgFileUrls = []; // 将图片路径转换成能够预览的路径 window.onPictureResult = function (type, imgFilePath, base64Data) { selectedImgFile.push( base64Data ); selectedImgFileUrls.push({ imgUrl: "data:image/jpg; base64," + base64Data }); }

不过这里依然可能存在一些问题，比如内存溢出，因为图片本身可能很大，尤其是使用相机直接拍照取图的情况，一张图片可能会有3~10M，直接编码为图片本身会比较耗时，而编码出来的字符串会存在于内存中，因此很有可能会导致Android端出现内存溢出的情况，因此这里可以考虑先压缩后编码，这样可以降低内存耗尽的几率。
五、总结
本文基于实际项目，介绍了混合开发中JS与原生交互的实现，然后以一个小实验测试了含WebView的Activity的启动速度，优化，然后测试优化后的启动速度，接着介绍了H5分模块更新的逻辑，最后整理了一套工具集，感兴趣的童鞋可以看看 H5MixDevelopTools，欢迎指正。
使用H5混合开发确实能够提升开发速度，但是实际体验确实一般，适合非常追求开发速度的场景。