H5性能優化方面的探索

H5性能優化方面的探索

H5很重要,很重要,很重要,重要的事情必須重複多遍,H5的優勢:跨平臺、迭代快、開發體驗好。缺點:加載慢,用戶體驗差。因此在接下來很長一段時間內我將會從H5的幾個缺點發面去研究如何優化。css

1、緩存問題及其解決辦法

常常遇到一個問題,H5頁面因爲緩存問題常常在H5發佈新版本以後客戶端App看不到最新的效果,以前因爲雜七雜八的問題項目工期緊沒好好研究,最近抽空研究了下緩存問題。html

緩存問題具體表現爲:UIWebview首次打開加載慢;第二次加載速度明顯快;H5資源更新事後在App上看不到更改的效果git

爲此我認爲是緩存形成的問題,我進入App目錄下,看到Library下的Caches下面有不少文件名稱很長的文件,點擊預覽能夠看到是圖片、css等,原本我想着找出H5資源緩存到App中的特色,而後用NSFileManager刪除掉緩存文件,發現此路不通。web

我想經過控制變量法研究緩存是否存在。

作了一個實驗。步驟以下:

  • 用HBuilder(一個編輯器,開啓後本機端口8020就能夠訪問網頁)打開H5工程
  • 在App的一個UIWebview頁面上經過和電腦在同一個局域網的方式加載網頁
  • 在App上查看效果,觀察某個元素的樣式
  • 在HBuilder編輯器中修改元素樣式
  • 在App上將UIWebView返回上一界面,再次進入查看該元素的樣式
  • 肯定有沒有變化,來肯定有沒有緩存

結論:頁面實時效果變化的,沒有緩存瀏覽器

對比實驗:緩存

  • 用HBuilder(一個編輯器,開啓後本機端口8020就能夠訪問網頁)打開H5工程
  • git提交到服務端
  • 在App的一個UIWebview頁面上經過公網IP的方式加載網頁
  • 在App上查看效果,觀察某個元素的樣式
  • 在HBuilder編輯器中修改元素樣式
  • git提交後發佈到服務器上
  • 在App上將UIWebView返回上一界面,再次進入查看該元素的樣式
  • 肯定有沒有變化,來肯定有沒有緩存

結論:頁面沒有看到最新的效果,明顯緩存了。可是我很想知道爲何本地局域網的方式請求網頁不會緩存,而經過公網IP的方式會緩存。性能優化

爲此,我作了進一步的實驗,用谷歌瀏覽器分別請求本地局域網和公網ip查看資源加載的狀況。服務器

一、公網IP 網絡

二、本地局域網運維

關鍵詞Status Code

結論:從圖上能夠看出本地局域網無論首次加載仍是刷新都是直接請求;而經過局域網的方式請求:首次請求是從服務器上獲取,在此刷新的時候是從(from memory cache)中獲取的。

猜測

局域網 的方式網速都比較快因此不會緩存;

公網IP的方式可能因爲網速問題會將首次請求到的資源緩存下來。

因此肯定緩存存在了,那麼如何避免緩存?

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType {
    if (webView != _webView) { return YES; }
    NSURL *url = [rntity Tag 的資源直接訪問equest URL];
    if ([request.URL.absoluteString containsString:@"http"] || [request.URL.absoluteString containsString:@"https"]) {
        if ([request.URL.absoluteString containsString:@"?"]) {
            url = [NSURL URLWithString:[NSString stringWithFormat:@"%@&h5V=%@",request.URL.absoluteString,[ProjectUtil getH5VersionString]]];
        }else{
            url = [NSURL URLWithString:[NSString stringWithFormat:@"%@?h5V=%@",request.URL.absoluteString,[ProjectUtil getH5VersionString]]];
        }
    }
    LBPLOG(@"url->%@",[url absoluteString]);
    __strong WVJB_WEBVIEW_DELEGATE_TYPE* strongDelegate = _webViewDelegate;
    if ([_base isCorrectProcotocolScheme:url]) {
        if ([_base isBridgeLoadedURL:url]) {
            [_base injectJavascriptFile];
        } else if ([_base isQueueMessageURL:url]) {
            NSString *messageQueueString = [self _evaluateJavascript:[_base webViewJavascriptFetchQueyCommand]];
            [_base flushMessageQueue:messageQueueString];
        } else {
            [_base logUnkownMessage:url];
        }
        return NO;
    } else if (strongDelegate && [strongDelegate respondsToSelector:@selector(webView:shouldStartLoadWithRequest:navigationType:)]) {
        return [strongDelegate webView:webView shouldStartLoadWithRequest:request navigationType:navigationType];
    } else {
        return YES;
    }
}

總結:

App的緩存問題暫時研究到這裏,後期會繼續研究其餘方面的問題

拓展

經過瀏覽器咱們知道有的緩存是200 OK(from cache ),有的緩存是304 Not modified。若是運維移除了Entity Tag就一直是200(from cache)。若是沒有移除的話2者是交替出現的。

爲何2者會有區別?

  • 200 OK(from cache)是直接點擊連接或者在瀏覽器地址欄中輸入網址敲回車鍵的結果
  • 而304 modified是咱們刷新了瀏覽器頁面時觸發或者設置了長緩存、但Entity Tags沒有移除時觸發

作了 實驗得出結論:

  • 直接訪問有緩存的網站都觸發 200 OK (from cache)

  • 刷新瀏覽器則會觸發304

  • 同一域名下,沒有 Entity Tag 的資源直接訪問,是 200 OK (from cache) 的結果

  • 同一域名下,有Entity Tag 的資源直接訪問,是出現304 Not Modified

相關文章
相關標籤/搜索