JSBridge通讯时间测试

时间 2019-11-08

标签 jsbridge 通讯时间测试繁體版

原文原文链接

写在前面

每次想写点东西，但老是以为心中有千万种骚操做，就是手跟不上大脑。别说了又要超鬼被举报了。前端

今天仍是决定整理下最近的笔记了。先从JsBridge 通讯耗时测试开始吧。下面统称JsB。git

正文

以前hybrid项目中遇到过一个卡顿问题，现象是当JsB传递数据越大时页面就越容易出现卡顿。一时间觉得是原生部分因，因而经过断点发现，其实卡顿发生在原生接受到JsB消息以前，也就是说是在H5部分或者JsB处理部分，因为本身前端刚入门，还特地去咨询项目中的前端同事，多是问题说的不清楚，最终估计是觉得我在给他找问题，结果就直接说前端只有业务不会形成卡顿。 [图片] github

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

JsB通讯的三个部分，先看看JSB消息传递的调用顺序。web

Native 调 JS bash

JS 调 Native

图片引用自 www.jianshu.com/p/fce3e2f9c… 上图为安卓的调用顺序。 iOS的其实也没什么差异，只是对应的原生接口名称不同而。 WebviewJavaScriptBridge 原理图.png

图画的很丑，将就看吧。

加入埋点

从上图看到各个部分的调用顺序。因此，咱们先看看JS调Native的耗时。ide

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本身找下回调函数）fetch

- (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的消耗时间啦。ui

原生部分

部分就忽略了，使用CFAbsoluteTimeGetCurrent() 作代码执行时间测试相对更加准确。

写在最后

上面纯属我的看法，若是疏漏的地方，请指教。

11.15 更新

demo地址