文章目录
受制于客户端发版周期长的问题，而h5开发周期较短，灵活性又好，所以现在大多数app里或多或少都会嵌入h5页面，所以Hybrid建设成了移动端热更新最常用的手段之一。
而WebView的话相对于native来说就会存在加载速度慢的问题。这篇文章我们主要来探讨这个加载速度问题。
前言
首先我们来看WebView加载速度慢的原因：
-
js解析效率。
js解析本身比较复杂，如果涉及到很多js文件的话，js解析效率会很低，所以加载速度也就快不起来了。 -
资源下载。
h5页面是从服务器获取的，每加载一个h5页面就要去获取图片，js，css等文件，会产生很多网络请求，而这些网络请求都是串行的，而这些资源又要等到下载完成以后才回去渲染，所以导致页面渲染速度慢。
ok，知道原因了以后我们就可以来想优化方案了。web优化的原则可以参考《web性能权威指南》，这里我摘入这本书里的经典的性能优化最佳实践一章中提到的思路，我在之前的文章web知识梳理中也有提到：
无论什么网络，也不管所用网络协议是什么版本，所有应用都应该致力于消除或减 少不必要的网络延迟，将需要传输的数据压缩至最少。这两条标准是经典的性能优 化最佳实践，是其他数十条性能准则的出发点。
- 减少DNS查找
每一次主机名解析都需要一次网络往返，从而增加请求的延迟时间，同时还会阻 塞后续请求。- 重用TCP连接
尽可能使用持久连接，以消除 TCP 握手和慢启动延迟- 减少HTTP重定向
HTTP 重定向极费时间，特别是不同域名之间的重定向，更加费时;这里面既有 额外的 DNS 查询、TCP 握手，还有其他延迟。最佳的重定向次数为零。- 使用CDN(内容分发网络)
把数据放到离用户地理位置更近的地方，可以显著减少每次 TCP 连接的网络延 迟，增大吞吐量。这一条既适用于静态内容，也适用于动态内容- 去掉不必要的资源
任何请求都不如没有请求快。- 在客户端缓存资源
应该缓存应用资源，从而避免每次请求都发送相同的内容。- 传输压缩过的内容
传输前应该压缩应用资源，把要传输的字节减至最少:确保对每种要传输的资源 采用最好的压缩手段。- 消除不必要的请求开销
减少请求的 HTTP 首部数据(比如 HTTP cookie)，节省的时间相当于几次往返 的延迟时间。- 并行处理请求和响应
请求和响应的排队都会导致延迟，无论是客户端还是服务器端。这一点经常被忽 视，但却会无谓地导致很长延迟。- 针对协议版本采取优化措施
HTTP 1.x 支持有限的并行机制，要求打包资源、跨域分散资源，等等。相对而 言，HTTP 2.0 只要建立一个连接就能实现最优性能，同时无需针对 HTTP 1.x 的 那些优化方法。
接下来我们的方案也都是根据上面的这些突破点，找到突破口来加快
Android WebView自带的缓存优化详解
首先我们先来看Android WebView自带的几种缓存机制：
浏览器缓存
Application Cache缓存
Dom Storage缓存
SQL Database缓存
Indexed Database缓存
File System 缓存
其他优化方案
WebView提前初始化
这个方案比较简单，其实说白了就是在加载这个h5之前，在外面添加一个0像素的webview，提前加载。因为上面提到的缓存机制，所以到真正用户感知的时候，加载速度明显加快。
提前加载数据
上面讲WebView加载慢的原因的时候也分析到了，因为h5要去服务端获取资源，还需要从服务端获取很多的数据，而这些网络请求都是串行的，所以就导致加载很慢。
这个方案就是以这个问题为切入口，由客户端在加载网页的同时去服务端请求h5需要的数据，然后再通过java调用js这种方式把数据传递给h5，这样就能把本来串行的事改成并行了，从这个角度来加快webview加载速度。
拦截请求本地化资源替换
这个方案其实就是上面引用《web性能权威指南》中的在客户端缓存资源这一点。说白了就是把图片资源等放在客户端本地，然后当h5去发起加载这个图片的网络请求的时候，把这个请求拦截下来，然后把本地的有的图片包装成web h5可以用的图片对象给h5进行替换，这样就起到了减少请求的作用来加快加载速度。
具体替换代码可以参考如下代码：