Android：手把手教你構建 WebView 的緩存機制 & 資源預加載方案

時間 2019-12-04

標籤 android 手把手構建 webview 緩存機制資源加載方案欄目 Android 简体版

原文原文鏈接

前言

因爲H5具有開發週期短、靈活性好的特色，因此如今 Android App大多嵌入了 Android Webview 組件進行 Hybrid 開發
但我知道你必定在煩惱 Android Webview 的性能問題，特別突出的是：加載速度慢 & 消耗流量
今天，我將針對 Android Webview 的性能問題，提出一些有效解決方案。

1. Android WebView 存在什麼性能問題？

Android WebView 裏 H5 頁面加載速度慢
耗費流量

下面會詳細介紹。前端

1.1 H5 頁面加載速度慢

H5 頁面加載速度慢的緣由java

下面會詳細介紹：android

1.1.1 渲染速度慢git

前端H5頁面渲染的速度取決於兩個方面：github

Js 解析效率
Js 自己的解析過程複雜、解析速度不快 & 前端頁面涉及較多 JS 代碼文件，因此疊加起來會致使 Js 解析效率很是低
手機硬件設備的性能
因爲Android機型碎片化，這致使手機硬件設備的性能不可控，而大多數的Android手機硬件設備沒法達到很好很好的硬件性能

總結：上述兩個緣由致使 H5頁面的渲染速度慢。web

1.1.2 頁面資源加載緩慢數據庫

H5 頁面從服務器得到，並存儲在 Android手機內存裏：瀏覽器

H5頁面通常會比較多
每加載一個 H5頁面，都會產生較多網絡請求：
1. HTML 主 URL 自身的請求；
2. HTML外部引用的JS、CSS、字體文件，圖片也是一個獨立的 HTTP 請求

每個請求都串行的，這麼多請求串起來，這致使 H5頁面資源加載緩慢緩存

**總結：H5頁面加載速度慢的緣由：渲染速度慢 & 頁面資源加載緩慢致使 **。

1.2 耗費流量

每次使用 H5頁面時，用戶都須要從新加載 Android WebView的H5 頁面
每加載一個 H5頁面，都會產生較多網絡請求（上面提到）
每個請求都串行的，這麼多請求串起來，這致使消耗的流量也會越多

總結

綜上所述，產生Android WebView性能問題主要緣由是：

緣由

上述問題致使了Android WebView的H5 頁面體驗與原生Native 存在較大差距。

2. 解決方案

針對上述Android WebView的性能問題，我提出了兩種解決方案：

使用Android WebView 自身的緩存機制
自身構建緩存機制（主要是H5頁面資源的預加載）

下面我將詳細介紹。

2.1 `Android WebView` 自身的緩存機制

定義
緩存，即離線存儲

這意味着 H5網頁加載過以後會存儲在緩存區域，在沒有網絡鏈接時也能夠進行訪問

做用
1. 離線瀏覽：用戶可在沒有網絡鏈接時進行H5頁面訪問
2. 提升頁面加載速度 & 減小流量消耗：直接使用已緩存的資源，不須要從新加載
具體應用
此處講解主要講解 Android WebView 的緩存機制 & 緩存模式：
a. 緩存機制：如何將加載過的網頁數據保存到本地
b. 緩存模式：加載網頁時如何讀取以前保存到本地的網頁緩存

前者是保存，後者是讀取，請注意區別

2.1.1 緩存機制

Android WebView的本質：在Android 中嵌入 H5頁面
因此，Android WebView自帶的緩存機制其實就是 H5頁面的緩存機制

Android WebView除了新的File System緩存機制還不支持，其餘都支持。

Android WebView自帶的緩存機制有5種：
1. 瀏覽器緩存機制
2. Application Cache 緩存機制
3. Dom Storage 緩存機制
4. Web SQL Database 緩存機制
5. Indexed Database 緩存機制
6. File System 緩存機制（H5頁面新加入的緩存機制，雖然Android WebView暫時不支持，但會進行簡單介紹）

下面將詳細介紹每種緩存機制。

1. 瀏覽器緩存機制

a. 原理

根據 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都是標準實現，你不須要操心

b. 特色

優勢：支持 Http協議層
不足：緩存文件須要首次加載後纔會產生；瀏覽器緩存的存儲空間有限，緩存有被清除的可能；緩存的文件沒有校驗。

對於解決以上問題，能夠參考手 Q 的離線包

c. 應用場景

靜態資源文件的存儲，如JS、CSS、字體、圖片等。

Android Webview會將緩存的文件記錄及文件內容會存在當前 app 的 data 目錄中。

d. 具體實現

Android WebView內置自動實現，即不須要設置即實現

Android 4.4後的 WebView 瀏覽器版本內核：Chrome

瀏覽器緩存機制是瀏覽器內核的機制，通常都是標準的實現

2. Application Cache 緩存機制

a. 原理

以文件爲單位進行緩存，且文件有必定更新機制（相似於瀏覽器緩存機制）
AppCache 原理有兩個關鍵點：manifest 屬性和 manifest 文件。

<!DOCTYPE html>
<html manifest="demo_html.appcache">
// HTML 在頭中經過 manifest 屬性引用 manifest 文件
// manifest 文件：就是上面以 appcache 結尾的文件，是一個普通文件文件，列出了須要緩存的文件
// 瀏覽器在首次加載 HTML 文件時，會解析 manifest 屬性，並讀取 manifest 文件，獲取 Section：CACHE MANIFEST 下要緩存的文件列表，再對文件緩存
<body>
...
</body>
</html>

// 原理說明以下：
// AppCache 在首次加載生成後，也有更新機制。被緩存的文件若是要更新，須要更新 manifest 文件
// 由於瀏覽器在下次加載時，除了會默認使用緩存外，還會在後臺檢查 manifest 文件有沒有修改（byte by byte)
發現有修改，就會從新獲取 manifest 文件，對 Section：CACHE MANIFEST 下文件列表檢查更新
// manifest 文件與緩存文件的檢查更新也遵照瀏覽器緩存機制
// 如用戶手動清了 AppCache 緩存，下次加載時，瀏覽器會從新生成緩存，也可算是一種緩存的更新
// AppCache 的緩存文件，與瀏覽器的緩存文件分開存儲的，由於 AppCache 在本地有 5MB（分 HOST）的空間限制

b. 特色

方便構建Web App的緩存

專門爲 Web App離線使用而開發的緩存機制

c. 應用場景

存儲靜態文件（如JS、CSS、字體文件）

應用場景同瀏覽器緩存機制

但AppCache 是對瀏覽器緩存機制的補充，不是替代。

d. 具體實現

// 經過設置WebView的settings來實現
        WebSettings settings = getSettings();

        String cacheDirPath = context.getFilesDir().getAbsolutePath()+"cache/";
        settings.setAppCachePath(cacheDirPath);
        // 1. 設置緩存路徑

         settings.setAppCacheMaxSize(20*1024*1024);
        // 2. 設置緩存大小

        settings.setAppCacheEnabled(true);
        // 3. 開啓Application Cache存儲機制
    
// 特別注意
// 每一個 Application 只調用一次 WebSettings.setAppCachePath() 和
 WebSettings.setAppCacheMaxSize()

3. Dom Storage 緩存機制

a. 原理

經過存儲字符串的 Key - Value 對來提供

DOM Storage 分爲 sessionStorage & localStorage；兩者使用方法基本相同，區別在於做用範圍不一樣：
a. sessionStorage：具有臨時性，即存儲與頁面相關的數據，它在頁面關閉後沒法使用
b. localStorage：具有持久性，即保存的數據在頁面關閉後也可使用。

b. 特色

存儲空間大（ 5MB）：存儲空間對於不一樣瀏覽器不一樣，如Cookies 才 4KB
存儲安全、便捷： Dom Storage 存儲的數據在本地，不須要常常和服務器進行交互

不像 Cookies每次請求一次頁面，都會向服務器發送網絡請求

c. 應用場景

存儲臨時、簡單的數據

代替 **將不須要讓服務器知道的信息存儲到 cookies **的這種傳統方法

Dom Storage 機制相似於 Android 的 SharedPreference機制

d. 具體實現

// 經過設置 `WebView`的`Settings`類實現
        WebSettings settings = getSettings();

        settings.setDomStorageEnabled(true);
        // 開啓DOM storage

4. Web SQL Database 緩存機制

a. 原理

基於 SQL 的數據庫存儲機制

b. 特色

充分利用數據庫的優點，可方便對數據進行增長、刪除、修改、查詢

c. 應用場景

存儲適合數據庫的結構化數據

d. 具體實現

// 經過設置WebView的settings實現
        WebSettings settings = getSettings();

        String cacheDirPath = context.getFilesDir().getAbsolutePath()+"cache/";
        settings.setDatabasePath(cacheDirPath);
        // 設置緩存路徑

        settings.setDatabaseEnabled(true);
        // 開啓 數據庫存儲機制

特別說明

根據官方說明，Web SQL Database存儲機制再也不推薦使用（再也不維護）
取而代之的是 IndexedDB緩存機制，下面會詳細介紹

5. IndexedDB 緩存機制

a. 原理

屬於 NoSQL 數據庫，經過存儲字符串的 Key - Value 對來提供

相似於 Dom Storage 存儲機制 的key-value存儲方式

b. 特色

優勢

c. 應用場景

存儲複雜、數據量大的結構化數據

d. 具體實現：

// 經過設置WebView的settings實現
        WebSettings settings = getSettings();

        settings.setJavaScriptEnabled(true);
        // 只需設置支持JS就自動打開IndexedDB存儲機制
        // Android 在4.4開始加入對 IndexedDB 的支持，只需打開容許 JS 執行的開關就行了。

6 . File System

a. 原理

爲 H5頁面的數據提供一個虛擬的文件系統

可進行文件（夾）的建立、讀、寫、刪除、遍歷等操做，就像 Native App 訪問本地文件系統同樣

虛擬的文件系統是運行在沙盒中

不一樣 WebApp 的虛擬文件系統是互相隔離的，虛擬文件系統與本地文件系統也是互相隔離的。

虛擬文件系統提供了兩種類型的存儲空間：臨時 & 持久性：
1. 臨時的存儲空間：由瀏覽器自動分配，但可能被瀏覽器回收
2. 持久性的存儲空間：須要顯式申請；本身管理（瀏覽器不會回收，也不會清除內容）；存儲空間大小經過配額管理，首次申請時會一個初始的配額，配額用完須要再次申請。

b. 特色

可存儲數據體積較大的二進制數據
可預加載資源文件
可直接編輯文件

c. 應用場景

經過文件系統管理數據

d. 具體使用

因爲 File System是 H5 新加入的緩存機制，因此Android WebView暫時不支持

緩存機制彙總

使用建議

綜合上述緩存機制的分析，咱們能夠根據需求場景的不一樣（緩存不一樣類型的數據場景）從而選擇不一樣的緩存機制（組合使用）
如下是緩存機制的使用建議：

使用建議

小技巧

在使用了上述說的Android WebView的緩存機制後，短期內再次訪問同一個H5頁面時，加載速度會比第一次的時間短、更加流暢
基於 Android WebView自身的這些緩存機制，有一種小技巧能更好地去減小H5頁面的加載速度 & 提升性能：在應用啓動時就初始化一個 WebView ，事先加載經常使用H5頁面資源（加載後就有緩存了），後續須要打開這些H5頁面時就直接從本地獲取。

這種技巧實際上是採用了 資源預加載 的思想：提前加載未來須要使用的H5頁面（有緩存了），使用時直接取過來用，而不用在須要時纔去加載

具體實現：在Android 的BaseApplication就初始化一個WebView對象用於加載經常使用的H5頁面資源；當須要使用這些頁面時再從BaseApplication裏取過來直接使用

對於Android WebView的首頁建議使用這種方案，能有效提升首頁加載的效率

固然這裏的BaseApplication只是舉個例子，你也能夠選擇在其餘地方提早加載。

2.1.2 緩存模式

定義
緩存模式是一種當加載 H5網頁時該如何讀取以前保存到本地緩存
從而進行使用的方式

即告訴Android WebView 何時去讀緩存，以哪一種方式去讀緩存

Android WebView 自帶的緩存模式有4種：

// 緩存模式說明: 
      // LOAD_CACHE_ONLY: 不使用網絡，只讀取本地緩存數據
      // LOAD_NO_CACHE: 不使用緩存，只從網絡獲取數據.
      // LOAD_DEFAULT: （默認）根據cache-control決定是否從網絡上取數據。
      // LOAD_CACHE_ELSE_NETWORK，只要本地有，不管是否過時，或者no-cache，都使用緩存中的數據。

具體使用

WebView.getSettings().setCacheMode(WebSettings.LOAD_CACHE_ELSE_NETWORK);
// 設置參數便可

2.2. 自身構建緩存

爲了有效解決 Android WebView 的性能問題，除了使用 Android WebView 自身的緩存機制，還能夠本身針對某一需求場景構建緩存機制。

2.2.1 需求場景

背景：H5頁面有一些更新頻率低、經常使用 & 固定的靜態資源文件（如JS、CSS文件、圖片等）

如一些圖片，JS、CSS文件等

需求場景：每次從新加載會浪費不少資源（時間 & 流量）

2.2.2 解決方案（原理）

經過攔截H5頁面的資源網絡請求從而直接從本地讀取資源而不須要發送網絡請求到服務器讀取。

2.2.3 具體步驟

事先將更新頻率較低、經常使用 & 固定的H5靜態資源文件（如JS、CSS文件、圖片等）放到本地
攔截H5頁面的資源網絡請求並進行檢測
若是檢測到本地具備相同的靜態資源就直接從本地讀取進行替換而不發送該資源的網絡請求到服務器獲取

原理

2.2.4 具體實現

重寫WebViewClient 的 shouldInterceptRequest 方法，當向服務器訪問這些靜態資源時進行攔截，檢測到是相同的資源則用本地資源代替

// 假設如今須要攔截一個圖片的資源並用本地資源進行替代

        mWebview.setWebViewClient(new WebViewClient() {
            // 重寫 WebViewClient  的  shouldInterceptRequest （）
            // API 21 如下用shouldInterceptRequest(WebView view, String url)
            // API 21 以上用shouldInterceptRequest(WebView view, WebResourceRequest request)
            // 下面會詳細說明

             // API 21 如下用shouldInterceptRequest(WebView view, String url)
            @Override
            public WebResourceResponse shouldInterceptRequest(WebView view, String url) {

                // 步驟1:判斷攔截資源的條件，即判斷url裏的圖片資源的文件名
                if (url.contains("logo.gif")) {
                // 假設網頁裏該圖片資源的地址爲：http://abc.com/imgage/logo.gif
                // 圖片的資源文件名爲:logo.gif

                    InputStream is = null;
                    // 步驟2:建立一個輸入流

                    try {
                        is =getApplicationContext().getAssets().open("images/abc.png");
                        // 步驟3:得到須要替換的資源(存放在assets文件夾裏)
                        // a. 先在app/src/main下建立一個assets文件夾
                        // b. 在assets文件夾裏再建立一個images文件夾
                        // c. 在images文件夾放上須要替換的資源（此處替換的是abc.png圖片）

                    } catch (IOException e) {
                        e.printStackTrace();
                    }

                    // 步驟4:替換資源
                    WebResourceResponse response = new WebResourceResponse("image/png",
                            "utf-8", is);
                    // 參數1：http請求裏該圖片的Content-Type,此處圖片爲image/png
                    // 參數2：編碼類型
                    // 參數3：存放着替換資源的輸入流（上面建立的那個）
                    return response;
                }

                return super.shouldInterceptRequest(view, url);
            }

            
           // API 21 以上用shouldInterceptRequest(WebView view, WebResourceRequest request)
            @TargetApi(Build.VERSION_CODES.LOLLIPOP)
            @Override
            public WebResourceResponse shouldInterceptRequest(WebView view, WebResourceRequest request) {

               // 步驟1:判斷攔截資源的條件，即判斷url裏的圖片資源的文件名
                if (request.getUrl().toString().contains("logo.gif")) {
                // 假設網頁裏該圖片資源的地址爲：http://abc.com/imgage/logo.gif
                // 圖片的資源文件名爲:logo.gif

                    InputStream is = null;
                    // 步驟2:建立一個輸入流

                    try {
                        is = getApplicationContext().getAssets().open("images/abc.png");
                         // 步驟3:得到須要替換的資源(存放在assets文件夾裏)
                        // a. 先在app/src/main下建立一個assets文件夾
                        // b. 在assets文件夾裏再建立一個images文件夾
                        // c. 在images文件夾放上須要替換的資源（此處替換的是abc.png圖片

                    } catch (IOException e) {
                        e.printStackTrace();
                    }

                    // 步驟4:替換資源
                    WebResourceResponse response = new WebResourceResponse("image/png",
                            "utf-8", is);
                    // 參數1：http請求裏該圖片的Content-Type,此處圖片爲image/png
                    // 參數2：編碼類型
                    // 參數3：存放着替換資源的輸入流（上面建立的那個）
                    return response;
                }
                return super.shouldInterceptRequest(view, request);
            }

    });

}

2.2.5 具體實例

下面我將經過替換主頁面（http:// ip.cn/）中的一個圖片（http:// s.ip-cdn.com/img/logo.gif）來對靜態資源攔截進行說明。

爲了更好的表現效果，我將替換的圖片換成別的圖片

實例說明1

實例說明2

具體步驟 & 代碼以下

步驟1：定義WebView佈局
activity_main.xml

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:paddingBottom="@dimen/activity_vertical_margin"
    android:paddingLeft="@dimen/activity_horizontal_margin"
    android:paddingRight="@dimen/activity_horizontal_margin"
    android:paddingTop="@dimen/activity_vertical_margin"
    tools:context="scut.carson_ho.webview_interceptrequest.MainActivity">

    <WebView
        android:id="@+id/webview"
        android:layout_width="match_parent"
        android:layout_height="match_parent" />
</RelativeLayout>

步驟2：進行資源的攔截、檢測 & 替換（詳細請看註釋）
MainActivity.java

public class MainActivity extends AppCompatActivity {
    
    WebView mWebview;
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        
        mWebview = (WebView) findViewById(R.id.webview);
        // 建立WebView對象

        mWebview.getSettings().setJavaScriptEnabled(true);
        // 支持與JS交互

        mWebview.loadUrl("http://ip.cn/");
        // 加載須要顯示的網頁

        mWebview.setWebViewClient(new WebViewClient() {

             // 複寫shouldInterceptRequest
             //API21如下用shouldInterceptRequest(WebView view, String url)
            @Override
            public WebResourceResponse shouldInterceptRequest(WebView view, String url) {

                // 步驟1:判斷攔截資源的條件，即判斷url裏的圖片資源的文件名
                // 此處網頁裏圖片的url爲:http://s.ip-cdn.com/img/logo.gif
                // 圖片的資源文件名爲:logo.gif

                if (url.contains("logo.gif")) {

                    InputStream is = null;
                    // 步驟2:建立一個輸入流


                    try {
                        is =getApplicationContext().getAssets().open("images/error.png");
                        // 步驟3:打開須要替換的資源(存放在assets文件夾裏)
                        // 在app/src/main下建立一個assets文件夾
                        // assets文件夾裏再建立一個images文件夾,放一個error.png的圖片

                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                    // 步驟4:替換資源

                    WebResourceResponse response = new WebResourceResponse("image/png",
                            "utf-8", is);
                    // 參數1:http請求裏該圖片的Content-Type,此處圖片爲image/png
                    // 參數2:編碼類型
                    // 參數3:替換資源的輸入流

                    System.out.println("舊API");
                    return response;
                }

                return super.shouldInterceptRequest(view, url);
            }


            // API21以上用shouldInterceptRequest(WebView view, WebResourceRequest request)
            @TargetApi(Build.VERSION_CODES.LOLLIPOP)
            @Override
            public WebResourceResponse shouldInterceptRequest(WebView view, WebResourceRequest request) {

                // 步驟1:判斷攔截資源的條件，即判斷url裏的圖片資源的文件名
                // 此處圖片的url爲:http://s.ip-cdn.com/img/logo.gif
                // 圖片的資源文件名爲:logo.gif
                if (request.getUrl().toString().contains("logo.gif")) {

                    InputStream is = null;
                    // 步驟2:建立一個輸入流

                    try {
                        is = getApplicationContext().getAssets().open("images/error.png");
                        // 步驟3:打開須要替換的資源(存放在assets文件夾裏)
                        // 在app/src/main下建立一個assets文件夾
                        // assets文件夾裏再建立一個images文件夾,放一個error.png的圖片

                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                    //步驟4:替換資源
                   
                    WebResourceResponse response = new WebResourceResponse("image/png",
                            "utf-8", is);
                    // 參數1：http請求裏該圖片的Content-Type,此處圖片爲image/png
                    // 參數2：編碼類型
                    // 參數3：存放着替換資源的輸入流（上面建立的那個）
                    
                    return response;
                }
                return super.shouldInterceptRequest(view, request);
            }

    });

}
}

步驟3：加入網絡權限
Manifest.xml

<uses-permission android:name="android.permission.INTERNET"/>

Demo地址

Carson_Ho的Github地址：https://github.com/Carson-Ho/WebView_InterceptRequest

特別注意

關於上述放到本地的靜態資源也是能夠更新的：

發佈新版本安裝更新
增量更新：在用戶處於WIFI環境時讓服務器推送到本地

不少著名的App（如微信）就是採用小範圍更新本地資源的

這種緩存機制的好處

有效解決 H5頁面靜態資源加載速度慢 & 流量消耗多的問題
開發成本低
1. 沒有改變前端H5的任何代碼，不須要爲 APP 作定製化的東西
2. 該方法只是更好地加快H5加載速度，哪怕失效，也不會對H5頁面產生其餘負面影響
一樣能得到相應的cookie
發送的網絡請求會直接帶上先前用戶操做所留下的 cookie 而都可以留下來，由於咱們沒有更改資源的 URL 地址