H5與原生混合開發總結

一、引言

本文主要針對H5與原生混合開發中的交互問題進行討論,當然,這僅僅是鄙人的見解,求同存異。

本文主要針對以下問題進行總結:

  1. 如何實現JSAndriod的交互?
  2. 針對WebView啓動慢問題,如何優化?
  3. 如果存在多個H5模塊包,如何實現模塊包的完全更新與部分更新?
  4. 針對以上問題的,如何建立一個公用的工具集(框架?)?
  5. 遇到的問題及解決辦法。

OK, 開始吧!

二、交互

關於如何實現JSAndroid交互,其實看官方的 Building web apps in WebView 這篇文章就夠了,如果你覺得英文不好理解,那也沒關係,因爲接下來的內容會覆蓋這些技術點。

  • 交互模型:

其實這裏可以進一步將Webview抽象化,那麼就得到了如下圖關係:

顯然這裏的問題就是如何實現JsExecutorJsInterfaces了。

對於JsExecutor而言(Android調用JS,其實是比較固定的寫法,比如,如果我們想要動態獲取網頁中某個標籤的html,那麼會這麼寫:

// 先假設id參數爲content
Stirng elementId = "content";
String jsCode = "javascript:document.getElementById(\" + elementId +\").innerHtml"; 
webView.evaluateJavascript(jsCode, new ValueCallback<String>() {
            @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<String> 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<String> 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啓動速度優化

我們先來做個實驗,測試一下包含WebViewActivity在優化前後的啓動速度,可以這麼做:根據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模塊的自動更新流程(完整更新):

上面是模塊包的完整更新過程,還可以進行補丁更新,而所謂補丁更新就是,下載的更新包中僅僅包含需要更新的文件,因而對應於上面流程而言,就是少了刪除本地舊版本文件的過程,而直接解壓替換對應文件。這種更新方式有以下優缺點:

  1. 可以極大的減少更新時對用戶的流量消耗,且速度極快。
  2. 但是需要前端明確抽取所更新的文件,否則會出現問題,可能這個過程會繁瑣點。
  3. 如果使用類似於VueJs這種模板框架編寫的界面,因爲需要編譯爲JS代碼,然後僅剩一個index.html入口,導致抽取定位繁瑣,且每次編譯出來的文件名可能不一樣,因此不能使用補丁更新這種方式,只能分包,然後進行完整更新。

具體代碼比較多,就補貼了,請看 github這裏, 其中H5ManagerSettingsH5Manager配置信息與無關邏輯的抽離類。

四、建立公用工具集

上面已經逐個介紹了混合開發中交互與更新的邏輯,工具集已經放到 githubH5MixDevelopTools,感興趣的童鞋可以看看,雖然這裏我並沒有把JS接口和html界面放上去。

遇到的實際問題與解決辦法:(以項目中使用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張的評論圖片,附帶文字上傳至服務器。

此時你會發現直接使用<input type="file">沒法調用起系統相片圖庫和相機,更沒法在旁邊顯示預覽圖,這時你可能需要這些配置:

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

接着就是選擇圖片有兩種方案

  • 通過複寫WebChromeClientc#onShowFileChooserWebChromeClient#openFileChooser,但是openFileChooser方法已經變爲系統Api了,所以沒法直觀的找到它,但是,即使找到了,你也會發現去適配不同的機型也是坑的很。可以先看看 android-4-4-webview-file-chooser-not-opening, 而因爲我不是直接調用圖庫選擇,而是先開啓一個BottomSheetDialog來選擇是通過相機還是圖庫取圖,這樣帶來的問題就是,如果我僅僅是開啓了BottomSheetDialog,然後不做任何選擇地關閉掉它,不調用ValueCallback#onReceiveValue傳值的話,那麼<input>只能啓當一次彈窗,之後再點就沒反應了,而如果我每次關閉BottomSheetDialog時通過ValueCallback#onReceiveValue傳個null,那麼連續啓動兩次後又會異常閃退,嗯,這坑我就不跳了,我選擇第二種方案。
  • 第二種方案就是直接建立JS交互接口,點擊圖片選擇控件後調用建立好的原生圖片選擇接口取圖,當我們選好圖之後在onActivityResult方法中執行JS方法將圖片的本地路徑傳給JS處理,嗯,到這裏的話好說,這個流程咱都熟悉。那麼來說說如何在<img>上預覽,以及如何將這個路徑的圖片作爲文件上傳。

下面是選完圖片後我們將圖片路徑回調到JS的方法。

/**
 *  相冊中獲取圖片、相機拍照結果回調
 * @param {Number} type   類型: 0->圖庫, 1->相機
 * @param {String} imgFilePath  
 */
window.selectedImgFile = [];  // 模擬<input>選擇文件後的存儲形式,用於上傳
window.selectedImgFileUrls = []; // 將圖片路徑轉換成<img>能夠預覽的路徑
window.onPictureResult = function (type, imgFilePath) {
    // 注意這裏
    selectedImgFile.push(new File([""], imgFilePath, {type:"image/*"}));
    selectedImgFileUrls.push({
        imgUrl: "file://" + imgFilePath
    });
}

上面selectedImgFile,selectedImgFileUrls這兩個掛載到window的變量,這兩個數組可以直接在全局引用了,記得在使用後清空,不然會影響到下次使用。

嗯,看起來很完美,選圖、預覽很完美,但很快你就會發現這實際是個BUGBUG在哪裏呢?注意到上面的new File([""], imgFilePath, {type:"image/*"}),這麼使用會導致上傳到服務器的圖片大小爲 0kb, 爲啥呢?因爲第一個參數[""]實際是圖片的實際數據(字節數組),它的長度代表着文件的大小,因此,上面這樣做雖然能夠預覽,但是無法僅僅直接通過一個本地路徑就讀取到文件流數據,也就不能上傳成功了。

怎麼辦呢?思考了很久,發現自己一直困在JS如何通過一個本地路徑建立File並上傳的思維當中,於是找前端和後臺的小夥伴交流,最終確定的方案是:選擇圖片後先將圖片編碼成Base64字符串再注入到JS處理,JS端收到數據後進行圖片數據綁定,以及上傳到服務器,服務器端進行Base64解碼處理,然後保存成本地圖片。

於是可以稍微修改成這樣:

window.selectedImgFile = [];  
window.selectedImgFileUrls = []; // 將圖片路徑轉換成<img>能夠預覽的路徑
window.onPictureResult = function (type, imgFilePath, base64Data) {
    selectedImgFile.push( base64Data );
    selectedImgFileUrls.push({
        imgUrl: "data:image/jpg;base64," + base64Data
    });
}

不過這裏依然可能存在一些問題,比如內存溢出,因爲圖片本身可能很大,尤其是使用相機直接拍照取圖的情況,一張圖片可能會有3~10M,直接編碼爲圖片本身會比較耗時,而編碼出來的字符串會存在於內存中,因此很有可能會導致Android端出現內存溢出的情況,因此這裏可以考慮先壓縮後編碼,這樣可以降低內存耗盡的機率。

五、總結

本文基於實際項目,介紹了混合開發中JS與原生交互的實現,然後以一個小實驗測試了含WebViewActivity的啓動速度,優化,然後測試優化後的啓動速度,接着介紹了H5分模塊更新的邏輯,最後整理了一套工具集,感興趣的童鞋可以看看 H5MixDevelopTools,歡迎指正。

使用H5混合開發確實能夠提升開發速度,但是實際體驗確實一般,適合非常追求開發速度的場景。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章