摘要：在這里介紹移動中嵌入網頁，優化頁面顯示速度。測試代碼如果后面找到解決方案，會更新到后面。一次移動優化之旅二參考使用的分析頁面性能技術筆記詳解網頁渲染過程

在這里介紹移動App中嵌入網頁，優化頁面顯示速度。

最近在Boss的要求下，寫組件模式的移動頁面。這里選擇的庫是react。（為什么？ 入門簡單 + JSX）。

在經過愉快的編寫組件后，打包組件形成組件庫文件，然后被頁面引用。配置到 App 中后，run···，發現界面顯示出來很慢，2s左右才會出現界面和數據。

不開心了，速度太慢。所以準備分析慢的原因。所以有了這篇筆記，新手，輕噴。

為什么2s左右才會出現，使用工具測試了下。chrome dev tools 下的 timeline 分析工具很贊。

具體操作方法：

在 chrome 瀏覽器地址欄輸入 chrome://inspect 這個是遠程調試工具，調試 App 應用中的 html 神器。

選擇 chrome 下檢查到的你的網頁，點擊 inspect 進入就行。

這里你的手機應該是連著電腦的。

選中 timeline 工具，打開分析，刷新網頁。 結果就出來了

效果如圖：

讀取 url 后，webkit 調用資源加載器加載 html 資源。在上圖中可以看到觸發了6個操作。

我們從時序上開始分析。

Send Request 根據url取資源文件，請求發送

Receive Response 應答返回時，觸發這個

Receive Data 接受資源文件內容，如果文件比較大的話，會觸發多次

Recaculate Style 重新計算樣式，根據html返回的內容，計算樣式

Finish Loading 文件處理完成

Parse HTML 顯示頁面？？？

步驟6在手機瀏覽器中，是會提前顯示出來的，但是在 App 中怎么會不顯示呢？（這個求大神解決下）

附上 html 代碼：

    
    
    
    
    
    
    
    


Hello World

html頁面中有節點 script, link 遇到這些 Webkit 又要調用資源加載器來加載資源了。效果圖如下：

可以看到，這些資源請求是異步的，就是說請求資源的請求是同時發出去的，沒有等上個資源返回后再發送。

資源的加載重復上面加載 html 頁面的過程: send request -> receive data -> caculate (scripting 部分) -> finish。

在當前情形下，jquery 回來后，開始 scripting, 接著是 highcharts, ···

scriping 這個部分是線性的，javascript 的特性。

css, js文件解析過程中，又有 url 鏈接圖片什么的，又是請求發送。

在 App 中出現頁面的最后一刻，有個 scriping 的過程，這里的觸發事件在左側顯示為 GC Event, 這個是什么東西？？？

通過上面的分析，優化頁面顯示的時間，個人認為主要有幾個方向：

Send Request <--> Receive Response, Receive Data

這個過程中，如果你的頁面是遠程服務器上，那么這個就和網絡有關了，網絡要好，文件要壓縮變小。

對于多個文件是否要合并為一個文件，從 `timeline` 時序上看，請求是并行的，如果帶寬和請求鏈接數沒有限制的話，個人感覺分開請求比較好。

當然也不能太多了，每個文件幾k，這樣就合并就沒有天理了。

scripting 階段，這個是讀js代碼邏輯，就是把js文件執行一遍。 這里的優化就看你的業務邏輯了。

圖片資源，動態圖下載，圖片請求的 Send Request <--> Receive Response 之間的響應太長了，

中間還涉及了一個 `GC Event`, 這個有什么用？？？

如圖：

對于目前個人的需求，文件放在本地，所以

優化1，這里合并文件效果不大。
優化2，
對于外部引用，可以去掉外部引用組件邏輯，例如 jquery, highcharts 這些，或者找個好點的庫。
對于自身的邏輯，最好分析下流程，看看哪里耗時
優化3，那個 GC Event 的作用還不怎么清楚，研究中。

還有一個想法是調用 React 中 server 的 renderToString 方法，先生成靜態頁面，顯示內容。這里就是在載入 html 頁面后，直接顯示。

設想的結果：

載入html，顯示出來

現在js，css，圖片等資源文件，準備好后更新頁面

這樣可以消除頁面準備過程中，空白的問題。想法很好，但是現實很骨感。 在 App 中載入 html 頁面盡然沒有顯示出來，非要等js準備好后，才顯示界面，

這是為什么？？？（設想結果1沒有）

在手機的瀏覽器中就么有這個問題？？？ why ？？？

手機App中，看到有2個js文件耗時很大: __tdx_vendor.js, __tdx_client.js

這是2個什么文件，總的來說，我這邊文件引入的庫是 React，所有的文件通過 webpack 打包形成這2個文件。

具體的時序圖，在 chrome://inspect 中看不到，我們直接在瀏覽器中打開分析：

先不考慮外部文件的效率。

webpack 打包后的文件，需要讀取的時候，每個都要花費這么長的時間？？？

在 __tdx_vendor.js 中只有 react 和 react-dom 的 dist 文件。內容如下：

這里只是貼了前面的部分，所有的module都在這個自執行函數的參數中。一個個的參數開始執行并緩存下來。

感覺說的有點亂，目前存在的問題：

html加載完成，js，css等文件沒有finish的時候，在瀏覽器中會先顯示html原有的內容，然后再更新。但是在 App 中的 WebView 組件為什么沒有這樣的顯示邏輯。

測試代碼:

// index.html



    
    
    
    
    
    
    



This is a static page





// index.js
!function() {

    var date = new Date();
    var curDate = null;
    do {
        curDate = new Date();
    } while (curDate - date < 5000);

    setTimeout(function() {
        var el = document.getElementById("page");
        el.innerHTML = "This is a second page";
    }, 5000)
}()

如果后面找到解決方案，會更新到后面。

20160602-2002

我的問題，這個地方瀏覽器和移動App的顯示效果是一樣的。初次加載的時候，都會卡頓5s，等 index.js 執行完成后頁面才會出來。

Sorry

今天又測試了下，這個地方還是有時是卡頓 5s 出現界面，有時不會卡頓 5s 就出現了界面。（這里的刷新界面不夠穩定，帶有隨機性。）

一次移動優化之旅（二）

使用Chrome DevTools的Timeline分析頁面性能

Webkit技術筆記(2):詳解 webkit 網頁渲染過程