Android Webview的性能问题
前言
由于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）的空间限制
