Android：手把手教你構建 WebView 的快取機制 & 資源預載入方案

Carson_Ho發表於2017-06-06

AndroidWebView快取

前言

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

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

Android WebView 裡 H5 頁面載入速度慢
耗費流量

下面會詳細介紹。

1.1 H5 頁面載入速度慢

下面會詳細介紹：

1.1.1 渲染速度慢

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

Js 解析效率 Js 本身的解析過程複雜、解析速度不快 & 前端頁面涉及較多 JS 程式碼檔案，所以疊加起來會導致 Js 解析效率非常低
手機硬體裝置的效能由於Android機型碎片化，這導致手機硬體裝置的效能不可控，而大多數的Android手機硬體裝置無法達到很好很好的硬體效能

總結：上述兩個原因導致 H5頁面的渲染速度慢。

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：**定義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地址：github.com/Carson-Ho/W…

特別注意

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

釋出新版本安裝更新
增量更新：在使用者處於WIFI環境時讓伺服器推送到本地

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

這種快取機制的好處

有效解決 H5頁面靜態資源載入速度慢 & 流量消耗多的問題
開發成本低
1. 沒有改變前端H5的任何程式碼，不需要為 APP 做定製化的東西
2. 該方法只是更好地加快H5載入速度，哪怕失效，也不會對H5頁面產生其他負面影響
同樣能獲得相應的cookie 傳送的網路請求會直接帶上先前使用者操作所留下的 cookie 而都能夠留下來，因為我們沒有更改資源的 URL 地址

3. 總結

本文主要對Android WebView 的效能問題 & 解決方案進行了全面介紹
我相信你還會需要下面關於Adroid WebView 的文章 Android開發：最全面、最易懂的Webview詳解最全面總結 Android WebView與 JS 的互動方式你不知道的 Android WebView 使用漏洞
接下來我會繼續講解其他安卓開發的知識，有興趣可以繼續關注Carson_Ho的安卓開發筆記！！！！

請點“喜歡”！因為你們的贊同/鼓勵是我寫作的最大動力！

歡迎關注carson_ho的微信公眾號

Android webview的快取機制
2017-09-25
AndroidWebView快取
從WebView快取聊到Http 的快取機制
2017-05-09
WebView快取HTTP
Android 資源載入機制剖析
2018-03-27
Android
從WebView快取聊到Http 的快取機制 | 掘金技術徵文
2019-03-03
WebView快取HTTP
Android 視訊縮圖的快取機制和非同步載入
2015-07-27
Android快取非同步
預載入與快取
2018-06-06
快取
WebView深度學習（三）之WebView的記憶體洩漏、漏洞以及快取機制原理和解決方案
2018-01-10
WebView深度學習記憶體快取
【構建Android快取模組】（三）Controller & 非同步圖片載入
2013-11-27
Android快取Controller非同步
開源框架——圖片載入和快取方案總結
2019-03-28
框架快取
深入理解Android中的快取機制(三)磁碟快取
2018-02-03
Android快取
App資料分析小心預載入機制
2021-07-23
APP
深入理解Android中的快取機制(二)RecyclerView跟ListView快取機制對比
2018-02-03
Android快取View
webView快取
2016-12-30
WebView快取
再次探究Android ListView快取機制
2015-01-22
AndroidView快取
Android中清楚Cookie和WebView的快取
2015-03-12
AndroidCookieWebView快取
Android WebView：這是一份詳細 & 易懂的WebView學習攻略（含與JS互動、快取構建等）
2019-03-03
AndroidWebViewJS快取
深入理解Android中的快取機制(一)快取簡介
2018-02-03
Android快取
Android原始碼分析：手把手帶你深入瞭解Glide的快取機制
2018-03-27
Android原始碼IDE快取
mybatis的快取機制
2023-04-02
MyBatis快取
mysql的快取機制
2013-03-08
MySql快取
MyBatis 的快取機制
2024-06-16
MyBatis快取
基於webpack4[.3+]構建可預測的持久化快取方案
2018-09-11
Web持久化快取
手把手教你如何構建一個優秀的開源專案
2017-07-13
Web 快取機制與快取策略
2018-11-20
Web快取
HTTP快取機制
2019-02-16
HTTP快取
Mybatis快取機制
2022-12-01
MyBatis快取
LRU快取機制
2020-10-13
快取
前端快取機制
2018-05-30
前端快取
web快取機制
2018-04-09
Web快取
client快取機制
2016-04-21
client快取
Android WebView載入TTF字型
2016-09-01
AndroidWebView
手把手教你做一個快取工具
2020-07-04
快取
node中的快取機制
2019-03-04
快取
Android快取機制-LRU cache原理與用法
2018-09-12
Android快取
Web快取知多少(快取機制和資料儲存)
2019-03-04
Web快取
手把手教你實現Android RecyclerView上拉載入功能
2017-04-13
AndroidView
MyBatis快取機制（一級快取，二級快取）
2020-05-20
MyBatis快取
Android 的 so 檔案載入機制
2019-03-03
Android

Android：手把手教你構建 WebView 的快取機制 & 資源預載入方案

前言

目錄

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

1.1 H5 頁面載入速度慢

1.1.1 渲染速度慢

1.1.2 頁面資源載入緩慢

1.2 耗費流量

總結

2. 解決方案

2.1 Android WebView 自身的快取機制

2.1.1 快取機制

1. 瀏覽器快取機制

a. 原理

b. 特點

c. 應用場景

d. 具體實現

2. Application Cache 快取機制

a. 原理

b. 特點

c. 應用場景

d. 具體實現

3. Dom Storage 快取機制

a. 原理

b. 特點

c. 應用場景

d. 具體實現

4. Web SQL Database 快取機制

a. 原理

b. 特點

c. 應用場景

d. 具體實現

特別說明

5. IndexedDB 快取機制

a. 原理

b. 特點

c. 應用場景

d. 具體實現：

6 . File System

a. 原理

b. 特點

c. 應用場景

d. 具體使用

快取機制彙總

使用建議

小技巧

2.1.2 快取模式

2.2. 自身構建快取

2.2.1 需求場景

2.2.2 解決方案（原理）

2.2.3 具體步驟

2.2.4 具體實現

2.2.5 具體例項

具體步驟 & 程式碼如下

Demo地址

特別注意

這種快取機制的好處

3. 總結

請點“喜歡”！因為你們的贊同/鼓勵是我寫作的最大動力！

歡迎關注carson_ho的微信公眾號

相關文章

2.1 `Android WebView` 自身的快取機制