WebView优化

过程分析

对于一个普通用户来讲，打开一个WebView通常会经历以下几个阶段：

1. 交互无反馈
2. 到达新的页面，页面白屏
3. 页面基本框架出现，但是没有数据；
4. 页面处于loading状态 出现所需的数据

如果从程序上观察，WebView启动过程大概分为以下几个阶段：

图片摘自美团技术团队

点开某个网页的那一刻发生了什么。举个例子,假如你点开了手机腾讯网，浏览器首先会通过DNS查到这个网站的真是ip地址，然后向该ip地址发起http协议的请求，请求拉取手机腾讯网的html页面。这时候你的手机和腾讯网的服务器悄悄的进行了数次握手，最终达成一致，服务器开始向你的手机传回html网页。
呼哧呼哧，经过无数个路由器和网关，html网页终于拉取到了。但是别高兴的太早，这个时候浏览器还不能显示出这个网页，原因是网页上还有很多CSS资源（用来美化网页的，控制字体啊、颜色之类的，没有CSS的手机腾讯网长下面这个样子）需要拉取。于是浏览器找到写在html网页里的CSS资源地址，再次向服务器发起http协议。
呼哧呼哧，CSS资源拉回来了。但是浏览器一看，咦，还有javascript代码落下了呢，于是又去网站上拉取javascript代码。老套路，握手、协商、传数据。为什么必须要拉取javascript代码呢？原来，现在有很多网站，数据都是异步加载的，就像很多APP那样，先显示一个架子（由html描述），然后后台请求数据（由javascript发起），数据拿到了再贴上去，渲染出来。美其名曰用户体验，其实用户该等还是得等。

于是浏览器又呼哧呼哧跑去拉去真正的数据了。
(摘自百度http://www.woshipm.com/pmd/792787.html?ivk_sa=1024320u)

过程总结:

只有当创建WebView实例的时候，才会创建WebView的基础框架。
所以与浏览器不同，App中打开WebView的第一步并不是建立连接，而是启动浏览器内核。

so 于是我们找到了“为什么WebView总是很慢”的原因之一：

1.在浏览器中，我们输入地址时（甚至在之前），浏览器就可以开始加载页面。
2.而在客户端中，客户端需要先花费时间初始化WebView完成后，才开始加载。

指标分析

针对WebView的初始化时间，我们可以定义两个指标：

1.首次初始化时间：客户端冷启动后，第一次打开WebView，从开始创建WebView到开始建立网络连接之间的时间。

2.二次初始化时间：在打开过WebView后，退出WebView，再重新打开WebView，从开始创建WebView到开始建立网络连接之间的时间。

webview存在的问题

1.初始化耗时
2.加载慢
3.白屏

移动端优化

全局WebView

方法：

在客户端刚启动时，就初始化一个全局的WebView待用，并隐藏；
当用户访问了WebView时，直接使用这个WebView加载对应网页，并展示。
这种方法可以比较有效的减少WebView在App中的首次打开时间。当用户访问页面时，不需要初始化WebView的时间。

当然这也带来了一些问题，包括：

额外的内存消耗。
页面间跳转需要清空上一个页面的痕迹，更容易内存泄露。

总结起来都是围绕两点：

1.在使用前预先初始化好WebView，从而减小耗时。
2.在初始化的同时，通过Native来完成一些网络请求等过程，使得WebView初始化不是完全的阻塞后续过程。

注意事项

1. WebView初始化完成，立刻loadUrl，无需等待框架onCreate或者OnResume结束
2. WebView初始完成后到页面首屏绘制完成之间，尽量减少UI线程的其他操作，繁忙的UI线程会拖慢WebView.loadUrl的速度

前端优化篇

建立连接/服务器处理
摘自美团:https://tech.meituan.com/2017/06/09/webviewperf.html

在页面请求的数据返回之前，主要有以下过程耗费时间。

1. DNS
2. connection
3. 服务器处理

技术方案:

DNS采用和客户端API相同的域名

DNS会在系统级别进行缓存，对于WebView的地址，如果使用的域名与native的API相同，则可以直接使用缓存的DNS而不用再发起请求图片。

以美团为例，美团的客户端请求域名主要位于api.meituan.com，然而内嵌的WebView主要位于 i.meituan.com。

当我们初次打开App时：

客户端首次打开都会请求api.meituan.com，其DNS将会被系统缓存。
然而当打开WebView的时候，由于请求了不同的域名，需要重新获取i.meituan.com的IP。
根据上面的统计，至少10%的用户打开WebView时耗费了60ms在DNS上面，如果WebView的域名与App的API域名统一，则可以让WebView的DNS时间全部达到1.3ms的量级。

静态资源同理，最好与客户端的资源域名保持一致。

同步渲染采用chunk编码

同步渲染时如果后端请求时间过长，可以考虑采用chunk编码，将数据放在最后，并优先将静态内容flush。对于传统的后端渲染页面，往往都是使用的【浏览器】–> 【Web API】 –> 【业务 API】的加载模式，其中后端时间就指的是Web API的处理时间了。在这里Web API一般有两个作用：

确定静态资源的版本。
根据用户的请求，去业务API获取数据。
而一般确定静态资源的版本往往是直接读取代码版本，基本无耗时；而主要的后端时间都花费在了业务API请求上面。

那么怎么优化利用这段时间呢？

在HTTP协议中，我们可以在header中设置 transfer-encoding:chunked 使得页面可以分块输出。如果合理设计页面，让head部分都是确定的静态资源版本相关内容，而body部分是业务数据相关内容，那么我们可以在用户请求的时候，首先将Web API可以确定的部分先输出给浏览器，然后等API完全获取后，再将API数据传输给浏览器。

页面框架渲染

页面在解析到足够多的节点，且所有CSS都加载完成后进行首屏渲染。在此之前，页面保持白屏；
在页面完全下载并解析完成之前，页面处于不完整展示状态。

WebView性能优化总结

一个加载网页的过程中，native、网络、后端处理、CPU都会参与，各自都有必要的工作和依赖关系；让他们相互并行处理而不是相互阻塞才可以让网页加载更快：

1. WebView初始化慢，可以在初始化同时先请求数据，让后端和网络不要闲着。
2. WebView初始化慢，就随时初始化好一个WebView待用。
3. 后端处理慢，可以让服务器分trunk输出，在后端计算的同时前端也加载网络静态资源。
4. 同时，合理的预加载、预缓存可以让加载速度的瓶颈更小。
5. DNS和链接慢，想办法复用客户端使用的域名和链接。
6. 脚本执行慢，可以把框架代码拆分出来，在请求页
7. 脚本执行慢，就让脚本在最后运行，不阻塞页面解析。

前端h5侧可以做的优化:

闪电算法的具体内容如下：

移动网页首屏在2秒之内完成打开的，在移动搜索下将获得提升页面评价优待，获得流量倾斜；同时，在移动搜索页面首屏加载非常慢（3秒及以上）的网页将会被打压。

首屏作为直面用户的第一屏，其重要性不言而喻。根据百度用户体验部的研究结果，《白皮书4.0》提出，首屏内容应在1.5秒内加载完成。
白皮书链接,现在已经是白5.0版本了:
https://zy.baidu.com/actxzh/mobile?isResponsible=1

技术建议

广大站长优化页面首屏加载时间，优化的技术建议包括但不限于:

资源加载：

1.将同类型资源在服务器端压缩合并，减少网络请求次数和资源体积。
2.引用通用资源，充分利用浏览器缓存。
3.使用CDN加速，将用户的请求定向到最合适的缓存服务器上。
4.非首屏图片懒加载，将网络带宽留给首屏请求。

页面渲染：

1.将CSS样式写在头部样式表中，减少由CSS文件网络请求造成的渲染阻塞。

2.将JavaScript放到文档末尾，或使用async方式加载，避免JS执行阻塞渲染。

3.对非文字元素（如图片，视频）指定宽高，避免浏览器重排重绘。

h5结语

站点可以结合自身情况升级技术栈，也可以使用通用加速方案（如MIP、AMP）对网页进行综合加速。

优化理念总结

1.提前做：包括预创建WebView和预取数据

2.并行做：包括图片直出&拦截加载，框架初始化阶段开启异步线程准备数据等

3.轻量化：对于前端来说，要尽量减少页面大小，删减不必要的JS和CSS，不仅可以缩短网络请求时间，还能提升内核解析时间

4.简单化：对于简单的信息展示页面，对内容动态性要求不高的场景，可以考虑使用直出替代hybrid，展示内容直接可渲染，无需JS异步加载

直出

简要讲:直接输出
浏览器直接输出渲染好数据的html页面」，简称直出
需要node.js的支持。node.js,就是服务器和前端一样，也用javascript编写，相当于在服务器上也跑一个浏览器，服务器上的浏览器渲染好的东西，直接输出给客户端的浏览器，那速度肯定快。

参考

摘自某神的片段
Chromium 有很多 Platform Configuration，在 Android 平台上就有两个不同的 Platform Configurations，分别是表现为提供给第三方应用使用的 WebView 组件，和独立应用的 Chrome for Android。

Chrome for Android 跟 Chromium 在其它平台的 Platform Configuration 整体架构比较类似，可以简单认为是一个功能简化版，因为 Chrome for Android 是一个独立的应用，所以它只使用了 Android GUI 框架里面最基础的部分，像窗口系统和事件监听机制。在这些相似的 Platform Configurations 里面，它们的 content’s embedder 就是所谓的 browser。

Android WebView 是一个比较特殊的 Platform Configuration，因为它不是一个独立应用，而是一个供第三方应用使用的组件：

WebView 的行为必须跟一个标准的 Android View 表现一致，这意味这 Chromium Android WebView 这个 Configuration 必须完全对接 Android 基于 View 的 UI 框架和渲染流水线，比如网页的绘制和滚动的处理必须完全由 Android UI 框架来驱动，触屏事件的获取也是通过 View 的接口，绘制的 Output Surface 和 GL 上下文也是由 Android UI 框架来提供；
WebView 本身没有提供完整的书签，历史管理，下载，智能地址/搜索框等功能，但是它需要提供必要的调用和回调接口供第三方应用实现；
原文链接：https://blog.csdn.net/rogeryi/article/details/48179851

1.VasSonic

VasSonic是腾讯VAS团队开发的轻量级高性能Hybrid框架，旨在加速Android和iOS平台网站的首屏。
https://github.com/Tencent/VasSonic

2.CandyWebCache

移动端web资源缓存解决方案，Android端SDK.
https://github.com/NEYouFan/ht-candywebcache-android
CandyWebCache是移动端web资源的本地缓存解决方案，能够拦截webview的请求，并优先使用本地缓存静态资源进行响应，以此来对webview加载页面性能进行优化。

特点：

协议层拦截请求，透明替换响应
静态资源版本控制及更新策略
资源防篡改策略
静态资源自动打包到应用，及首次安装解压处理

3.Android混合开发之——WebView中使用原生组件替换标签元素

http://unclechen.github.io/2017/10/15/Android%E6%B7%B7%E5%90%88%E5%BC%80%E5%8F%91%E4%B9%8BWebView%E4%B8%AD%E4%BD%BF%E7%94%A8%E5%8E%9F%E7%94%9F%E7%BB%84%E4%BB%B6%E6%9B%BF%E6%8D%A2%E6%A0%87%E7%AD%BE%E5%85%83%E7%B4%A0/

4.关于webview体验的一些数字指标

https://www.cnblogs.com/may18/p/12583629.html

5.webview加载html的大概流程

(应用：前端性能监控performance)
https://juejin.cn/post/6844903926496493581

6.今日头条团队极致优化方案

https://mp.weixin.qq.com/s/Xqr6rQBbx7XPoBESEFuXJw

7.WebView 常见 Crash 分析及解决方案

https://xw.qq.com/cmsid/20211110A04YER00

8.手机百度APP的处理方案

https://mp.weixin.qq.com/s/AqQgDB-0dUp2ScLkqxbLZg