手把手教你构建 Android WebView 的缓存机制＆资源预加载方案

前言

由于具备 开发周期短、灵活性好 的特点，所以现在大多嵌入了组件进行开发

但我知道你一定在烦恼的性能问题，特别突出的是：加载速度慢 & 消耗流量

今天，我将针对的性能问题，提出一些有效解决方案。

目录

1. Android WebView 存在什么性能问题？

里 页面加载速度慢

耗费流量

下面会详细介绍。

1.1 H5 页面加载速度慢

下面会详细介绍：

1.1.1 渲染速度慢

前端页面渲染的速度取决于 两个方面：

解析效率

本身的解析过程复杂、解析速度不快 & 前端页面涉及较多代码文件，所以叠加起来会导致解析效率非常低

手机硬件设备的性能

由于机型碎片化，这导致手机硬件设备的性能不可控，而大多数的Android手机硬件设备无法达到很好很好的硬件性能

总结：上述两个原因 导致 H5页面的渲染速度慢。

1.1.2 页面资源加载缓慢

页面从服务器获得，并存储在 手机内存里：

页面一般会比较多

每加载一个 页面，都会产生较多网络请求：

主 自身的请求；

外部引用的、字体文件，图片也是一个独立的 请求

每一个请求都串行的，这么多请求串起来，这导致 页面资源加载缓慢

总结：H5页面加载速度慢的原因：渲染速度慢 & 页面资源加载缓慢 导致。

1.2 耗费流量

每次使用页面时，用户都需要重新加载的页面

每加载一个页面，都会产生较多网络请求（上面提到）

每一个请求都串行的，这么多请求串起来，这导致消耗的流量也会越多

1.3 总结

综上所述，产生性能问题主要原因是：

上述问题导致了的 页面体验 与 原生 存在较大差距。

2. 解决方案

针对上述的性能问题，我提出了3种解决方案：

前端的缓存机制（自带）

资源预加载

资源拦截

下面我将详细介绍。

2.1 前端的缓存机制

定义

缓存，即离线存储

这意味着 网页 加载后会存储在缓存区域，在无网络连接时也可访问

的本质 = 在 中嵌入 页面，所以，自带的缓存机制其实就是 页面的缓存机制

除了新的缓存机制还不支持，其他都支持。

作用

离线浏览：用户可在没有网络连接时进行页面访问

提高页面加载速度 & 减少流量消耗：直接使用已缓存的资源，不需要重新加载

具体应用

此处讲解主要讲解 前端的缓存机制 的缓存机制 & 缓存模式 ：

a. 缓存机制：如何将加载过的网页数据保存到本地

b. 缓存模式：加载网页时如何读取之前保存到本地的网页缓存

前者是保存，后者是读取，请注意区别

2.1.1 缓存机制

自带的缓存机制有5种：

浏览器 缓存机制

缓存机制

缓存机制

缓存机制

缓存机制

缓存机制（页面新加入的缓存机制，虽然暂时不支持，但会进行简单介绍）

下面将详细介绍每种缓存机制。

1. 浏览器缓存机制

a. 原理

根据 协议头里的 （或 ）和 （或 ）等字段来控制文件缓存的机制

下面详细介绍、、 & 四个字段

不同的是， 的取值是一个对文件进行标识的特征字串。

在向服务器查询文件是否有更新时，浏览器通过 字段把特征字串发送给服务器，由服务器和文件最新特征字串进行匹配，来判断文件是否有更新：没有更新回包304，有更新回包200

和 可根据需求使用一个或两个同时使用。两个同时使用时，只要满足基中一个条件，就认为文件没有更新。

是 标准中的字段，Cache-Control 是 标准中新加的字段

当这两个字段同时出现时， 优先级较高

：用于控制文件在本地缓存有效时长

如服务器回包：，则表示文件在本地应该缓存，且有效时长是600秒（从发出请求算起）。在接下来600秒内，如果有请求这个资源，浏览器不会发出 HTTP 请求，而是直接使用本地缓存的文件。

：与功能相同，即控制缓存的有效时间

：标识文件在服务器上的最新更新时间

下次请求时，如果文件缓存过期，浏览器通过 If-Modified-Since 字段带上这个时间，发送给服务器，由服务器比较时间戳来判断文件是否有修改。如果没有修改，服务器返回304告诉浏览器继续使用缓存；如果有修改，则返回200，同时返回最新的文件。

：功能同 ，即标识文件在服务器上的最新更新时间。

常见用法是：

与 一起使用；

与 一起使用；

即一个用于控制缓存有效时间，一个用于在缓存失效后，向服务查询是否有更新

特别注意：浏览器缓存机制 是 浏览器内核的机制，一般都是标准的实现

即、 、 、 都是标准实现，你不需要操心

b. 特点

优点：支持 协议层

不足：缓存文件需要首次加载后才会产生；浏览器缓存的存储空间有限，缓存有被清除的可能；缓存的文件没有校验。

对于解决以上问题，可以参考手 Q 的离线包

c. 应用场景

静态资源文件的存储，如` JS、CSS`、字体、图片等。

会将缓存的文件记录及文件内容会存在当前 app 的 data 目录中。

d. 具体实现

内置自动实现，即不需要设置即实现

4.4后的 浏览器版本内核：

浏览器缓存机制 是 浏览器内核的机制，一般都是标准的实现

2. Application Cache 缓存机制

a. 原理

以文件为单位进行缓存，且文件有一定更新机制（类似于浏览器缓存机制）

原理有两个关键点：manifest 属性和 manifest 文件。

b. 特点

方便构建的缓存

专门为 离线使用而开发的缓存机制

c. 应用场景

存储静态文件（如、、字体文件）

应用场景 同 浏览器缓存机制

但AppCache 是对 浏览器缓存机制 的补充，不是替代。

d. 具体实现

3. Dom Storage 缓存机制

a. 原理

通过存储字符串的 对来提供

分为 & ； 二者使用方法基本相同，区别在于作用范围不同：

a. ：具备临时性，即存储与页面相关的数据，它在页面关闭后无法使用

b. ：具备持久性，即保存的数据在页面关闭后也可以使用。

b. 特点

存储空间大（ 5MB）：存储空间对于不同浏览器不同，如Cookies 才 4KB

存储安全、便捷： 存储的数据在本地，不需要经常和服务器进行交互

不像 每次请求一次页面，都会向服务器发送网络请求

c. 应用场景

存储临时、简单的数据

代替 将 不需要让服务器知道的信息 存储到 的这种传统方法

机制类似于 的 机制

d. 具体实现

4. Web SQL Database 缓存机制

a. 原理

基于 `SQL` 的数据库存储机制

b. 特点

充分利用数据库的优势，可方便对数据进行增加、删除、修改、查询

c. 应用场景

存储适合数据库的结构化数据

d. 具体实现

特别说明

根据官方说明，存储机制不再推荐使用（不再维护）

取而代之的是缓存机制，下面会详细介绍

5. IndexedDB 缓存机制

a. 原理

属于 数据库，通过存储字符串的 对来提供

类似于 的存储方式

b. 特点

c. 应用场景

存储 复杂、数据量大的结构化数据

d. 具体实现：

6 . File System

a. 原理

为 页面的数据 提供一个虚拟的文件系统

可进行文件（夹）的创建、读、写、删除、遍历等操作，就像 访问本地文件系统一样

虚拟的文件系统是运行在沙盒中

不同 的虚拟文件系统是互相隔离的，虚拟文件系统与本地文件系统也是互相隔离的。

虚拟文件系统提供了两种类型的存储空间：临时 & 持久性：

临时的存储空间：由浏览器自动分配，但可能被浏览器回收

持久性的存储空间：需要显式申请；自己管理（浏览器不会回收，也不会清除内容）；存储空间大小通过配额管理，首次申请时会一个初始的配额，配额用完需要再次申请。

b. 特点

可存储数据体积较大的二进制数据

可预加载资源文件

可直接编辑文件

c. 应用场景

通过文件系统 管理数据

d. 具体使用

由于 是 新加入的缓存机制，所以暂时不支持

缓存机制汇总

使用建议

综合上述缓存机制的分析，我们可以根据 需求场景的不同（缓存不同类型的数据场景） 从而选择不同的缓存机制（组合使用）

以下是缓存机制的使用建议：

2.1.2 缓存模式

定义

缓存模式是一种 当加载 网页时 该如何读取之前保存到本地缓存

从而进行使用 的方式

即告诉 什么时候去读缓存，以哪种方式去读缓存

自带的缓存模式有4种：

具体使用

2.2 资源预加载

定义

提早加载将需使用的H5页面，即 提前构建缓存

使用时直接取过来用而不用在需要时才去加载

具体实现

预加载对象 & 预加载资源

2.2.1 预加载WebView对象

此处主要分为2方面：首次使用的WebView对象 & 后续使用的WebView对象

具体如下图

2.2.2 预加载H5资源

原理

a. 从而 事先加载常用的H5页面资源（加载后就有缓存了）

b. 此方法虽然不能减小WebView初始化时间，但数据请求和WebView初始化可以并行进行，总体的页面加载时间就缩短了；缩短总体的页面加载时间：

在应用启动、初始化第一个对象时，直接开始网络请求加载页面

后续需打开这些H5页面时就直接从该本地对象中获取

具体实现

在 的里初始化一个对象（用于加载常用的H5页面资源）；当需使用这些页面时再从BaseApplication里取过来直接使用

2.2.3 应用场景

对于Android WebView的首页建议使用这种方案，能有效提高首页加载的效率

2.3 自身构建缓存

为了有效解决 的性能问题，除了使用 自身的缓存机制，还可以自己针对某一需求场景构建缓存机制。

2.3.1 需求场景

2.3.2 实现步骤

事先将更新频率较低、常用 & 固定的静态资源 文件（如、文件、图片等） 放到本地

拦截页面的资源网络请求 并进行检测

如果检测到本地具有相同的静态资源 就 直接从本地读取进行替换 而 不发送该资源的网络请求 到 服务器获取

2.3.3 具体实现

重写 的 方法，当向服务器访问这些静态资源时进行拦截，检测到是相同的资源则用本地资源代替

2.3.5 具体实例

下面我将通过 替换主页面（）中的一个图片（） 来对静态资源拦截 进行说明。

为了更好的表现效果，我将替换的图片换成别的图片

具体步骤 & 代码如下

步骤1：定义布局

activity_main.xml

步骤2：进行资源的拦截、检测 & 替换（详细请看注释）

MainActivity.java

步骤3：加入网络权限

Manifest.xml

Demo地址

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

特别注意

关于上述放到本地的静态资源也是可以更新的：

1. 发布新版本安装更新

2. 增量更新：在用户处于环境时让服务器推送到本地

很多著名的（如微信）就是采用小范围更新本地资源的

这种缓存机制的好处

有效解决 页面静态资源 加载速度慢 & 流量消耗多的问题

开发成本低

没有改变前端的任何代码，不需要为 APP 做定制化的东西

该方法只是更好地加快加载速度，哪怕失效，也不会对页面产生其他负面影响

同样能获得相应的

发送的网络请求会直接带上先前用户操作所留下的 而都能够留下来，因为我们没有更改资源的 URL 地址

3. 总结

本文主要 对 的性能问题 & 解决方案 进行了全面介绍

我相信你还会需要下面关于 的文章

Android开发：最全面、最易懂的Webview详解

最全面总结 Android WebView与 JS 的交互方式

你不知道的 Android WebView 使用漏洞