Webview – Caching mechanism & Resource preloading solution

Reprinted from: original article by CSDN blogger “Carson_Ho”. Please attach the original source link and this statement.

Original link: blog.csdn.net/carson_ho/a…

Today, I’m going to propose some effective solutions to Android Webview’s slow loading and traffic consumption.

1. What are the performance problems of Android WebView?

• The loading speed of H5 page in Android WebView is slow
• Take traffic

1.1 H5 Page loading speed is slow

1.1.1 Slow rendering speed

The speed of front-end H5 page rendering depends on two things:

• Js parsing efficiency

Js itself parsing process is complex, parsing speed is not fast & front-end page involves many Js code files, so the superposition will lead to Js parsing efficiency is very low

• The performance of the phone’s hardware

Due to the fragmentation of Android models, the performance of mobile phone hardware devices is uncontrollable, and most Android mobile phone hardware devices cannot achieve very good hardware performance

Summary: H5 pages render slowly due to the above two reasons.

1.1.2 Slow Page resource loading

The H5 page is obtained from the server and stored in the Android phone’s memory:

• H5 pages tend to be larger

• Each load of an H5 page will generate many network requests:

  HTML main URL itself request; HTML external references to JS, CSS, font files, images are also a separate HTTP request. Each request is serial, so many requests are strung together, which causes H5 page resources to load slowlyCopy the code

Summary: H5 slow page loading causes: slow rendering & slow page resource loading.

1.2 Flow consumption

• Each time the H5 page is used, the user needs to reload the H5 page of the Android WebView
• Each H5 page loaded generates more network requests (mentioned above)
• Each request is serial, and with so many requests strung together, more traffic is consumed

1.3 summarize

To sum up, the main reasons for Android WebView performance problems are:

The above problems lead to a big gap between the H5 page experience of Android WebView and Native.

2. Solutions

I propose three solutions to the above performance problems of Android WebView:

• Front-end H5 cache mechanism (WebView)

• Resource preloading

• Resources to intercept

2.1 Cache mechanism of front-end H5

Define cache, that is, offline storage

This means that H5 pages are stored in the cache area after loading, and the essence of WebView is accessible without network connection = embed H5 pages in Android, so, Android WebView's own cache mechanism is actually the H5 page cache mechanism Android WebView in addition to the new File System cache mechanism is not supported, other support. roleCopy the code

Offline browsing: Users can access H5 pages when there is no network connection to improve page loading speed & reduce traffic consumption: directly use cached resources without reloading

The specific application

This section mainly introduces the front-end H5 cache mechanism cache mechanism & cache mode: A. Cache mechanism: how to save the loaded web page data to the local b. Cache mode: how to read the cached web page before loading, the former is saved, the latter is read, please pay attention to the differenceCopy the code

2.1.1 Cache mechanism

Android WebView has five built-in caching mechanisms:

2, Application Cache mechanism 3, Dom Storage Cache mechanism 4, Web SQL Database Cache mechanism 5, Indexed Database Cache mechanism 6, File System Caching mechanism (a new caching mechanism for H5 pages, although not currently supported by Android WebView, but will be briefly introduced)Copy the code

Each of these caching mechanisms is described in detail below.

1. Browser caching mechanism

Principle A mechanism for controlling file caching based on cache-Control (or Expires) and last-Modified (or Etag) fields in the HTTP header

Cache-control, Expires, Last-Modified & Etag fields are described in detail below

Cache-control: controls the Cache validity period of files. For example, cache-control :max-age=600 indicates that files should be cached locally and the validity period is 600 seconds from the time the request is sent. For the next 600 seconds, if there is a request for this resource, the browser will not make an HTTP request, but will simply use the locally cached file. Expires. Cache-control is an HTTP1.0 field. Cache-control is an HTTP1.1 field. Cache-control priority last-modified: Identifies when the file was last updated on the server. On the next request, If the file cache is out of date, the browser sends the date in the if-modified-since field to the server, which compares the timestamp to determine whether the file has changed. If not, the server returns 304 telling the browser to continue using the cache; If there are changes, 200 is returned, along with the most recent file. Etag: Functions as last-modified, indicating when a file was Last updated on the server. The difference is that the value of Etag is a character string that identifies the file. When querying whether the file is updated, the browser sends the signature string to the server using the if-none-match field. The server matches the latest signature string to determine whether the file is updated. There is no update back package 304, there is update back package 200 Etag and Last-Modified can be used as required or both. When two files are used at the same time, the file is considered not updated as long as one of the base conditions is met. The common usage is: cache-control is used with last-modified; Expires is used with Etag; Note: The browser cache mechanism is the mechanism of the browser kernel, and it is generally standard implementation: Cache-control, Last-Modified, Expires, and Etag are all standard implementations that you don't need to worry aboutCopy the code

The characteristics of

• Advantages: Supports Http protocol layer
• Insufficient: Cache files need to be loaded for the first time. The storage space of the browser cache is limited, and the cache may be cleared. The cached file is not verified.

To solve these problems, you can refer to the offline package of Hand Q

Application Scenario Storage of static resource files, such as JS, CSS, fonts, and images.

Android Webview will store cached file records and file contents in the data directory of the current app.

Specific implementation of Android WebView built-in automatic implementation, that is, do not need to set that implementation

WebView kernel after Android 4.4: Chrome cache mechanism is the mechanism of the browser kernel, generally standard implementation

2. Application Cache

The principle is to cache files as a unit, and files have a certain update mechanism (similar to the browser cache mechanism)

The AppCache principle has two key points: the manifest property and the MANIFEST file.

<! DOCTYPE HTML > < HTML manifest="demo_html.appcache"> < HTML manifest="demo_html.appcache"> // When the browser first loads an HTML file, it parses the manifest property and reads the manifest file, fetching the manifest Section: <body>... <body>... </body> </ HTML > // The mechanism is described as follows: // AppCache also has an update mechanism after it is first loaded. // The manifest file must be updated if the cached file is to be updated. // The manifest file must be updated if the cached file is to be updated. Refetch the manifest file, for // Section: // If the user has manually cleared the AppCache, the browser will regenerate the CACHE for the next load. The AppCache cache file is stored separately from the browser cache file, because AppCache has a local space limit of 5MB (split HOST)Copy the code

Features Easy to build Web App cache, specially developed for offline use of Web apps cache mechanism

Application scenario Storing static files (such as JS, CSS, and font files)

Application scenario The same as the browser cache mechanism But AppCache is a supplement to the browser cache mechanism, not a substitute.

The specific implementation

WebSettings Settings = getSettings(); String cacheDirPath = context.getFilesDir().getAbsolutePath()+"cache/"; // 1. Set the cache path settings.setAppCachePath(cacheDirPath); / / 2. Set the cache size Settings. SetAppCacheMaxSize (20 * 1024 * 1024); / / 3. Open the Application Cache storage mechanism Settings. SetAppCacheEnabled (true); / / pay special attention to each Application / / just call a WebSettings. SetAppCachePath () and WebSettings setAppCacheMaxSize ()Copy the code

3. Dom Storage caching mechanism

The principle is provided by storing key-value pairs of strings. DOM Storage is divided into sessionStorage and localStorage. The two use methods are basically the same, the difference lies in the scope of action:

• SessionStorage: temporary, i.e. store page-related data, it is not available after the page is closed
• LocalStorage: persistent, that is, saved data can be used even after the page is closed.

The characteristics of

• Large storage space (5MB) : the storage space is different for different browsers. For example, Cookies are only 4KB
• Secure and convenient Storage: Dom Storage stores data locally and does not need to interact with the server frequently

Unlike Cookies, which send network requests to the server every time a page is requested

Application Scenario Stores temporary and simple data

** The traditional method of storing information to cookies ** that the server does not need to know

The Dom Storage mechanism is similar to the Android SharedPreference mechanism

WebSettings Settings = getSettings();

settings.setDomStorageEnabled(true); // Enable DOM storageCopy the code

4. Web SQL Database caching mechanism

Principles A DATABASE storage mechanism based on SQL

Features Make full use of the advantages of the database, data can be easily added, deleted, modified, query

Application scenario Stores structured data suitable for databases

The specific implementation

WebSettings Settings = getSettings(); String cacheDirPath = context.getFilesDir().getAbsolutePath()+"cache/"; settings.setDatabasePath(cacheDirPath); / / set the path cache Settings. SetDatabaseEnabled (true); According to the official description, the Web SQL Database storage mechanism is no longer recommended (and no longer maintained) and is replaced by the IndexedDB cache mechanism, as described belowCopy the code

5. IndexedDB cache mechanism

NoSQL databases store key-value pairs of strings. The key-value Storage mode is similar to that of Dom Storage

The characteristics of

Application Scenario Stores complex and large amount of structured data

Concrete implementation:

WebSettings Settings = getSettings(); settings.setJavaScriptEnabled(true); // Android added support for IndexedDB in 4.4. Simply turn on the JS switch to allow JS execution.Copy the code

6 . File System

The principle of

• It provides a virtual file system for H5 page data, which can create, read, write, delete, traverse and other operations of files (folders), just as the Native App accesses the local file system

• Virtual file systems run in sandboxes. Virtual file systems of different WebApps are isolated from each other. Virtual file systems are also isolated from local file systems.

• Virtual file systems provide two types of storage: temporary & persistent:

  Temporary storage space: automatically allocated by the browser, but can be reclaimed by the browser persistent storage space: must be explicitly requested. Manage your own content (browsers don't recycle or clean it up); The storage space size is managed by quota. You need to apply for an initial quota for the first time and apply for another quota when the quota is used up.Copy the code

The characteristics of

• Binary data that can store large volumes of data
• Preloadable resource files
• Edit files directly

Usage Scenario Manage data using a file system

Android WebView does not support File System because it is a new cache mechanism added in H5.

Summary of Caching mechanisms

• Use advice

Based on the analysis of the above cache mechanism, we can choose different cache mechanisms (combined use) according to different demand scenarios (caching different types of data scenarios). The following are suggestions for using the cache mechanism:

2.1.2 Cache Mode

Defining cache mode is a way of telling the Android WebView when to read the cache and how to read the cache before loading the H5 web page and saving it to the local cache for use

Android WebView has four built-in cache modes: // Cache mode description: // LOAD_CACHE_ONLY: does not use the network, only reads the local cache data // LOAD_NO_CACHE: // LOAD_DEFAULT: (default) Determines whether to fetch data from the network based on cache-control. // LOAD_CACHE_ELSE_NETWORK, as long as there is local, regardless of expiration, or no-cache, use the data in the cache. Use webView.getSettings ().setCachemode (websettings.load_cache_else_network); // Set the parametersCopy the code

2.2 Resource Preloading

Define the H5 pages that will be used by pre-loading, that is, pre-build the cache to be fetched when it is used rather than loaded when it is needed

Concrete implementation of preloading WebView object & preloading H5 resources

2.2.1 Preloading WebView Objects

This is mainly divided into two aspects: the first use of WebView objects & the subsequent use of WebView objects as shown in the following figure

2.2.2 Preloading H5 Resources

Principle When the application starts and initializes the first WebView object, it directly starts the network request to load the H5 pages and then obtains the H5 pages from the local object when the H5 pages need to be opened

A. Load common H5 page resources in advance (after loading there is a cache) b. Although this method can not reduce the WebView initialization time, but the data request and WebView initialization can be carried out in parallel, the overall page load time is shortened; Reduce overall page load time:Copy the code

The implementation of the Android BaseApplication initializes a WebView object (used to load common H5 page resources); When these pages need to be used, it is recommended to use this scheme for the home page of Android WebView, which can effectively improve the efficiency of home page loading

2.3 Build your own cache

In order to effectively solve the performance problems of Android WebView, in addition to the use of Android WebView’s own cache mechanism, we can also build a cache mechanism for a certain demand scenario.

2.3.1 Requirement Scenario

2.3.2 Implementation steps

1, will update frequency is low, commonly used in advance & fixed H5 static resource files (such as JS, CSS files, pictures, etc.) on the local 2, intercept H5 page resources network request and testing 3, if detected local with the same static resources Directly read from the local to replace and not send the resource request to the network Server AcquisitionCopy the code

2.3.3 Specific implementation

Rewrite the shouldInterceptRequest method of the WebViewClient to intercept static resources when accessing them from the server and replace them with local resources if they are the same

/ / assume that now need to intercept a picture with local resources to replace mWebview. SetWebViewClient (new WebViewClient () {/ / rewrite WebViewClient ShouldInterceptRequest () shouldInterceptRequest(WebView view, ShouldInterceptRequest (WebView view, shouldInterceptRequest) WebResourceRequest Request) shouldInterceptRequest(WebView view, String url) @override public WebResourceResponse shouldInterceptRequest(WebView view, String url) { If (url.contains("logo.gif")) {// If (url.contains("logo.gif")) {// If (url.contains("logo.gif")) { HTTP: / / http://abc.com/imgage/logo.gif / / picture resource file named: logo. GIF InputStream is = null; // Step 2: Create an input stream try {is =getApplicationContext().getassets ().open("images/abc.png"); // Step 3: Obtain the resources to be replaced (in the assets folder) // a. Create an assets folder under app/ SRC /main // b. Create an images folder inside assets // c. } catch (IOException e) {e.prinintStackTrace ();} catch (IOException e) {e.prinintStackTrace (); } // Step 4: Replace the resource WebResourceResponse Response = new WebResourceResponse("image/ PNG ", "UTF-8 ", is); // Parameter 1: content-type of the image in the HTTP request, where the image is image/ PNG // Parameter 2: encoding Type // Parameter 3: input stream containing the replacement resource (the one created above) return response; } return super.shouldInterceptRequest(view, url); } shouldInterceptRequest(shouldInterceptRequest); WebResourceRequest request) @TargetApi(Build.VERSION_CODES.LOLLIPOP) @Override public WebResourceResponse ShouldInterceptRequest (WebView View, WebResourceRequest Request) {shouldInterceptRequest(WebView View, WebResourceRequest Request) { If (request.geturl ().tostring (). Contains ("logo.gif")) {// HTTP: / / http://abc.com/imgage/logo.gif / / picture resource file named: logo. GIF InputStream is = null; // Step 2: Create an input stream try {is = getApplicationContext().getassets ().open("images/abc.png"); // Step 3: Obtain the resources to be replaced (in the assets folder) // a. Create an assets folder under app/ SRC /main // b. Create an images folder inside assets // c. In the images folder, place the resource that needs to be replaced (here the abc.png image is replaced). Catch (IOException e) {e.prinintStackTrace (); } // Step 4: Replace the resource WebResourceResponse Response = new WebResourceResponse("image/ PNG ", "UTF-8 ", is); // Parameter 1: content-type of the image in the HTTP request, where the image is image/ PNG // Parameter 2: encoding Type // Parameter 3: input stream containing the replacement resource (the one created above) return response; } return super.shouldInterceptRequest(view, request); }}); }Copy the code

• Pay special attention to

  Incremental update: When the user is in WIFI environment, let the server push to the local many famous apps (such as wechat) is to update local resources in a small rangeCopy the code

• The benefits of this caching mechanism

  1. Effectively solve the problem of slow loading speed of static resources on H5 page and high traffic consumption

  2. Low development cost

  It doesn't change any of the front-end H5 code, doesn't need to do anything customized for the APP, it just speeds up the H5 load better, and even if it fails, it won't have other negative effects on the H5 pageCopy the code

  3. The corresponding cookie can also be obtained

  The sent network request will take the cookie from the previous user action and will remain because we did not change the URL of the resource

---

Other:

The WebView – based

WebView- Pothole Filling Road

WebView-# Small optimizations & Security vulnerabilities and fixes