Android WebView 的快取機制 & 資源預載入方案

阿新 • • 發佈：2019-02-11

前言

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

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

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

下面會詳細介紹。

1.1 H5 頁面載入速度慢

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四個欄位
1. Cache-Control：用於控制檔案在本地快取有效時長
  
  如伺服器回包：Cache-Control:max-age=600，則表示檔案在本地應該快取，且有效時長是600秒（從發出請求算起）。在接下來600秒內，如果有請求這個資源，瀏覽器不會發出 HTTP 請求，而是直接使用本地快取的檔案。
2. Expires：與Cache-Control功能相同，即控制快取的有效時間
  1. Expires是 HTTP1.0 標準中的欄位，Cache-Control 是 HTTP1.1 標準中新加的欄位
  2. 當這兩個欄位同時出現時，Cache-Control 優先順序較高
3. Last-Modified：標識檔案在伺服器上的最新更新時間
  
  下次請求時，如果檔案快取過期，瀏覽器通過 If-Modified-Since 欄位帶上這個時間，傳送給伺服器，由伺服器比較時間戳來判斷檔案是否有修改。如果沒有修改，伺服器返回304告訴瀏覽器繼續使用快取；如果有修改，則返回200，同時返回最新的檔案。
4. Etag：功能同Last-Modified ，即標識檔案在伺服器上的最新更新時間。
  1. 不同的是，Etag 的取值是一個對檔案進行標識的特徵字串。
  2. 在向伺服器查詢檔案是否有更新時，瀏覽器通過If-None-Match 欄位把特徵字串傳送給伺服器，由伺服器和檔案最新特徵字串進行匹配，來判斷檔案是否有更新：沒有更新回包304，有更新回包200
  3. 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頁面的資料提供一個虛擬的檔案系統
1. 可進行檔案（夾）的建立、讀、寫、刪除、遍歷等操作，就像 Native App 訪問本地檔案系統一樣
2. 虛擬的檔案系統是執行在沙盒中
3. 不同 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裡取過來直接使用
1. 對於Android WebView的首頁建議使用這種方案，能有效提高首頁載入的效率
2. 當然這裡的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) {

 
 
              
           
              
              
            
            相關推薦
			   
            
            
            
 

    

    
    Android WebView 的快取機制 & 資源預載入方案
      
                

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

  
 

    

    
    android WebView快取機制介紹
      
                

當我們載入Html時候，會在我們data/應用package下生成database與cache兩個資料夾:

我們請求的Url記錄是儲存在webviewCache.db裡，而url的內容是儲存在webviewCache資料夾下.


WebView中存在著兩種快取：網頁資 

  
 

    

    
    Android WebView 快取機制和模式詳解
      
package com.example.webviewtest;  
  
import java.io.File;  
  
import android.app.Activity;  
import android.graphics.Bitmap;  
import android.os.Bundle; 

  
 

    

    
    Android WebView使用全面解析（載入網路資源、本地HTML，JS互動）
      
                
簡述：  
  WebView是什麼？有什麼用途？我們先來看一下官方介紹：
     A View that displays web pages. This class is the basis upon which you can roll your own web b 

  
 

    

    
    android 視訊的縮圖 快取機制和 非同步載入縮圖
      
							
							
							在這次的工作開發專案中，涉及到一個視訊縮圖的視訊列表；這個在大家看來，製作視訊縮圖就是兩行程式碼就搞定的事。確實是這樣的，百度一下，每個帖子都知道製作視訊縮圖的方法，在這裡確實也是一樣的，但是我要實現的是讓縮圖 在ListView上顯示，而且不會出現卡頓，其實也 

  
 

    

    
    資源預載入preload和資源預讀取prefetch簡明學習
      前面的話
　　基於VUE的前端小站改造成SSR伺服器端渲染後，HTML文件會自動使用preload和prefetch來預載入所需資源，本文將詳細介紹preload和prefetch的使用

資源優先順序
　　在介紹preload和prefetch之前，首先要介紹瀏覽器的資源優先順序

　　在Chr 

  
 

    

    
    Android程序回收機制和保活方案
       
 
 
 1 Low Memory Killer機制 
 在Android系統中，程序的生命週期都是由系統來控制的。出於體驗和效能上的考慮，即使對一個App進行Home鍵還是Back鍵退出的操作，系統並不會真正殺掉該App的程序，它的程序依然存在於記憶體之中。因為這樣在下次要啟動這個App時就能更加快速。 

  
 

    

    
    HTML5頁面資源預載入(Link prefetch)寫法
      
                
不管是瀏覽器的開發者還是普通web應用的開發者，他們都在做一個共同的努力：讓Web瀏覽有更快的速度感覺。有很多已知的技術都可以讓你的網站速度變得更快：使用CSS sprites，使用圖片優化工具，使用.htaccess設定頁面頭資訊和快取時間，JavaScript壓縮，使用 

  
 

    

    
    HTML5的頁面資源預載入技術(Link prefetch)加速頁面載入
      
							
							
							

不管是瀏覽器的開發者還是普通web應用的開發者，他們都在做一個共同的努力：讓Web瀏覽有更快的速度感覺。有很多已知的技術都可以讓你的網站速度變得更快：使用CSS sprites，使用圖片優化工具，使用.htaccess設定頁面頭資訊和快取時間，JavaScr 

  
 

    

    
    Android WebView的cookie第一次載入不工作的問題的解決
      
                

 今天遇到一個問題，在使用WebView載入一個網頁時，當用戶點選一個需要登陸的按鈕時，就跳到自己做的登入頁面，登陸成功以後，就同步WebView，相當於WebView也登入了，但是，等登陸成功以後，重新載入頁面發現還是沒有登陸，要退出這個activity再進入才顯示已經 

  
 

    

    
    Android WebView重定向問題的解決方案
      
當WebView在載入網頁時，有時會有重定向問題，返回鍵回退怎麼也回退不掉，怎麼辦？
WebView有一個getHitTestResult():返回的是一個HitTestResult，一般會根據開啟的連結的型別，返回一個extra的資訊，如果開啟連結不是一個url，或者開啟的連結是JavaScript的ur 

  
 

    

    
    Android webView 快取 Cache + HTML5離線功能解決
      
                
WebView的快取可以分為頁面快取和資料快取。
           頁面快取是指載入一個網頁時的html、JS、CSS等頁面或者資源資料。這些快取資源是由於瀏覽器的行為而產生，開發者只能通過配置HTTP響應頭影響瀏覽器的行為才能間接地影響到這些快取資料。

       

  
 

    

    
    13、Android Webview圖片自適應螢幕解決方案
      
							
							
							圖片過大，通過設定webview後字型又超小。

網上的方法千篇一律

嘗試過程：



1、設定



//    mWebview.getSettings().setUseWideViewPort(true);//讓webview讀取網頁設定的viewpor 

  
 

    

    
    web資源預載入-生產環境實踐
      此文記錄資源預載入在我們專案的實踐，技術難度不算高，重在介紹一套技術方案的誕生與實施，其中都進行了哪些思考，依據什麼來做決策，如何進行效果評估，等等。為讀者在制定技術方案時提供一定啟示。
背景
資源預載入機制很好理解，即在使用者訪問頁面之前，提前載入好相應的資源。這樣使用者在訪問頁面的時候，省去了載入資源的時 

  
 

    

    
    Android圖片載入框架最全解析（三），深入探究Glide的快取機制(筆記)
       
  
  
 原文地址：Android圖片載入框架最全解析（三），深入探究Glide的快取機制 
 筆記： 
 1.Glide快取簡介 
 2.快取Key 
 EngineKey  
  
  重寫了equals()和hashCode()方法，保證只有傳入EngineKey的所有引數都相同的情況下才認為是 

  
 

    

    
    Android webview 載入https:// 網站時不展示 圖片資源
      
                可能原因是：該圖片資源不是https的；

解決辦法：


if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
    webSettings.setMixedContentMode(WebSetti 

  
 

    

    
    android:webview載入網頁速度很慢的的究極解決方案
      
                

 Android客戶端中混搭HTML頁面，會出現雖然HTML內容載入完成，標題也正常顯示，但是整個網頁需要等到近5秒（甚至更多）時間才會顯示出來。研究了很久，搜遍了國外很多網站，也看過PhoneGap的程式碼，一直無解。
       一般人堆WebView的加速，都是建 

  
 

    

    
    android  webview載入網頁按後退鍵黑屏一下問題的解決方案
      
								
								            
						
                
出現這個問題剛開始還真是一頭霧水,不知道怎麼解決,後來跟同事一交流,發現凡是這種問題,很大一部分原因是application的style,或者activity的style設定問題,比如啟動頁黑屏問題也 

  
 

    

    
    Android Apk資源載入機制原始碼分析以及資源動態載入實現系列文章
      
							
							
							Android系統中執行Apk時是如何對包內的資源進行載入以及我們開發中設定相關資源後又是如何被加載出來，這個系列我們可以學習系統載入資源的機制原理，然後我們再巧妙的利用學習系統載入技巧來打造我們自己的動態資源載入機制實現。

這個系列主要分為如下3部分內容來講 

  
 

    

    
    android viewpager+fragment 避免預載入，快取
      
                

一、需求是這樣的：滑動到哪一頁就在家一頁的資料，避免預載入二、由於使用setOffScreenLimit無效解決辦法：<span style="color:#ff6666;">注意：setUserVisibleHint，使用這個方法來完成切換到哪一頁才載入哪一

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.1 `Android WebView` 自身的快取機制