一、簡介
一提到App內的WebView加載網頁，大家的第一印象就是：慢、耗流量、體驗比原生差。但WebView加載網頁也有其天生的優勢：動態，跨平臺，開發周期短。
那能如何解決WebView加載網頁慢和體驗差的問題呢？可以思考下面兩個問題：
- 從打開瀏覽器到網頁完全展示都發生了什么？
- 如何給WebView加載網頁提速？
二、整體思維導圖
三、衡量標準
快慢是一個相對量，如何衡量WebView的快慢呢？
3.1 用戶體驗的時間尺度
從用戶角度來看，如下圖是2018年份百度移動端的統計數據：
根據上面的統計折線圖，得出如下表格：
可以發現：
- 小于1s，用戶更容易接受，關閉率更低。
- 用戶對移動端的容忍比PC端更低，要求更高。
3.2 加載時長標準
加載時長 = 加載結束 - 加載開始
加載開始很好界定，當用戶點擊feed流里面的item開始，就開始計時。
加載結束呢？WebView有個WebViewClient#onPageFinished回調方法，這個方法是在頁面完全加載結束時候回調的，但是頁面DOM渲染完頁面就已經有內容，對于用戶來說算是頁面已經展示出來了。統計加載時長以DOM渲染完更好些。
3.3 統計標準
通過收集真正的用戶使用數據，才能更好的根據用戶的情況進行優化。那如何才能反應用戶的真實情況呢？
通常有兩種方式：
- 平均數，容易被較長的加載時間給拉高，不容易反應真實情況。
- 中位數，能很好的反應大多數用戶的情況，但是中位數的要求較低，可以將其提高到80分位，或者90分位。
在們項目進行數據統計時候可以先采用80分位，檢測下優化效果，后續再提高要求，使用更高分位如95分位等。
根據現網數據可知，當95分位的用戶頁面加載時長為1s以內時，80分位的用戶頁面加載時長為0.35s以內時，APP內網頁的體驗最佳。
具體最佳時間可以根據真實的上報數據的統計結果進行調整。
四、問題分析
前端頁展示一般分兩種：
- 前后端分離，前端加載資源后，通過js請求展示的數據并在前端渲染展示。
- 頁面直出，頁面數據由服務器填充完成后，直接下發到前端，由前端直接展示。
現在較多的采用前后端分離的方式，下面都以這種方式為例講解。
4.1 WebView渲染過程
WebView渲染大致需要如下幾步：
- 解析 HTML 文件
- 加載 JavaScript 和 CSS 文件
- 解析并執行 JavaScript
- 構建 DOM 結構
- 加載圖片等資源
- 頁面加載完畢
4.2 WebView耗時統計方法
統計可從兩方面入手，一是網頁層統計，二是App層統計。
4.2.1 網頁層統計：WebView中網頁耗時統計方法
WebView加載url到完全展示出各個部分耗時情況，可以根據w3c標準中網頁performance參數獲取具體耗時統計參數信息，詳細的頁面加載過程見下圖：
根據performance統計情況可以得出如下數據：
- 重定向耗時：redirectEnd - redirectStart
- DNS查詢耗時 ：domainLookupEnd - domainLookupStart
- TCP鏈接耗時 ：connectEnd - connectStart
- HTTP請求耗時 ：responseEnd - responseStart
- 解析dom樹耗時 ： domComplete - domInteractive
- 白屏時間 ：responseStart - navigationStart
- DOMready時間 ：domContentLoadedEventEnd - navigationStart
- onload時間：loadEventEnd - navigationStart，也即是onload回調函數執行的時間。
4.2.2 App層統計：App層統計WebView耗時
Android可以通過WebViewClient#onPageFinished回調統計頁面整個加載時長，開始時間以WebView創建開始算，嚴格一點可以從feed流中點擊item開始算。這個統計只能算整個加載時長，加載到用戶可見的時長以DOM渲染完頁面為準，后者比前置時長更短一些。前置供參考，以后者為準。
根據上圖可以獲取的統計數據：
- WebView創建耗時：navigationStart - createWebView（以初始化開始時間為準，下同）
- 交互開始到頁面可見耗時：onClickItem - createWebView
- 頁面加載到可見耗時：domContentLoadedEventEnd - createWebView
- 頁面完全加載耗時：onPageFinished - createWebView
4.3 資訊統計數據
測試資訊連接1：測試文章1
測試資訊連接2：測試文章2
五、優化方案
從統計數據看，WebView首次加載耗時較多2s左右，二次加載耗時也有0.5s左右。
5.1 離線化
同我們現有的離線包一樣，將頁面用的公共資源html,css,js等模板化，將模板打成壓縮包形成離線包內置或動態下發到App端，在App中訪問訪問到具體的頁面時候優先加載本地的模板資源。
通過WebViewClient#shouldInterceptRequest方法攔截WebView的資源加載，匹配到本地模板中的資源就直接加載本地資源，沒有匹配本地模板資源再去加載線上資源。genWebResourceResponse用于實現具體的匹配策略。
override fun shouldInterceptRequest(view: WebView?, request: WebResourceRequest?): WebResourceResponse? {
return genWebResourceResponse(request, view)
}
模板注意事項：
- 精簡模板，移除不必要的js、css，進行異步拉取
- 模板內聯js、css，減少io
- js盡量放到最后，避免阻礙DOM解析
5.2 數據與模板加載
5.2.1 并行執行：數據請求與模板加并行
雖然進行了本地化網頁模板化，但整體的頁面加載依然是串行執行的。為了進一步提高頁面的加載速度，可以讓數據請求由app端代理。使數據加載與模板加載并行執行，待數據加載完成時通過JsBridge回填到網頁中。效果如下圖：
5.2.2 數據預加載
既然數據請求已經由app代理了，當然也可以通過一定的策略預加載數據，當頁面打開時候直接使用緩存數據。這樣整個網頁加載過程完全離線化不受網絡影響。
5.3 WebView預創建
由上面統計數據可知，WebView創建與二次創建耗時相差甚遠，如下圖總結：
原因是Webview所有的邏輯處理都是通過WebViewProvider來實現的，它需要加載Webview內核，這是一個重量級的操作，內核是以apk的形式存在。而內核加載后在同一頁面是共享的，因此后續的初始化時間就很少了。
可以通過預創建WebView來加速這一過程，預創建會消耗一定量的內存，如何平衡預創建和內存消耗問題還需實踐把握衡量，具體方式：
WebView池（或統一全局WebView）：在app啟動時候后臺創建WebView池，當app需要展示網頁的時候直接拿已創建的WebView，需要在頁面銷毀時候清除頁面數據。池結構如下：
預創建WebView注意事項：
- WebView初始化需要傳context，需要注意內存泄漏。
- WebView創建需要較大內存，需要注意內存耗費。
- WebView復用需要清除數據，需要注意狀態維護。
5.4 模板預熱
經過前面幾步處理后，網頁加載過程可以實現全部本地化后，但每次打開網頁的時候還需要重復加載模板數據。DOM解析耗時，如下圖：
為了避免重復加載模板，則需要在WebView池的基礎上，讓池中的WebView預先加載本地模板。當需要展示網頁時候直接拿到已經加載過本地模板的WebView，并通過JsBridge注入數據。池中結構如下：
網頁加載的整個過程如下：
5.5 圖片加載
WebView在加載大量圖片時候表現不佳，重復進入時還會重復加載圖片，體驗不好且浪費瀏覽。
5.5.1 App代理圖片加載
該方式需要借助圖片加載庫如Glide，在WebViewClient#shouldInterceptRequest方法攔截WebView的資源加載，判斷要加載的資源url是否為圖片，是就走Glide加載并生成加載圖片的WebResourceResponse，通過Glide來達到緩存圖片目的，避免多次打開頁面重復加載線上圖片資源，genWebResourceResponse用于實現具體的匹配策略。這種方式有點是不需要前端配合，客戶端完全自己處理即可。
在api>=21時，可以通過WebResourceRequest獲取請求中的accept字段獲取返回值類型，用于區分url類型。
override fun shouldInterceptRequest(
view: WebView?,
request: WebResourceRequest?
): WebResourceResponse? {
val url = request.url.toString()
if (checkImageRequest(request)) {
val imageFile = Glide.with(view.context)
.asFile()
.load(url)
.submit()
.get()
return WebResourceResponse(
"image/png,*/*",
"UTF-8",
FileInputStream(imageFile)
)
}
return super.shouldInterceptRequest(view, url)
}
在api<21時，只能通過url來判斷來判斷類型。
override fun shouldInterceptRequest(view: WebView?, url: String?): WebResourceResponse? { // 處理資源匹配
return genWebResourceResponse(url, view)
}
注：示例代碼僅展示用，細節需要自己處理
5.5.2 hybrid
使用網頁和原生控件的混合開發模式，網頁中文字部分讓WebView渲染，網頁中的圖片視頻等使用原生控件展示。優點即可以避免重復加載圖，又能提升圖片瀏覽體驗；缺點實現成本高，需要前后端協調處理。今日頭條8.0.3版本同樣采用了這種方式加載展示圖片。
具體思路：
- 圖片展示容器與WebView上下疊放，大小一致
- WebView中預留圖片占位div
- 獲取網頁中圖片的url、大小以及位置信息
- 通過js或其他方式通知App
- App加載圖片并根據WebView中占位div位置設置原生圖片位置
- 原生控件與WebView同步滾動
六、總結
Android中WebView還存在較大的優化空間，可以進一步提升資訊、活動頁等h5頁面的瀏覽體驗。本文涉及的優化方式僅是方向性的，為后續Android App的WebView優化提供方向性指引，實際操作會涉及到多端配合，細節較多，需要不斷迭代優化。
參考文章：
Does Page Load Time Really Affect Bounce Rate?
