前言

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

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

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

Android WebView里H5页面加载速度慢

耗费流量

下面会详细介绍。

下面会详细介绍：

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

Js解析效率

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

手机硬件设备的性能

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

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

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

H5页面一般会比较多

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

HTML主URL自身的请求；

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

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

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

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

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

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

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

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

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

使用Android WebView自身的缓存机制

自身构建缓存机制(主要是H5页面资源的预加载)

下面我将详细介绍。

定义

缓存，即离线存储

这意味着H5网页 加载过之后会存储在缓存区域，在没有网络连接时也可以进行访问

作用

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

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

具体应用

此处讲解主要讲解Android WebView的缓存机制 & 缓存模式 ：

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

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

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

Android WebView的本质：在Android 中嵌入H5页面

所以，Android WebView自带的缓存机制其实就是H5页面的缓存机制

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

Android WebView自带的缓存机制有5种：

浏览器 缓存机制

Application Cache缓存机制

Dom Storage缓存机制

Web SQL Database缓存机制

Indexed Database缓存机制

File System缓存机制(H5页面新加入的缓存机制，虽然Android WebView暂时不支持，但会进行简单介绍)

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

根据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都是标准实现，你不需要操心

优点：支持Http协议层

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

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

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

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

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

Android4.4后的WebView浏览器版本内核：Chrome

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

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

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

// HTML 在头中通过 manifest 属性引用 manifest 文件

// manifest 文件：就是上面以 appcache 结尾的文件，是一个普通文件文件，列出了需要缓存的文件

// 浏览器在首次加载 HTML 文件时，会解析 manifest 属性，并读取 manifest 文件，获取 Section：CACHE MANIFEST 下要缓存的文件列表，再对文件缓存...// 原理说明如下：

// AppCache 在首次加载生成后，也有更新机制。被缓存的文件如果要更新，需要更新 manifest 文件

// 因为浏览器在下次加载时，除了会默认使用缓存外，还会在后台检查 manifest 文件有没有修改(byte by byte)

发现有修改，就会重新获取 manifest 文件，对 Section：CACHE MANIFEST 下文件列表检查更新

// manifest 文件与缓存文件的检查更新也遵守浏览器缓存机制

// 如用户手动清了 AppCache 缓存，下次加载时，浏览器会重新生成缓存，也可算是一种缓存的更新

// AppCache 的缓存文件，与浏览器的缓存文件分开存储的，因为 AppCache 在本地有 5MB(分 HOST)的空间限制