JSBridge通訊時間測試

寫在前面

每次想寫點東西，但老是以爲心中有千萬種騷操做，就是手跟不上大腦。別說了又要超鬼被舉報了。

今天仍是決定整理下最近的筆記了。先從JsBridge 通訊耗時測試開始吧。下面統稱JsB。

正文

以前hybrid項目中遇到過一個卡頓問題，現象是當JsB傳遞數據越大時頁面就越容易出現卡頓。一時間覺得是原生部分 因，因而經過斷點發現，其實卡頓發生在原生接受到JsB消息以前，也就是說是在H5部分或者JsB處理部分，因爲本身前端剛入門，還特地去諮詢項目中的前端同事，多是問題說的不清楚，最終估計是覺得我在給他找問題，結果就直接說前端只有業務不會形成卡頓。 [圖片]

因此讓我想起了那句話，Talk is cheap.show me the code.

JsB通訊的三個部分，先看看JSB消息傳遞的調用順序。

Native 調 JS

JS 調 Native

圖片引用自 www.jianshu.com/p/fce3e2f9c… 上圖爲安卓的調用順序。 iOS的其實也沒什麼差異，只是對應的原生接口名稱不同而。 WebviewJavaScriptBridge 原理圖.png

圖畫的很醜，將就看吧。

加入埋點

從上圖看到各個部分的調用順序。因此，咱們先看看JS調Native的耗時。

JS部分的時間

onclick() 到 JsB的doSend()方法，由於這部分都是JS代碼，只要在onclick()時給window對象加一個屬性window.JSTime記錄觸發onclick()的瞬時間，而後再JsB的doSend()函數中當前時間減去window.JSTime就是JS部分的時間。 JsB部分時間

doSend()到原生接受到第一條消息也就是觸發webview的- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler （本人用的WKWebview,若是是UIWebview本身找下回調函數）

- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler {
    if (webView != _webView) { return; }
    NSURL *url = navigationAction.request.URL;
    __strong typeof(_webViewDelegate) strongDelegate = _webViewDelegate;

    if ([_base isWebViewJavascriptBridgeURL:url]) {
        if ([_base isBridgeLoadedURL:url]) {
            [_base injectJavascriptFile];
        } else if ([_base isQueueMessageURL:url]) {
            [self WKFlushMessageQueue];
        } else {
            [_base logUnkownMessage:url];
        }
        decisionHandler(WKNavigationActionPolicyCancel);
        return;
    }
    
    if (strongDelegate && [strongDelegate respondsToSelector:@selector(webView:decidePolicyForNavigationAction:decisionHandler:)]) {
        [_webViewDelegate webView:webView decidePolicyForNavigationAction:navigationAction decisionHandler:decisionHandler];
    } else {
        decisionHandler(WKNavigationActionPolicyAllow);
    }
}
複製代碼

可是咱們查看WebViewJavascriptBridge源碼發現，在觸發原生回調後，webview仍是繼續調JsB的WebViewJavascriptBridge._fetchQueue()。因此JsB部分的時間，只須要在doSend()給window添加一個埋點window.JsBTime,而後在_fetchQueue()return的前面一行獲取瞬時時間減去window.JsBTime就是JsB的消耗時間啦。

原生部分

部分就忽略了，使用CFAbsoluteTimeGetCurrent() 作代碼執行時間測試相對更加準確。

寫在最後

上面純屬我的看法，若是疏漏的地方，請指教。

11.15 更新

demo地址