Android Hybrid优化方案详解

受制于客户端发版周期长的问题，而h5开发周期较短，灵活性又好，所以现在大多数app里或多或少都会嵌入h5页面，所以Hybrid建设成了移动端热更新最常用的手段之一。

而WebView的话相对于native来说就会存在加载速度慢的问题。这篇文章我们主要来探讨这个加载速度问题。

前言

首先我们来看WebView加载速度慢的原因：

1. js解析效率。
   js解析本身比较复杂，如果涉及到很多js文件的话，js解析效率会很低，所以加载速度也就快不起来了。

2. 资源下载。
   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进行替换，这样就起到了减少请求的作用来加快加载速度。

具体替换代码可以参考如下代码：

Web离线包