WKWebView启动优化

yadong
8,054 阅读10分钟

苹果提供的WKWebView使用简单方便，普通需求甚至只需寥寥数行代码便可完成核心功能，为开发者带来了便利。但是在WKWebView的性能改善中，我认为开发者还有很多事情可做。如果你也有这方面的兴趣，不妨来听听我的看法～

WKWebView启动优化.png

1.背景

用户体验
网页的开启速度是用户最直观的体验之一。但网页相对于原生的启动相应速度还是略有差距，所以需要我们开发者继续努力，给到用户更好的体验。

理解问题的本质才能更好的处理问题。所以需要分析WKWebView的启动到底在做什么事情？

2. 分析

我将webView启动分为三个阶段：wkwebView初始化阶段，浏览器网络资源请求阶段，浏览器渲染阶段。接下来我会逐一进行分析。

2.1 WKWebView初始化阶段

从代码上来看，WKWebView的使用是非常简单的：

WKWebView *wkWebView = [[WKWebView alloc] initWithFrame:self.view.bounds configuration:configuration];

初一看确实貌似没什么问题，但是细想却又有点奇怪，为什么会觉得怪？

那就是alloc初始化之后，是否意味着WKWebView已经初始化完成了呢？

我通过以下三点进行了考虑：

  1. WKWebView是在另外一个进程上运行的。
  2. WKWebView是NSObject的子类，通过alloc方法创建之后，实际上就是在我们APP的进程内存中创建了一个WKWebView的结构体而已。
  3. 初始化完成状态应该可用状态，结合第一点考虑，那应该也要初始化一个WKWebView进程。

通过上面三点分析，可以得出结论alloc之后，并不意味着初始化完成。

那经历init方法后，是否意味着WKWebView已经初始化完成了呢？

init构造方法确实还不太好从理论上分析，谁也不知道构造方法里面写入了什么内容，好在WebKit开源，那么就直接从源码上面分析吧！

通过源码分析函数走向为: initWithFrame:(CGRect)frame configuration:(WKWebViewConfiguration *)configuration -> _initializeWithConfiguration:(WKWebViewConfiguration *)configuration;

image2022-1-17_17-33-38.png

核心流程在第二个函数中。直接看看部分代码吧～

image2022-1-17_17-41-48.png

从代码上来看，主要做了如下几件事情：

  1. 设置WKProcessPool
  2. 设置配置信息
  3. 初始化WKContentView并绑定
  4. 生成 WebPageProxy并赋值到configuration
  5. 设置窗口大小与展示模式
  6. 添加一些通知
  7. 添加一些代理

总的来看，都是对WKWebView这个对象进行操作，并未提及到进程初始化。所以可以得出结论，init方法之后，也不意味着初始化完成。
那对于WKWebView操作还有两个方法：loadRequest: 和 addSubView:。首先排除addSubView:，直接分析loadRequest:

分析loadRequest:方法。 通过符号断点抓取函数栈，先看看函数栈。

image2022-1-17_17-45-25.png

源码分析WebPageProxy::loadRequest这个方法到底做了什么？

image2022-1-17_17-45-50.png

看1368和1369两行代码，从字面意思描述的比较清楚了。先判断有没有进程，如果没有进程的话，就初始化一个进程～

那先分析hasRunningProcess里面做了什么事情：

image2022-1-17_17-46-25.png

主要就是通过一个m_hasRunningProcess的标识位，来判断当前的WKWebView有没有开启WKWebView的进程。

接下来看看初始化进程lauchProcess方法里面做了什么吧～

image2022-1-17_17-52-16.png

主要操作如下：

  1. 检查器重置。
  2. 843行-844行。WKWebView进程(后面统称WK进程)移除关联的WKWebView与IPC通信。这一步其实很迷惑，既然是WKWebView中没有WK进程的话，那初始化进程的时候为什么会有移除关联的操作? 这里就引伸出来另一个概念：WK进程复用。也就是当我们APP关闭一个WKWebView之后，WK进程并没有立刻结束，而是会在后台保持一段时间。这其实也很好的说明了一个现象：第二次开启WKWebView要比第一次开启WKWebView初始化耗时更少。
  3. 安全启动WK进程。
  4. WK进程绑定当前的WKWebView以及建立IPC通信。
  5. 注入一些信息。

走到这里也可以盖棺定论了，loadRequest：方法之后，才算初始化完成。那总结下WKWebView初始化都经历了那些事情吧，以一张图来展示。

image2022-1-17_17-54-27.png

2.2 浏览器网络资源请求及渲染阶段

一个网页需要完整的在浏览器展示需要用到三种资源：

  1. HTML/SVG/XHTML，HTML字符串描述了一个页面的结构，浏览器会把HTML结构字符串解析转换DOM树形结构。
  2. CSS，解析CSS会产生CSS规则树，它和DOM结构比较像。
  3. Javascript脚本，等到Javascript 脚本文件加载后， 通过 DOM API 和 CSSOM API 来操作 DOM Tree 和 CSS Rule Tree。

而这些资源都是通过网络请求，或者从本地缓存中读取，只有拿到这些资源后，浏览器才能开始进行渲染的操作。简而言之，获取资源的速度决定了WKWebView启动的速度。

那在什么时机才意味着网络资源请求全部完成呢？

所以我们需要分析浏览器下载资源流程，主要流程为四步：

  1. 浏览器下载HTML，先从本地缓存进行查找，如果本地缓存没有，则发起网络请求。
  2. 获取HTML后，浏览器解析HTML，然后一边构建DOM，一边下载解析到的CSS,JS资源，也会先从本地缓存进行查找，如果本地缓存没有，则发起网络请求。
  3. 结合DOM与CSS生成的CSSOM，生产Render Tree。这一步是和第2步并发执行。
  4. 浏览器根据Render Tree进行渲染。这一步也是并发执行。

用一张图来表示：

image2022-1-17_17-57-12.png

在HTML解析完成，并下载全部的CSS,JS之后，才能够生成完全的Render Tree，此时的浏览器才能完整的渲染出网页内存。那么在此时，我们才认为网络资源请求已经完成。

3. 解决方案

3.1 四个准则与三个方向

分析完流程，接下来的优化也就比较好解决了，解决方案按照下面四个方向进行就好：

  1. 那些事情可以提前做
  2. 那些事情可以一起做
  3. 那些事情可以不用做
  4. 那些事情可以减少做

我会通过三个方向进行调优：

  1. WKWebView初始化阶段
  2. 浏览器资源请求阶段
  3. 浏览器渲染阶段

3.2 webView初始化阶段调优

  1. 预初始化一个WKWebView （提前做）
  2. WKWebView复用池 （减少做）

流程图如下：

image.png

需要注意的点：

  1. WKWebView入池后，需要loadRequest一个空页面，此时才能能算真正启动初始化流程。
  2. WKWebView出池时，只有完成didFinish回调后，才能顺利入池。避免因为delegate而引起其他异常。
  3. 复用的WKWebView的需要清除backForwardList。

3.3 浏览器资源请求阶调优

  1. 网络资源缓存池构建 （减少做）
  2. 资源预下载 （提前做）

需要做到上叙四点，需要解决一个壁垒。WKWebView的网络拦截以及WKWebView的资源管理。之前的文章我已经进行了分享，这个方案的特点是：能够完整的拦截到WKWebView发起的网络请求，并且拦截时机是在访问浏览器缓存之前。通过这两个特点，就能很好的对WKWebView网络阶段进行控制和管理。

3.3.1 网络资源缓存池构建

缓存分为两级：

  1. 强缓存：不会向服务器发起请求，直接从缓存中读取缓存。
  2. 协商缓存：当强缓存失败后，携带缓存标识字段向服务器发起请求，由服务器根据缓存标识字段来决定是否使用缓存。

流程图如下：

构建网页资源缓存池.jpg

3.3.2 资源预下载

通过浏览器网络资源请求的分析，可以得到一个结论：要想知道HTML里面的资源，就得先下载HTML并解析。那除去这种方案，那还有其他方法可以知道HTML里面的资源呢？答案是：前端同学知道。那让前端同学在合适的时机以合适的方式告诉我们就好了。

合适的时机：APP启动60秒之后拉取，以及每10分钟轮询一次。

合适的方式：网页资源表。

资源表结构如下：

image.png

资源分为三个等级：高等级：资源存在资源列表中，且PromptlyDown = 1。高等级资源会在拉取到资源表且为WIFI环境，则立刻下载资源。

中等级：资源存在资源列表中，且PromptlyDown = 0。中等级资源会在拉取到资源表且为WIFI环境且客户端网络有空闲时，则立刻下载资源。

低等级：资源只存在网页列表中。低等级资源只会在打开对应网页时，才会下载资源。
流程图如下：

image.png

3.4 浏览器渲染阶段调优

  1. HTML预解析 （提前做）
  2. WebView启动流程调优：并发进行webView初始化，HTML下载，资源表CSS,JS下载 （一起做）

3.4.1 HTML预解析

通过原理分析，我们已经知道HTML解析主要包括：生成DOM树，以及加载CSS,JS资源。
那么在将要打开网页时，可以通过资源表中的信息，搜寻到HTML所需的CSS,JS资源。此时可以将所需资源从磁盘加载到内存，亦或是发起网络请求，如此即可模拟HTML解析效果。
流程图如下：

image.png

3.4.2 WebView启动流程调优

在webView的整体启动流程中，webView初始化、HTML下载，CSS,JS下载三者是一个串行关系。由于HTML,CSS,JS的下载都不是UI操作，所以可在子线程中进行，那么对于这种串行的流程实际上没有完全利用手机性能，造成了性能浪费。通过上叙的优化后，我们可以对webView初始化，以及网络请求进行控制。那么我们就可以将webView初始化、HTML下载，CSS,JS下载三者调整为并发进行，使得性能尽可能的完全使用。

先来看看浏览器本来的资源加载流程：

image2022-1-17_18-6-47.png

改为并发之后为：

image2022-1-17_18-7-6.png

4.总结

4.1 整体流程

image2022-1-17_18-7-53.png

4.2 方案总结

本文从背景开始讲述，简要说明了WKWebView启动优化的理由。
随后分析了WKWebView初始化原理，浏览器获取资源以及渲染原理，正所谓了解问题的本质才能提出最佳方案。
最后结合四个准则：提前做，一起做，减少做，不要做。以及三个方向：WKWebView初始化，浏览器资源请求，浏览器渲染。逐个给出阶段性的解决方案，大家可以借鉴参考，有更好的想法也欢迎沟通交流。
通过此次需求，我总结了如下心得：

  1. 总结了四个准则。当遇到速度类优化问题时，不妨先想想这四个准则。
  2. 了解问题的本质。充分了解本质，梳理整体流程，方能给出合理方案。
  3. 阶段性优化。目标太远时，不妨分割成多个优化阶段。不要妄想一口吃成大胖子。
  4. 善用缓存。以空间换时间，充分调动设备性能，以此获取更好体验。
  5. 资源表的妙用。除了可以优化启动速度，还可以动态的对资源进行增删改的操作。

相关文章

深入剖析WebKit
深入浅出浏览器渲染原理
深入理解浏览器的缓存机制
从URL输入到页面展现到底发生什么？

avatar
文章
阅读
粉丝