摘要：在這里介紹移動(dòng)中嵌入網(wǎng)頁，優(yōu)化頁面顯示速度。測(cè)試代碼如果后面找到解決方案，會(huì)更新到后面。一次移動(dòng)優(yōu)化之旅二參考使用的分析頁面性能技術(shù)筆記詳解網(wǎng)頁渲染過程

在這里介紹移動(dòng)App中嵌入網(wǎng)頁，優(yōu)化頁面顯示速度。

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

在經(jīng)過愉快的編寫組件后，打包組件形成組件庫文件，然后被頁面引用。配置到 App 中后，run···，發(fā)現(xiàn)界面顯示出來很慢，2s左右才會(huì)出現(xiàn)界面和數(shù)據(jù)。

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

為什么2s左右才會(huì)出現(xiàn)，使用工具測(cè)試了下。chrome dev tools 下的 timeline 分析工具很贊。

具體操作方法：

在 chrome 瀏覽器地址欄輸入 chrome://inspect 這個(gè)是遠(yuǎn)程調(diào)試工具，調(diào)試 App 應(yīng)用中的 html 神器。

選擇 chrome 下檢查到的你的網(wǎng)頁，點(diǎn)擊 inspect 進(jìn)入就行。

這里你的手機(jī)應(yīng)該是連著電腦的。

選中 timeline 工具，打開分析，刷新網(wǎng)頁。 結(jié)果就出來了

效果如圖：

讀取 url 后，webkit 調(diào)用資源加載器加載 html 資源。在上圖中可以看到觸發(fā)了6個(gè)操作。

我們從時(shí)序上開始分析。

Send Request 根據(jù)url取資源文件，請(qǐng)求發(fā)送

Receive Response 應(yīng)答返回時(shí)，觸發(fā)這個(gè)

Receive Data 接受資源文件內(nèi)容，如果文件比較大的話，會(huì)觸發(fā)多次

Recaculate Style 重新計(jì)算樣式，根據(jù)html返回的內(nèi)容，計(jì)算樣式

Finish Loading 文件處理完成

Parse HTML 顯示頁面？？？

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

附上 html 代碼：

    
    
    
    
    
    
    
    


Hello World

html頁面中有節(jié)點(diǎn) script, link 遇到這些 Webkit 又要調(diào)用資源加載器來加載資源了。效果圖如下：

可以看到，這些資源請(qǐng)求是異步的，就是說請(qǐng)求資源的請(qǐng)求是同時(shí)發(fā)出去的，沒有等上個(gè)資源返回后再發(fā)送。

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

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

scriping 這個(gè)部分是線性的，javascript 的特性。

css, js文件解析過程中，又有 url 鏈接圖片什么的，又是請(qǐng)求發(fā)送。

在 App 中出現(xiàn)頁面的最后一刻，有個(gè) scriping 的過程，這里的觸發(fā)事件在左側(cè)顯示為 GC Event, 這個(gè)是什么東西？？？

通過上面的分析，優(yōu)化頁面顯示的時(shí)間，個(gè)人認(rèn)為主要有幾個(gè)方向：

Send Request <--> Receive Response, Receive Data

這個(gè)過程中，如果你的頁面是遠(yuǎn)程服務(wù)器上，那么這個(gè)就和網(wǎng)絡(luò)有關(guān)了，網(wǎng)絡(luò)要好，文件要壓縮變小。

對(duì)于多個(gè)文件是否要合并為一個(gè)文件，從 `timeline` 時(shí)序上看，請(qǐng)求是并行的，如果帶寬和請(qǐng)求鏈接數(shù)沒有限制的話，個(gè)人感覺分開請(qǐng)求比較好。

當(dāng)然也不能太多了，每個(gè)文件幾k，這樣就合并就沒有天理了。

scripting 階段，這個(gè)是讀js代碼邏輯，就是把js文件執(zhí)行一遍。 這里的優(yōu)化就看你的業(yè)務(wù)邏輯了。

圖片資源，動(dòng)態(tài)圖下載，圖片請(qǐng)求的 Send Request <--> Receive Response 之間的響應(yīng)太長(zhǎng)了，

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

如圖：

對(duì)于目前個(gè)人的需求，文件放在本地，所以

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

還有一個(gè)想法是調(diào)用 React 中 server 的 renderToString 方法，先生成靜態(tài)頁面，顯示內(nèi)容。這里就是在載入 html 頁面后，直接顯示。

設(shè)想的結(jié)果：

載入html，顯示出來

現(xiàn)在js，css，圖片等資源文件，準(zhǔn)備好后更新頁面

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

這是為什么？？？（設(shè)想結(jié)果1沒有）

在手機(jī)的瀏覽器中就么有這個(gè)問題？？？ why ？？？

手機(jī)App中，看到有2個(gè)js文件耗時(shí)很大: __tdx_vendor.js, __tdx_client.js

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

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

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

webpack 打包后的文件，需要讀取的時(shí)候，每個(gè)都要花費(fèi)這么長(zhǎng)的時(shí)間？？？

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

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

感覺說的有點(diǎn)亂，目前存在的問題：

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

測(cè)試代碼:

// 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)
}()

如果后面找到解決方案，會(huì)更新到后面。

20160602-2002

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

Sorry

今天又測(cè)試了下，這個(gè)地方還是有時(shí)是卡頓 5s 出現(xiàn)界面，有時(shí)不會(huì)卡頓 5s 就出現(xiàn)了界面。（這里的刷新界面不夠穩(wěn)定，帶有隨機(jī)性。）

一次移動(dòng)優(yōu)化之旅（二）

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

Webkit技術(shù)筆記(2):詳解 webkit 網(wǎng)頁渲染過程