那麼在移動互聯網發展到今天，native界面測試已經成爲傳統，webview+natvie模式已經漸漸來到我們身邊，目前市面上也有許許多多hybird類應用，並且我認爲這也是未來的趨勢，當然最大的好處就是更新成本低，直接更新h5就行了，同時也具有插件化的一些優點。
webview訪問基本流程
上圖是一個一般的http訪問流程，但是考慮到可能有重定向這個東西，所以以下面的圖爲準
重定向：這一過程其實也走了一遍流程，只不過在響應碼返回的是3xx，會指引瀏覽器重定向連接，這部分可能會導致一定的耗時問題，navigation timing api也提供了這一部分的時間統計。
DNS解析：先去緩存找有沒有dns緩存，如果再去hosts裏面，還是沒有就需要去dns服務器查詢了，因爲有這一層原因，測試的時候需要清除瀏覽器緩存。
tcp(https)：因爲http是基於tcp的應用層協議，所以需要先建立連接才能進行數據傳輸，如果是https連接，那麼需要建立https的鏈接，並進行ssl層的證書籤名校驗，然後才能正常地發送請求響應
request和response：正常發送請求並得到html
parse html：這裏webview其實已經拿到html數據了，接下來就是解析成dom樹，加載和渲染render，以及一些腳本和樣式加載操作，這部分依賴於瀏覽器內核，這部分瀏覽器一般是邊解析邊渲染，以便加快速度
上述的流程只是一個簡單歸納，每一個部分都可以擴展很多內容，更多內容可以參考tcp/ip詳解和html加載，瀏覽器渲染的相關內容。
navigation timing api的使用說明
那麼這個api是html 5引入的一個統計web界面的新api，對於傳統統計web耗時，和移動端測試耗時一樣都是在代碼裏面打點，然後log輸出。但是代碼統計的方式一是繁瑣，而是可能會影響統計時間，所以navigation timing api就誕生了，這套api使用方便，並且是在界面打開之後才統計的，所以對性能影響是微乎其微的，而且這套api是原生支持android的webview調試了，所以爲我們測試webview提供的良好的支持。
使用方法非常簡單，在chrome按F12就可以出來了，這套api是依賴於window.performance對象的，所以我們從這個api入手
navigation timing api = navigation + timing + others
navigation我們需要記住的就兩個方法，一個是重定向的次數，另一個是這個界面的來源。
1) redirectCount是重定向次數
2) type是頁面來源類型，有以下幾個類型：
3) 那麼timing 這個對象提供給我們最重要的時間了，我們通過js代碼看一下：
這些時間就是我們需要的性能指標了，所以下一部需要弄懂這些xxoo是什麼意思。
這是截取官方文檔針對navigation timing api的解析圖，對應於timing對象的幾個屬性。
那麼經過第一部分的學習，應該看得懂這幅圖的流程了，timing統計的正是這個流程的各個節點。
unloadEventStart和unloadEventEnd，看名字應該是卸載的意思，指的是當前界面卸載上一個同源文檔的時間(同源策略指的是隻能運行同一域名、協議、端口下的腳本)。
中間的domContentLoadedEventStart和domContentLoadedEventEnd指的是css加載了，需要立即執行的js都執行了的時間。
最後面的loadEventStart和loadEventEnd是onLoad事件的開始結束時間。
嗯，其他的參數應該可以猜到了，就不多解釋啦。
android中測試webview的方法
android測試webview的性能其實非常簡單，因爲chrome插件其實已經給我們提供現成的遠程調試工具了：
安裝了之後在插件處可以看到一個綠色的小機器人，點擊它就可以開啓了
那麼怎麼使用呢
1.在app代碼部分，爲webview設置允許debug調試
webView.setWebContentsDebuggingEnabled(true);這樣就可以允許遠程調試了，當然這個功能只支持4.4以上的系統
2.連接手機，如果adb連接上的話，理論會直接顯示出設備
如果當前在設置的webview界面，那麼會有inspect這個按鈕，點擊就進入了調試模式了，和chrome上點擊f12一樣。
這個工具的使用方法不在這裏的討論範圍了，後續再深入學習。我們重點關注的是console的腳本執行這裏，在前面部分我們已經學習http(s)請求的流程，以及navigaion timing api提供給我們的統計字段，接下來我們就可以計算出我們的webview加載時間了。
這裏列出幾個目前用來統計的參數
1)
太多重定向會拖累頁面訪問速度
2)
這是統計界面獲取到數據，做解析和渲染到webview加載完的時間，這部分和處理器性能有關，和網絡無關，也就是統計了性能
3)
這個完全依賴於網絡了，是屬於正式開始訪問網絡，解析域名，建議握手並獲取數據的過程，這部分的耗時往往還參考webview的請求數量和內容相關，這部分時間在筆者項目裏往往是對比國內和國外服務器的對比測試。
最後
好了，那麼針對webview性能調試的初步就寫到這裏吧，本篇重點是學習了訪問流程和navigation timing api以及android端webview統計耗時的簡單使用，後續隨着學習的深入再總結如何去測試webview性能相關的東西吧！