webview-从业务出发的思考

背景：公司业务2B业务起步，为了app能尽快上线，所以针对一些核心功能使用了H5编写。

问题：核心功能带来 ---> 用户高频触发。而H5从webview打开 到 H5 页面展示出来，在ios iphone5 和 iphone6机型上打开缓慢。

webview性能

从用户使用的过程，大致如下：

1.打开了一个新的窗口

2.页面白屏

3.页面基本骨架渲染出来，但是没有数据

4.数据获取完成，页面整体渲染结束

慢的一部分原因：webview去加载url并不像是 浏览器 加载url的过程，webview存在一个初始化的过程。

过程如图：

图参考自：美团技术团队

所以，webview加载url，第一步并不是建立连接，而是启动浏览器内核。

优化思路

全局webview

app打开初始化一个全局的webview备用，并且将它隐藏，所以对于用户来讲是无感知的。但是这种做法也来带额外的内存开销。但是有时候也是一种不错的选择。

为什么？

业务场景举例：app首页banner点击 ---->  打开webview加载url ----> h5页面点击跳转继续打开一个webview去加载url。

所以，针对这种h5页面并不是在同一个webview的交互，如果使用这种优化手段是一个不错的选择。

数据参考：美团技术团队

因为app打开创建了全局的webview，所以接下来所有的webview打开的内存消耗都只是二次打开带来的内存开销。

客户端代理数据请求

1.在客户端初始化webview的时候，直接由客户端请求数据

2.页面加载结束，从客户端读取数据

个人对这种设计思维并不是很看好：

1.客户端代理数据请求注定需要客户端和H5通信 ，本来简单的H5页面就要使用jsbridge

2.jsbridge的初始化也是需要时间的

webview优化，主要是围绕两点：

1.在使用前预先初始化好WebView，从而减小耗时。

2.在初始化的同时，通过Native来完成一些网络请求等过程，使得WebView初始化不是完全的阻塞后续过程。

ps:

参考自：https://tech.meituan.com/WebViewPerf.html