移動端WebView性能優化

前言

在App的開發過程當中，隨着業務的發展，愈來愈多的公司會選擇內嵌 WebView，可是便利性的同時，WebView 的性能卻有着很大的問題，備受爭議。 做爲移動開發者應該從哪些方面去優化webView就一個很值得研究的話題。

---

從網頁加載提及

咱們從App中打開一個網頁，到網頁所有加載和渲染和顯示完展示出來所須要花費得時間要比native長很多，這中間經歷的階段大體以下：

1. WebView初始化
2. 創建鏈接
3. 接受頁面和樣式
4. 頁面渲染和腳本下載解析
5. 後端處理數據
6. 前端接受數據
7. 渲染數據

在這幾個階段中網頁會經歷從無反饋、白屏、正在加載，對用戶的使用體驗是不好的。

---

優化分析

要對webView進行性能優化 應該針對性的對以上幾個階段所消耗的時間進行優化。

WebView初始化

當在App中第一次打開一個網頁，系統首先作的並非直接創建鏈接，而是啓 動瀏覽器內核。因此第一次webView的初始化要花費大量時間。

優化方法：

• 提早初始化webview
• 客戶端代理數據請求

提早初始化webview能夠分爲：

1. 提早初始化全局webView

當App剛啓動時就初始化全局webView並隱藏，當用戶訪問了webView時，直接使用這個 webView加載對應網頁。缺點是須要額外消耗內存。還有須要webView切換時須要清除頁面痕跡，容易形成內存泄漏。

2. 設置webView的緩衝池。

App啓動後。在webView的緩衝池初始化多個webView。須要加載網頁時能夠去緩衝池中去取出新的webView。不須要時就能夠直接銷燬，同時初始化新的webView放進緩衝池中。缺點是相比而言須要更大的額外內存消耗。可是確保減小webView初始化消耗的時間和下降清除頁面所形成的內存泄漏

3. 客戶端代理數據請求

在初始化的同時，經過 Native 來完成一些網絡請求等過程，而後在回傳給WebView，使得 WebView初始化不是徹底的阻塞後續過程。

---

創建鏈接

在創建鏈接過程當中主要消耗時間：

1. DNS解析服務器地址
2. 鏈接服務器
3. 服務器處理數據

優化方法：

1. 客戶端採用統一的API域名。利用系統對DNS的緩存。減小每次請求的DNS解析時間。
2. 服務器分段輸出網頁數據

---

頁面渲染

一般狀況下，CSS 不會阻塞 HTML 的解析，但若是 CSS 後面有 JS，則會阻 塞 JS 的執行直到 CSS 加載完成(即使 JS 是內聯的腳本)，從而間接阻塞 HTML 的 解析。

優化方法：

1.CSS 的加載會在 HTML 解析到 CSS 的標籤時開始，因此 CSS 的標籤要盡 量靠前。 2.可是，CSS 連接下面不能有任何的 JS 標籤(包括很簡單的內聯 JS)，不然會 阻塞 HTML 的解析。 3.若是必需要在頭部增長內聯腳本，必定要放在 CSS 標籤以前。

---

WebView 性能優化總結

• WebView 初始化慢，能夠在初始化同時先請求數據，讓後端和網絡不要閒着。
• 後端處理慢，可讓服務器分 trunk 輸出，在後端計算的同時前端也加載網絡 靜態資源。
• 腳本執行慢，就讓腳本在最後運行，不阻塞頁面解析。
• 同時，合理的預加載、預緩存可讓加載速度的瓶頸更小。
• WebView 初始化慢，就隨時初始化好一個 WebView 待用。
• DNS 和連接慢，想辦法複用客戶端使用的域名和連接。 腳本執行慢，能夠把框架代碼拆分出來，在請求頁面以前就執行好。