天天看點
傳回

Native與H5互動的那些事

轉載于http://zhengxiaoyong.me/

前言

Hybrid開發模式目前幾乎每家公司都有涉及和使用，這種開發模式兼具良好的Native使用者互動體驗的優勢與WebApp跨平台的優勢，而這種模式，在Android中必然需要WebView作為載體來展示H5内容和進行互動，而WebView的各種安全性、相容性的問題，我想大多數人與它友誼的小床已經翻了，特别是4.2版本之前的addjavascriptInterface接口引起的漏洞，可能導緻惡意網頁通過Js方法周遊剛剛通過addjavascriptInterface注入進來的類的所有方法從中擷取到getClass方法，然後通過反射擷取到Runtime對象，進而調用Runtime對象的exec方法執行一些操作，惡意的Js代碼如下：

1
2
3
4
5
6
7
8
9
      
function execute(cmdArgs) {
    for (var obj in window) {
        if ("getClass" in window[obj]) {
            alert(obj);
            return  window[obj].getClass().forName("java.lang.Runtime")  
                 .getMethod("getRuntime",null).invoke(null,null).exec(cmdArgs);
        }
    }
}

為了避免這個漏洞，即需要限制Js代碼能夠調用到的Native方法，官方于是在從4.2開始的版本可以通過為可以被Js調用的方法添加

@JavascriptInterface

注解來解決，而之前的版本雖然不能通過這種方法解決，但是可以使用Js的

prompt

方法進行解決，隻不過

需要和前端協商好一套公共的協定

，除此之外，為了避免WebView加載任意url，也需要對url進行白名單檢測，由于Android碎片化太嚴重，WebView也存在相容性問題，WebView的核心也在4.4版本進行了改變，由webkit改為chromium，此外WebView還有一個非常明顯的問題，就是記憶體洩露，根本原因就是Activity與WebView關聯後，WebView内部的一些操作的執行在新線程中，這些時間無法确定，而可能導緻WebView一直持有Activity的引用，不能回收。下面就談談怎樣正确安全的讓Native與H5互動

Native與H5怎樣安全的進行互動？

要使得H5内的Js與Native之間安全的互相進行調用，我們除了可以通過添加

@JavascriptInterface

注解來解決（>=4.2），還有通過

prompt

的方式，不過如果使用官方的方式，這就需要對4.2以下做相容了，這樣使得我們一個app中有兩套Js與Native互動的方式，這樣極其不好維護，我們應該隻需要一套Js與Native互動的方式，是以，我們借助Js中的

prompt

方法來實作

一套安全的Js與Native互動的JsBridge架構

Js與Native代碼互相調用

Native Invoke Js:

我們知道如果Native需要調用Js中的方法，隻需要使用

WebView:loadUrl();

方法即可直接調用指定Js代碼，如：

這樣就直接調用了Js中的

setUserName

方法并把

zhengxiaoyong

這個名字傳到這個方法中去了，接下來就是Js自己處理了

Js Invoke Native:

而如果Js要調用Native中的Java方法呢？這就需要我們自己實作了，因為我們不采取

JavascriptInterface

的方式，而采取prompt方式

對WebView熟悉的同學們應該都知道Js中對應的

window.alert()

、

window.confirm()

、

window.prompt()

這三個方法的調用在

WebChromeClient

中都有對應的回調方法，分别為：

onJsAlert()

、

onJsConfirm()

、

onJsPrompt()

，對于它們傳入的

message

，都可以在相應的回調方法中接收到，是以，對于Js調Native方法，我們可以借助這個信道，和前端協定好一段特定規則的

message

，這個規則中應至少包含這些資訊：

所調用Native方法所在類的類名

所調用Native的方法名

Js調用Native方法所傳入的參數

是以基于這些資訊，很容易想到使用http協定的格式來協定規則，如下格式：

scheme://host:port/path?query

對應的我們協定

prompt

 傳入

message

的格式為:

jsbridge://class:port/method?params

這樣以來，前端和app端協商好後，以後前端需要通過Js調用Native方法來擷取一些資訊或功能，就隻需要按照協定的格式把需要調用的類名、方法名、參數放入對應得位置即可，而我們會在

onJsPrompt

方法中接受到，是以我們根據與前端協定好的協定來進行解析，我們可以用一個

Uri

來包裝這段協定，然後通過

Uri:getHost、getPath、getQuery

方法擷取對應的類名，方法名，參數資料，最後通過反射來調用指定類中指定的方法

而此時會有人問？

port

是用來幹嘛的？params格式是KV還是什麼格式？

當然，既然和前端協定好了協定的格式了，那麼params肯定也是需要協定好的，可以用KV格式，也可以用一串Json字元串表示，為了解析友善，還是建議使用

Json格式

而

port

是用來幹嘛的呢？

port

 我們并不會直接操作它，它是由Js代碼自動生成的，port的作用是為了辨別Js中的回調

function

 ,當Js調用Native方法時，我們會得到本次調用的

port

 号，我們需要在Native方法執行完畢後再把該

port

 、執行的後結果、是否調用成功、調用失敗的msg等資訊通過調用Js的

onComplete

 方法傳入，這時候Js憑什麼知道你本次傳回的資訊是哪次調用的結果呢？就是通過

port

 号，因為在Js調用Native方法時我們會把自動生成的

port

 号和此次回調的

function

 綁定在一起，這樣以來Native方法傳回結果時把

port

 也帶過來，就知道是哪次回調該用哪個

function

 方法來處理

自動生成

port

和綁定

function回調

的Js代碼如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
      
generatePort: function () {
    return Math.floor(Math.random() * (1 << 50)) + '' + increase++;
},
//調用Native方法
callMethod: function (clazz, method, param, callback) {
    var port = PrivateMethod.generatePort();
    if (typeof callback !== 'function') {
        callback = null;
    }
    //綁定對應port的function回調函數
    PrivateMethod.registerCallback(port, callback);
    PrivateMethod.callNativeMethod(clazz, port, method, param);
},
onComplete: function (port, result) {
    //把Native傳回的Json字元串轉為JSONObject
    var resultJson = PrivateMethod.str2Json(result);
    //擷取對應port的function回調函數
    var callback = PrivateMethod.getCallback(port).callback;
    PrivateMethod.unRegisterCallback(port);
    if (callback) {
        //執行回調
        callback && callback(resultJson);
    }
}

Js代碼上已經注釋的很清楚了，就不多解釋了。

經過上面介紹，那麼在Native方法執行完成後，當然就需要把結果傳回給Js了，那麼結果的格式又是什麼呢？傳回給Js方法又是什麼呢？

沒錯，還是需要和前端進行協定，建議資料的傳回格式為Json字元串，基本格式為：

1
2
3
4
5
6
7
      
resultData = {
    status: {
        code: 0,//0:成功，1:失敗
        msg: '請求逾時'//失敗時候的提示，成功可為空
    },
    data: {}//資料，無資料可以為空
};

其中定義了一個

status

，這樣的好處是無論在Native方法調用成功與否、Native方法是否有傳回值，Js中都可以收到傳回的資訊，而這個Json字元串至少都會包含一個

status

Json對象來描述Native方法調用的狀況

而傳回給Js的方法自然是上面的

onComplete

方法：

ps:RainbowBridge是我的JsBridge架構的名字

至此Js調用Native的流程就分析完成了，一切都看起來那麼美妙，因為，我們自己實作一套

Js Invoke Native

的主要目的是讓Js調用Native更加安全，同時也隻維護一套

JsBridge

架構更加友善，那麼這個安全性表現在哪裡了？

我們知道之前原生的方式漏洞就是惡意Js代碼可能會調用Native中的其它方法，那麼答案出來了，如果需要讓

Js Invoke Native

保證安全性，隻需要限制我們通過反射可調用的方法，是以，在JsBridge架構中，我們需要對Js能調用的Native方法給予一定的規則，隻有符合這些規則Js才能調用，而我的規則是：

1、Native方法包含public static void 這些修飾符（當然還可能有其它的，如：synchronized）

2、Native方法的參數數量和類型隻能有這三個：WebView、JSONObject、JsCallback。為什麼要傳入這三個參數呢？

2.1、第一個參數是為了提供一個WebView對象，以便擷取對應Context和執行WebView的一些方法

2.2、第二個參數就是Js中傳入過來的參數，這個肯定要的

2.3、第三個參數就是當Native方法執行完畢後，把執行後的結果回調給Js對應的方法中

是以符合Js調用的Native方法格式為：

1
2
3
4
      
public static void ***(WebView webView, JSONObject data, JsCallback callback) {
	//get some info ...
	JsCallback.invokeJsCallback(callback, true, result, null);
}

判斷Js調用的方法是否符合該格式的代碼為，符合則存入一個Map中供Js調用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
      
private void putMethod(Class<?> clazz) {
    if (clazz == null)
        return;
    ArrayMap<String, Method> arrayMap = new ArrayMap<>();
    Method method;
    Method[] methods = clazz.getDeclaredMethods();
    int length = methods.length;
    for (int i = 0; i < length; i++) {
        method = methods[i];
        int methodModifiers = method.getModifiers();
        if ((methodModifiers & Modifier.PUBLIC) != 0 && (methodModifiers & Modifier.STATIC) != 0 && method.getReturnType() == void.class) {
            Class<?>[] parameterTypes = method.getParameterTypes();
            if (parameterTypes != null && parameterTypes.length == 3) {
                if (WebView.class == parameterTypes[0] && JSONObject.class == parameterTypes[1] && JsCallback.class == parameterTypes[2]) {
                    arrayMap.put(method.getName(), method);
                }
            }
        }
    }
    mArrayMap.put(clazz.getSimpleName(), arrayMap);
}

對于有傳回值的方法，并不需要設定它的傳回值，因為方法的結果最後我們是通過

JsCallback.invokeJsCallback

來進行對Js層的回調，比如我貼一個符合該格式的Native方法：

1
2
3
4
5
6
7
8
9
      
public static void getOsSdk(WebView webView, JSONObject data, JsCallback callback) {
    JSONObject result = new JSONObject();
    try {
        result.put("os_sdk", Build.VERSION.SDK_INT);
    } catch (JSONException e) {
        e.printStackTrace();
    }
    JsCallback.invokeJsCallback(callback, true, result, null);
}

Js調Native代碼執行耗時操作情況處理

一般情況下，比如我們通過Js調用Native方法來擷取AppName、OsSDK版本、IMSI号、使用者資訊等都不會有問題，但是，假如該Native方法需要執行一些耗時操作，如：IO、sp、Bitmap Decode、SQLite等，這時為了保護UI的流暢性，我們需要讓這些操作執行在異步線程中，待執行完畢再把結果回調給Js，而我們可以提供一個線程池來專門處理這些耗時操作，如：

1
2
3
4
5
6
7
8
9
      
public static void doAsync(WebView webView, JSONObject data, final JsCallback callback) {
    AsyncTaskExecutor.runOnAsyncThread(new Runnable() {
        @Override
        public void run() {
            //IO、sp、Bitmap Decode、SQLite
            JsCallback.invokeJsCallback(callback, true, result, null);
        }
    });
}

【注】：對于WebView，它的方法的調用隻能在主線程中調用，當設計到WebView的方法調用時，切記不可以放在異步線程中調用，否則就GG了.

Js調Native流程圖

Native與H5互動的那些事

JsBridge效果圖

Native與H5互動的那些事

RainbowBridge:github位址

白名單Check

上面我們介紹了JsBridge的基本原理，實作了Js與Native互相調用，而且還避免了惡意Js代碼調用Native方法的安全問題，通過這樣我們保證了Js調用Native方法的安全性，即Js不能随意調用任意Native方法，不過，對于WebView容器來說，它并不關心所加載的url是Js代碼還是網頁位址，它所做的工作就是執行我們傳入的url，而WebView加載url的方式有兩種：get和post，方式如下：

1
2
      
mWebView.loadUrl(url);//get
mWebView.postUrl(url,data);//post

對于這兩種方式，也有不同的應用點，一般get方式用于查，也就是傳入的資料不那麼重要，比如：商品清單頁、商品詳情頁等，這些傳入的資料隻是一些商品類的資訊。而post方式一般用于改，post傳入的資料往往是比較私密的，比如：訂單界面、購物車界面等，這些界面隻有在把使用者的資訊post給伺服器後，伺服器才能正确的傳回相應的資訊顯示在界面上。是以，對于post方式涉及到使用者的私密資訊，我們總不能給一個url就把私密資料往這個url裡面發吧，當然不可能的，這涉及到安全問題，那麼就需要一個白名單機制來檢查url是否是我們自己的，是我們自己的那麼即可以post資料，不是我們自己的那就不post資料，而白名單的定義通常可以以我們自己的域名來判斷，搞一個正規表達式，是以我們可以重寫WebView的

postUrl

方法：

1
2
3
4
5
6
7
8
      
@Override
public void postUrl(String url, byte[] postData) {
    if (JsBridgeUrlCheckUtil.isTrustUrl(url)) {
        super.postUrl(url, postData);
    } else {
        super.postUrl(url, null);
    }
}

這樣就對不是我們自己的url進行了攔截，不把資料發送到不是我們自己的伺服器中

至此，白名單的Check還沒有完成，因為這隻是對WebView加載Url時候做的檢查，而在WebView内各中連結的跳轉、其中有些url還可能被營運商劫持注入了廣告，這就有可能在WebView容器内的跳轉到某些界面後，該界面的url并不是我們自己的，但是它裡面有Js代碼調用Native方法來擷取一些資料，雖然說Js并不能随便調我們的Native方法，但是有些我們指定可以被調用的Native方法可能有一些擷取裝置資訊、讀取檔案、擷取使用者資訊等方法，是以，我們也應該在Js調用Native方法時做一層白名單Check，這樣才能保證我們的資訊安全

是以，白名單檢測需要在兩個地方進行檢測：

1、WebView:postUrl()前檢測url的合法性

2、Js調用Native方法前檢測目前界面url的合法性

具體代碼如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
      
@Override
public void postUrl(String url, byte[] postData) {
    if (JsBridgeUrlCheckUtil.isTrustUrl(url)) {
        super.postUrl(url, postData);
    } else {
        super.postUrl(url, null);
    }
}

 /**
 * @param webView WebView
 * @param message rainbow://class:port/method?params
 */
public void call(WebView webView, String message) {
    if (webView == null || TextUtils.isEmpty(message))
        return;
    if (JsBridgeUrlCheckUtil.isTrustUrl(webView.getUrl())) {
        parseMessage(message);
        invokeNativeMethod(webView);
    }
}

移除預設内置接口

WebView内置預設也注入了一些接口，如下：

1
2
3
4
5
6
      
//移除預設内置接口,防止遠端代碼執行漏洞攻擊
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
    mWebView.removeJavascriptInterface("searchBoxJavaBridge_");
    mWebView.removeJavascriptInterface("accessibility");
    mWebView.removeJavascriptInterface("accessibilityTraversal");
}

這些接口雖然不會影響用prompt方式實作的Js與Native互動，但是在使用addJavascriptInterface方式時，有可能有安全問題，最好移除

WebView相關

WebView的配置

下面給出WebView的通用配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
      
WebSettings webSettings = mWebView.getSettings();
webSettings.setJavaScriptEnabled(true);
webSettings.setJavaScriptCanOpenWindowsAutomatically(true);
webSettings.setSupportZoom(false);
webSettings.setBuiltInZoomControls(false);
webSettings.setAllowFileAccess(true);
webSettings.setDatabaseEnabled(true);
webSettings.setDomStorageEnabled(true);
webSettings.setGeolocationEnabled(true);
webSettings.setAppCacheEnabled(true);
webSettings.setAppCachePath(getApplicationContext().getCacheDir().getPath());
webSettings.setDefaultTextEncodingName("UTF-8");
//螢幕自适應
webSettings.setUseWideViewPort(true);
webSettings.setLoadWithOverviewMode(true);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
    webSettings.setCacheMode(WebSettings.LOAD_CACHE_ELSE_NETWORK);
} else {
    webSettings.setCacheMode(WebSettings.LOAD_DEFAULT);
}
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
    webSettings.setDisplayZoomControls(false);
}
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
    webSettings.setLoadsImagesAutomatically(true);
} else {
    webSettings.setLoadsImagesAutomatically(false);
}

mWebView.setScrollBarStyle(WDWebView.SCROLLBARS_INSIDE_OVERLAY);
mWebView.setHorizontalScrollBarEnabled(false);
mWebView.setHorizontalFadingEdgeEnabled(false);
mWebView.setVerticalFadingEdgeEnabled(false);

其中有一項配置，是在4.4以上版本時設定網頁内圖檔可以自動加載，而4.4以下版本則不可自動加載，原因是4.4WebView核心的改變，使得WebView的性能更優，是以在4.4以下版本不讓圖檔自動加載，而是先讓WebView加載網頁的其它靜态資源：js、css、文本等等，待網頁把這些靜态資源加載完成後，在

onPageFinished

方法中再把圖檔自動加載打開讓網頁加載圖檔：

1
2
3
4
5
6
7
      
@Override
public void onPageFinished(WebView view, String url) {
    super.onPageFinished(view, url);
    if (!mWebView.getSettings().getLoadsImagesAutomatically()) {
        mWebView.getSettings().setLoadsImagesAutomatically(true);
    }
}

WebView的獨立程序

通常來說，WebView的使用會帶來諸多問題，記憶體洩露就是最常見的問題，為了避免WebView記憶體洩露，目前最流行的有兩種做法：

1、獨立程序，簡單暴力，不過可能涉及到程序間通信

2、動态添加WebView，對傳入WebView中使用的Context使用弱引用，動态添加WebView意思在布局建立個ViewGroup用來放置WebView，Activity建立時add進來，在Activity停止時remove掉

個人推薦獨立程序，好處主要有兩點，一是在WebViewActivity使用完畢後直接幹掉該程序，防止了記憶體洩露，二是為我們的app主程序減少了額外的記憶體占用量

使用獨立程序還需注意一點，這個程序中在有多個WebViewActivity，不能在Activity銷毀時就幹掉程序，不然其它Activity也會蹦了，此時應該在該程序建立一個Activity的維護集合，集合為空時即可幹掉程序

關于WebView的銷毀，如下：

1
2
3
4
5
6
7
8
9
10
11
      
private void destroyWebView(WebView webView) {
    if (webView == null)
        return;
    webView.stopLoading();
    ViewParent viewParent = webView.getParent();
    if (viewParent != null && viewParent instanceof ViewGroup)
        ((ViewGroup) viewParent).removeView(webView);
    webView.removeAllViews();
    webView.destroy();
    webView = null;
}

WebView的相容性

不同版本硬體加速的問題 

1
2
3
4
5
6
7
8
9
10
      
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH_MR1 && shouldOpenHardware()) {
    mWebView.setLayerType(View.LAYER_TYPE_HARDWARE, null);
}
public static boolean shouldOpenHardware () {
    if ("samsung".equalsIgnoreCase(Build.BRAND))
        return false;
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP)
        return true;
    return true;
}

不同裝置點選WebView輸入框鍵盤的不彈起 

1
2
3
4
5
6
7
8
9
10
11
12
      
mWebView.setOnTouchListener(new View.OnTouchListener() {
    @Override
    public boolean onTouch(View v, MotionEvent event) {
        try {
            if (mWebView != null)
                mWebView.requestFocus();
        } catch (Exception e) {
            e.printStackTrace();
        }
        return false;
    }
});

三星手機硬體加速關閉後導緻H5彈出的對話框出現不消失情況 

1
2
3
4
5
6
      
String brand = android.os.Build.BRAND;
if ("samsung".equalsIgnoreCase(brand) && Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
    getWindow().setFlags(
            WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
            WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);
}

不同版本shouldOverrideUrlLoading的回調時機

對于

shouldOverrideUrlLoading

的加載時機，有些同學經常與

onProgressChanged

這個方法的加載時機混淆，這兩個方法有兩點不同：

1、

shouldOverrideUrlLoading

 隻會走Get方式的請求，Post方式的請求将不會回調這個方法，而

onProgressChanged

對Get和Post都會走

2、

shouldOverrideUrlLoading

 都知道在WebView内部點選連結（Get）會觸發，它在Get請求打開界面時也會觸發，

shouldOverrideUrlLoading

 還有一點特殊，就是在按傳回鍵傳回到上一個頁面時時不會觸發的，而

onProgressChanged

 在隻要界面更新了都會觸發

對于

shouldOverrideUrlLoading

的傳回值，傳回true為剝奪WebView對該此請求的控制權，交給應用自己處理，是以WebView也不會加載該url了，傳回false為WebView自己處理

對于

shouldOverrideUrlLoading

的調用時機，也會有不同，在3.0以上是會正常調用的，而在3.0以下，并不是每次都會調用，可以在

onPageStarted

方法中做處理，也沒必要了，現在應該都适配4.0以上了

頁面重定向導緻WebView:goBack()無效的處理

像一些界面有重定向，比如：淘寶等，需要按多次（>1）才能正常傳回，一般都是二次，是以可以把那些具有重定向的界面存入一個集合中，在攔截傳回事件中這樣處理：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
      
@Override
public void onBackPressed() {
    if (mWebView == null)
        return;
    WebBackForwardList backForwardList = mWebView.copyBackForwardList();
    if (backForwardList != null && backForwardList.getSize() != 0) {
        int currentIndex = backForwardList.getCurrentIndex();
        WebHistoryItem historyItem = backForwardList.getItemAtIndex(currentIndex - 1);
        if (historyItem != null) {
            String backPageUrl = historyItem.getUrl();
            if (TextUtils.isEmpty(backPageUrl))
                return;
            int size = REDIRECT_URL.size();
            for (int i = 0; i < size; i++) {
                if (backPageUrl.contains(REDIRECT_URL.get(i)))
                    mWebView.goBack();
            }
        }
    }
    if (mWebView.canGoBack()) {
        mWebView.goBack();
    } else {
        this.finish();
    }
}

這裡處理是在按傳回鍵時，如果上一個界面是重定向界面，則直接調用goBack，或者也可以finish目前Activity

WebView無法加載不信任網頁SSL錯誤的處理

有時我們的WebView會加載一些不信任的網頁，這時候預設的處理是WebView停止加載了，而那些不信任的網頁都不是由CA機構信任的，這時候你可以選擇繼續加載或者讓手機内的浏覽器來加載：

1
2
3
4
5
6
      
@Override
public void onReceivedSslError(WebView view, final SslErrorHandler handler, SslError error) {
    //繼續加載
    handler.proceed();
    //或者其它處理 ...
}

自定義WebView加載出錯界面

出錯的界面的顯示，可以在這個方法中控制：

1
2
3
4
      
@Override
public void onReceivedError(WebView view, WebResourceRequest request, WebResourceError error) {
    super.onReceivedError(view, request, error);
}

你可以重新加載一段Html專門用來顯示錯誤界面，或者用布局顯示一個出錯的View，這時候需要把出錯的WebView内容清除，可以使用：

1
2
3
4
5
6
      
@Override
public void onReceivedError(WebView view, WebResourceRequest request, WebResourceError error) {
    super.onReceivedError(view, request, error);
    view.loadDataWithBaseURL(null,"","text/html","UTF-8",null);
    errorView.setVisibility(View.VISIBLE);
}

擷取位置權限的處理

如果在WebView中有擷取地理位置的請求，那麼可以直接在代碼中預設處理了，沒必要彈出一個框框讓使用者每次都确認：

1
2
3
4
5
      
@Override
public void onGeolocationPermissionsShowPrompt(String origin, GeolocationPermissions.Callback callback) {
    super.onGeolocationPermissionsShowPrompt(origin, callback);
    callback.invoke(origin, true, false);
}

打造一個通用的WebViewActivity界面

一個通用的WebViewActivity當然是樣式和WebView内部處理的政策都統一樣，這裡隻對樣式進行說明，因為WebView内部的處理各個公司都不一樣，但應該都需要包含這麼幾點吧：

1、白名單檢測

2、Url的跳轉

3、出錯的處理

4、…

一個WebViewActivity界面，最主要的就是Toolbar标題欄的設計了，因為不同的app的WebViewActivity界面Toolbar上有不同的icon和操作，比如：分享按鈕、重新整理按鈕、更多按鈕，都不一樣，既然需要通用，即可讓調用者傳入某個參數來動态改變這些東西吧，比如傳一個ToolbarStyle來辨別此WebViewActivity的風格是什麼樣的，背景色、字型顔色、圖示等，包括點選時的動畫效果，作為通用的界面，必須是讓調用者簡單操作，不可能調用時傳入一個圖示id還是一個Drawable，是以，主要需要用到tint，來對字型、圖示的顔色動态改變，代碼如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
      
public static ColorStateList createColorStateList(int normal, int pressed) {
    int[] colors = new int[]{normal, pressed};
    int[][] states = new int[2][];
    states[0] = new int[]{-android.R.attr.state_pressed};
    states[1] = new int[]{android.R.attr.state_pressed};
    return new ColorStateList(states, colors);
}

public static Drawable tintDrawable(Drawable drawable, int color) {
    final Drawable tintDrawable = DrawableCompat.wrap(drawable.mutate());
    ColorStateList colorStateList = ColorStateList.valueOf(color);
    DrawableCompat.setTintMode(tintDrawable, PorterDuff.Mode.SRC_IN);
    DrawableCompat.setTintList(tintDrawable, colorStateList);
    return tintDrawable;
}

H5與Native界面互相喚起

對于H5界面，有些操作往往是需要喚起Native界面的，比如：H5中的登入按鈕，點選後往往喚起Native的登入界面來進行登入，而不是直接在H5登入，這樣一個app就隻需要一套登入了，而我們所做的便是攔截登入按鈕的url：

1
2
3
4
5
      
@Override
public boolean shouldOverrideUrlLoading(WebView view, String url) {
    parserURL(url); //解析url,如果符合跳轉native界面的url規則，則跳轉native界面
    return super.shouldOverrideUrlLoading(view, url);
}

這個規則我們可以在Native的Activity的

intent-filter

中的

data

來定義，如下：

1
2
3
4
5
6
7
8
9
10
      
<activity android:name=".LoginActivity">
    <intent-filter>
        <action android:name="android.intent.action.VIEW"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <data
            android:host="native"
            android:path="/login"
            android:scheme="activity"/>
    </intent-filter>
</activity>

解析url過程是判斷scheme、host、path的是否有完全與之比對的，有則喚起

而Native喚H5，其實也是一個url的解析過程，隻不過需要配置WebViewActivity的

intent-filter

的

data

，WebViewActivity的scheme配置為http和https

startActivity VS UrlRouter

上面說到了H5與Native互相調起，其實這個可以在app内做成一套界面跳轉的方式，摒棄startActivity，為什麼原生的跳轉方式不佳？

1、因為原生的跳轉需要确定該Activity是已經存在的，否則編譯将報錯，這樣帶來的問題是不利于協同開發，如：A、B同學分别正在開發項目的兩個不同的子產品，此時B剛好需要跳A同學的某一個界面，如商品清單頁跳商品詳情頁，這時候B就必須寫個TODO，待B完成該子產品後再寫了。而通過url跳轉，隻需要傳入一串url即可

2、原生的跳轉Activity與目标Activity是耦合的，跳轉Activity完全依賴于目标Activity

3、原生的跳轉方式不利于管理所傳遞來的參數，擷取參數時需要在跳轉Activity的地方确定傳遞了幾個參數、什麼類型的參數，這樣以來跳轉的方式多了，就比較混亂了。當然一個原生跳轉良好的設計是在目的Activity實作一個靜态的start方法，其它界面要跳直接調用即可

4、最後一個就是在有參數傳遞的情況下，每次跳轉都要寫好多代碼啊

而UrlRouter架構的實作原理，一種實作是可以維護一套Activity與url的映射表，這種方式還是沒有擺脫不利于協同開發這個毛病，另外一種是通過一串指定規則的url與manifest中配置的data比對，具體跳轉則是通過

intent.setData()

來設定跳轉的url，這種方式比較好，不過需要處理下比對到多個Activity時優先選擇的問題

JsBridge位址 ： RainbowBridge

android jsbridge Webview WebView安全 相容性
上一篇: android jsbridge實作原理簡述
下一篇: jsbridge.BridgeWebView的基礎使用以及屬性詳解

繼續閱讀