webview加載時有5個事件。觸發順序為loading、titleUpdate、rendering、rendered、loaded。
webview開始載入頁面時觸發loading，
載入過程中如果<title>節點已經解析並賦予新值，觸發titleUpdate，
頁面開始渲染，觸發rendering，
頁面渲染完畢，觸發rendered，
頁面載入完畢觸發loaded。

loaded常用於判斷頁面是否載入完畢，載入完畢才顯示新頁面。
但有時頁面內容很長時，全部載入完畢比較慢，導致顯示新窗體比較慢。為了讓新窗體打開快點，我們可以在titleUpdate時就顯示新窗體。
因為網頁本身有分步渲染的機制，所以一般只要滾動前的第一屏頁面渲染完畢就不會讓用戶看到白屏。
在2014年，手機普遍的渲染能力較慢，所以為避免白屏，官方的框架和示例默認都是loaded時show頁面。但到了2016年，手機的性能有更高的提升，在大多數手機上titleupdate時show新頁面也不會觸發白屏，並且比loaded更快，為了提升切屏速度，官方mui統一調整成了在titleupdate時show新頁面。
如果是從服務器在線載入頁面，或者本地的頁面非常復雜導致渲染很慢，此時titleUpdate時仍然可能白屏，此時需使用rendering或rendered事件可避免白屏。

為什麽rendered和loaded是2個事件呢？
其實在純本地頁面時這2個事件幾乎沒區別。但有時頁面裏會引入一些優先級較低的外部網絡js，比如統計js，一旦網絡響應慢，或者幹脆是無效引用，雖然頁面渲染完了，但loaded會觸發的很慢，直到這些網絡js也加載好或超時才觸發。

有人問plus ready和webview的loaded、以及HTML裏的DOMContentLoaded 這3個事件的順序。
plus ready在HBuilder早期是webview的loaded事件發生時才觸發。
但隨著技術的進步，目前策略已經變化。
在iOS上，plus ready已經名存實亡，只是為了向下兼容，因為在webview最開始，plus就是生效的。目前iOS上plus ready事件的觸發為保持向下兼容也是在webview的loaded時，但該事件觸發之前其實plus已經可以使用了。
在安卓上，plus ready默認也是在webview的loaded時，但可通過如下方法，5+ API提前生效可用：http://ask.dcloud.net.cn/article/921。如果開發者使用了該文的方法配置了提前生效，雖然plus ready的執行時間沒變，但在titleUpdate後就可以使用plus的api了。
註意：plus提前生效後，在plus ready裏操作dom就變的危險了，因為plus ready快於DOMContentLoaded，造成dom還沒有準備好。此時操作dom，還是得在DOMContentLoaded之後。同時plus提前生效會讓頁面本身的js執行時間推後幾十至幾百毫秒，這點使用時要註意。

註意：以上的事件在實際代碼監聽時，需要寫在不同的webview裏。
由於新開的webview裏的plus ready時間晚於該webview的loading、titleUpdate，所以在新webview裏用plus api監聽這2個事件是監聽不到初次打開的。
只能在老的webview裏對新webview的loading和titleUpdate進行監聽。

註意：如果頁面是網絡頁面，並且發生服務器跳轉，有可能觸發多次titleupdate。

註意：在個別國產手機上，如果網頁的title節點內容為空，不會觸發titleupdate事件。

提供一個判斷webview載入時間的方法。

一般webview載入要多久，開發者可以自己使用計時器計時，計算從開始載入到loaded的時間差。
但首頁的載入速度開發者無法編程獲得，5+runtime提供了首頁的webview的載入時間，plus.runtime.launchLoadedTime。
這個time最大的用途是判斷手機性能。
首頁正常是本地頁面，同樣的首頁在不同手機上loadedtime值是不同的，根據這個值，就知道了這臺手機載入網頁的速度到底多快。
這個速度與本地io性能有關，也與計算渲染能力有關。
根據這個值，我們可以做很多優化。
比如在一些高性能手機上，載入新窗體很快，導致出現雪花閃一下又立即消失的情況，此時就沒必要讓雪花出現了，直接切屏就好了。而低性能手機即loadedtime值較低的則老老實實轉雪花。

App的啟動加速技巧

首頁的配置幾乎都是在manifest做，用好manifest才能優化好app的啟動速度。
1.首頁的頂部title，在manifest裏配置laucherwebview的navigationbar，描述title的背景色、文字等樣式，因為是原生繪制，要比webview快不少。
2.如果底部有tab，建議使用雙首頁。雙首頁是一個很有趣的機制，在manifest裏配置，DCloud的引擎會同時打開2個webview，而不是先等一個webview的plus生效後通過js再創建另一個webview。在manifest裏配置secondwebview，由laucherwebview加載tab頁面，secondwebview加載第一個tab的內容頁。
tab那個webview裏面建議加載一個很素的HTML，不引外部css和js，也不依賴js渲染，簡單的js註冊下點擊切換事件，也不要提前讓plus生效。（我們說webview渲染比原生慢很多，其實鍋主要是js背，如果頁面渲染是很簡單的HTML，webview和原生的渲染速度差距會大幅減少。）
3.然後manifest裏配置splash關閉時間為titleUpdate，可以非常早的關閉splash。
在即將發布的HBuilder8.2中，將支持subnview，這個技術可以在屏幕上引入更多原生渲染的內容，讓頁面渲染更快。

在提供些其他影響app啟動的設置：
如果設置了runmode為解壓模式，安裝apk後第一次啟動時需要先把js等資源解壓到sdcard，這裏有個耗時。第二次啟動就好了。

提升HTML5的性能體驗系列之五 webview啟動速度優化及事件順序解析