前言
随着app的迭代，嵌入的html5界面越来越多了，webview这个强大组件引起的问题越发的多起来，例如：
- 1、webview导致的oom问题
- 2、android版本不同，采用了不同的内核，兼容性crash
- 3、不同版本实现不同，甚至uri不规范也会引起不同程度的问题
通常的H5加载流程
一般将html/js/css等静态资源放到CDN上，而后页面加载后，再经过CGI去拉取最新的数据，进行拼接展现。这种模式的加载流程以下： html
- 加载开始前作初始化工做，包括Runtime初始化，建立WebView等；
- 完成初始化以后，WebView开始去请求资源加载H5页面；
- 页面发起CGI请求对应的数据（或者经过本地缓存获取），拿到数据后对DOM进行操做更新。
从流程上看存在的直观的问题：android
- 终端耗时：终端初始化阶段的时间里（网络资料显示耗时在1s以上），网络彻底是处于空闲等待状态的，浪费时间；
- 资源和数据动态拉取，获取的速度受制于网络速度；
一. 分析
为什么拥有Webview的H5页面打开这么慢，是因为它通常会经历以下几个阶段：
1）Webview初始化。
2）到达新的页面，网络连接，从服务器下载html，css，js，页面白屏。
3）页面基本框架出现，js请求页面数据，页面处于loading状态。
4）出现所需的数据，完成整个页面的渲染，用户可交互。
可以用下面这张图来表示：
很明显，相对于原生应用只需要从后台拉取数据进行渲染来说，Webview多了初始化，拉取整个页面资源这2个步骤，而且他们的顺序是串行的。
即必须在完成初始化后才能开始建立网络连接(因为Webview相当于浏览器客户端，我们在PC上也是必须先打开chrome浏览器才能再输入网址打开页面)，拉取html，css，js等资源，而只有拉取到js之后，js才能发起ajax网络请求，获取需要展现的动态数据。
而初始化，建立网络连接，拉取数据恰恰都是比较耗时的操作，这就是为什么我们从直观上来讲感觉速度太慢的原因。
知道了原因后，我们就可以针对各个阶段来逐个优化。
二. Webview提前初始化
我们知道每个页面在打开时都会调用setContentView()方法 -> inflate() -> createViewFromTag()，也就是说都会调用view的构造函数，webview也不例外，但是不同的是webview的首次构造耗时比较长。
可以通过简单的代码来对比一下Webview首次初始化和第二次所花费的时间：
private void testWebViewInitUsedTime(){long p = System.currentTimeMillis();WebView mWebView = new WebView(this);long n = System.currentTimeMillis();Log.i("Info", "testWebViewFirstInit use time:" + (n-p));
}testWebViewInitUsedTime();
testWebViewInitUsedTime();//测试环境 Android 7.0 三星S7
testWebViewFirstInit use time:182
testWebViewFirstInit use time:4
可见第二次所用的时间远远小于第一次，这是为什么呢？
通过阅读源码，我们会发现Webview所有的逻辑处理都是通过WebViewProvider来实现的，因为它要加载Webview内核，这是一个重量级的操作，内核是以apk的形式存在。而内核加载后在同一页面是共享的，因此后续的初始化时间就很少了。
static WebViewFactoryProvider getProvider()
{
...Class<WebViewFactoryProvider> providerClass = getProviderClass();
sProviderInstance = providerClass.getConstructor(WebViewDelegate.class).newInstance(new WebViewDelegate());
return sProviderInstance;
}private static Class<WebViewFactoryProvider> getProviderClass()
{
...loadNativeLibrary();
}private static int loadNativeLibrary()
{
...String[] args = getWebViewNativeLibraryPaths();
int result = nativeLoadWithRelroFile(args[0] /* path32 */,args[1] /* path64 */,CHROMIUM_WEBVIEW_NATIVE_RELRO_32,CHROMIUM_WEBVIEW_NATIVE_RELRO_64);}
既然如此，我们可以在App生成一个全局webview，并且在启动时初始化，这样在后面使用时通过动态获取这个全局Webview，然后添加到rootview中，这样就可以进行复用从而减少初始化的时间。
不过需要注意的是，如果在不同页面使用Webview时使用不同的设置，就需要动态维护，而且在不同的页面跳转前要做好清理工作。
三．H5页面拉取优化
有了Webview，就要开始拉取H5页面了。针对这一步，我们可以把html，css，js，image等资源预置在客户端本地，并和服务端协商好前端的版本控制和增量更新策略，如此一来Webview就可以先快速加载本地缓存页面资源，剩下的就只需要拉取那些需要更新的增量资源即可。
而针对这些需要拉取的增量资源，可以对它们进行webpack+gzip数据压缩和CDN加速处理，以提升拉取速度。并且在建立网络连接时，可以让前端请求的域名和客户端API接口域名一致，以减少DNS解析时间。
最后，对于H5页面来说，图片资源的拉取是最为耗时的，一个比较好的解决方案就是先加载并展示非图片内容，延迟这些图片的加载，以提升用户体验。
WebView有一个setBlockNetworkImage(boolean)方法，该方法的作用是是否屏蔽图片的加载。可以利用这个方法来实现图片的延迟加载：在onPageStarted时屏蔽图片加载，在onPageFinished时开启图片加载。
四．H5动态数据拉取并行
正常的顺序是在html，css，js拉取下来之后，才开始由js发起前端的ajax请求，获取到数据后才开始进行填充。
其实我们可以把前端的ajax请求提前到和页面加载同时进行，由客户端请求数据，等到H5加载完毕，直接向客户端索要即可，如此一来，便缩短了总体的页面加载时间。
五．总结
除了上述提到的点，其实还有很多其他的方案，比如可以通过静态直出，直接下发首屏html的方式加速首屏的展现，也可以通过智能预取的方式提前进行网络请求数据到本地，甚至有些重度依赖H5的App利用预先准备好数据的Webview池来达到加速的目的。