前言
由于H5具備 開發周期短、靈活性好 的特點，所以現在Android App大多嵌入了Android Webview組件進行Hybrid開發
但我知道你一定在煩惱Android Webview的性能問題，特別突出的是：加載速度慢 & 消耗流量
今天，我將針對Android Webview的性能問題，提出一些有效解決方案。
Android WebView里H5頁面加載速度慢
耗費流量
下面會詳細介紹。
下面會詳細介紹：
前端H5頁面渲染的速度取決于 兩個方面：
Js解析效率
Js本身的解析過程復雜、解析速度不快 & 前端頁面涉及較多JS代碼文件，所以疊加起來會導致Js解析效率非常低
手機硬件設備的性能
由于Android機型碎片化，這導致手機硬件設備的性能不可控，而大多數的Android手機硬件設備無法達到很好很好的硬件性能
總結：上述兩個原因 導致H5頁面的渲染速度慢。
H5頁面從服務器獲得，并存儲在Android手機內存里：
H5頁面一般會比較多
每加載一個H5頁面，都會產生較多網絡請求：
HTML主URL自身的請求；
HTML外部引用的JS、CSS、字體文件，圖片也是一個獨立的HTTP請求
每一個請求都串行的，這么多請求串起來，這導致H5頁面資源加載緩慢
總結：H5頁面加載速度慢的原因：渲染速度慢 & 頁面資源加載緩慢 導致。
每次使用H5頁面時，用戶都需要重新加載Android WebView的H5頁面
每加載一個H5頁面，都會產生較多網絡請求（上面提到）
每一個請求都串行的，這么多請求串起來，這導致消耗的流量也會越多
綜上所述，產生Android WebView性能問題主要原因是：
上述問題導致了Android WebView的H5頁面體驗 與 原生Native存在較大差距。
針對上述androidWebView的性能問題，我提出了兩種解決方案：
使用Android WebView自身的緩存機制
自身構建緩存機制（主要是H5頁面資源的預加載）
下面我將詳細介紹。
定義
緩存，即離線存儲
這意味著H5網頁 加載過之后會存儲在緩存區域，在沒有網絡連接時也可以進行訪問
作用
離線瀏覽：用戶可在沒有網絡連接時進行H5頁面訪問
提高頁面加載速度 & 減少流量消耗：直接使用已緩存的資源，不需要重新加載
具體應用
此處講解主要講解Android WebView的緩存機制 & 緩存模式 ：
a. 緩存機制：如何將加載過的網頁數據保存到本地
b. 緩存模式：加載網頁時如何讀取之前保存到本地的網頁緩存
前者是保存，后者是讀取，請注意區別
Android WebView的本質：在Android 中嵌入H5頁面
所以，Android WebView自帶的緩存機制其實就是H5頁面的緩存機制
Android WebView除了新的File System緩存機制還不支持，其他都支持。
Android WebView自帶的緩存機制有5種：
瀏覽器 緩存機制
Application Cache緩存機制
Dom Storage緩存機制
Web SQL Database緩存機制
Indexed Database緩存機制
File System緩存機制（H5頁面新加入的緩存機制，雖然Android WebView暫時不支持，但會進行簡單介紹）
下面將詳細介紹每種緩存機制。
根據HTTP協議頭里的Cache-Control（或Expires）和Last-Modified（或Etag）等字段來控制文件緩存的機制
下面詳細介紹Cache-Control、Expires、Last-Modified&Etag四個字段
Cache-Control：用于控制文件在本地緩存有效時長
如服務器回包：Cache-Control:max-age=600，則表示文件在本地應該緩存，且有效時長是600秒（從發出請求算起）。在接下來600秒內，如果有請求這個資源，瀏覽器不會發出 HTTP 請求，而是直接使用本地緩存的文件。
Expires：與Cache-Control功能相同，即控制緩存的有效時間
Expires是HTTP1.0標準中的字段，Cache-Control 是HTTP1.1標準中新加的字段
當這兩個字段同時出現時，Cache-Control優先級較高
Last-Modified：標識文件在服務器上的最新更新時間
下次請求時，如果文件緩存過期，瀏覽器通過 If-Modified-Since 字段帶上這個時間，發送給服務器，由服務器比較時間戳來判斷文件是否有修改。如果沒有修改，服務器返回304告訴瀏覽器繼續使用緩存；如果有修改，則返回200，同時返回最新的文件。
Etag：功能同Last-Modified，即標識文件在服務器上的最新更新時間。
不同的是，Etag的取值是一個對文件進行標識的特征字串。
在向服務器查詢文件是否有更新時，瀏覽器通過If-None-Match字段把特征字串發送給服務器，由服務器和文件最新特征字串進行匹配，來判斷文件是否有更新：沒有更新回包304，有更新回包200
Etag和Last-Modified可根據需求使用一個或兩個同時使用。兩個同時使用時，只要滿足基中一個條件，就認為文件沒有更新。
常見用法是：
Cache-Control與Last-Modified一起使用；
Expires與Etag一起使用；
即一個用于控制緩存有效時間，一個用于在緩存失效后，向服務查詢是否有更新
特別注意：瀏覽器緩存機制 是 瀏覽器內核的機制，一般都是標準的實現
即Cache-Control、Last-Modified、Expires、Etag都是標準實現，你不需要操心
優點：支持Http協議層
不足：緩存文件需要首次加載后才會產生；瀏覽器緩存的存儲空間有限，緩存有被清除的可能；緩存的文件沒有校驗。
對于解決以上問題，可以參考手 Q 的離線包
靜態資源文件的存儲，如` JS、CSS`、字體、圖片等。
Android Webview會將緩存的文件記錄及文件內容會存在當前 app 的 data 目錄中。
`Android WebView`內置自動實現，即不需要設置即實現
Android4.4后的WebView瀏覽器版本內核：Chrome
瀏覽器緩存機制 是 瀏覽器內核的機制，一般都是標準的實現
以文件為單位進行緩存，且文件有一定更新機制（類似于瀏覽器緩存機制）
AppCache原理有兩個關鍵點：manifest 屬性和 manifest 文件。? ??
// HTML 在頭中通過 manifest 屬性引用 manifest 文件
// manifest 文件：就是上面以 appcache 結尾的文件，是一個普通文件文件，列出了需要緩存的文件
// 瀏覽器在首次加載 HTML 文件時，會解析 manifest 屬性，并讀取 manifest 文件，獲取 Section：CACHE MANIFEST 下要緩存的文件列表，再對文件緩存...// 原理說明如下：
// AppCache 在首次加載生成后，也有更新機制。被緩存的文件如果要更新，需要更新 manifest 文件
// 因為瀏覽器在下次加載時，除了會默認使用緩存外，還會在后臺檢查 manifest 文件有沒有修改（byte by byte)
發現有修改，就會重新獲取 manifest 文件，對 Section：CACHE MANIFEST 下文件列表檢查更新
// manifest 文件與緩存文件的檢查更新也遵守瀏覽器緩存機制
// 如用戶手動清了 AppCache 緩存，下次加載時，瀏覽器會重新生成緩存，也可算是一種緩存的更新
// AppCache 的緩存文件，與瀏覽器的緩存文件分開存儲的，因為 AppCache 在本地有 5MB（分 HOST）的空間限制
