WKWebView启动优化

·  阅读 3618

苹果提供的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输入到页面展现到底发生什么?

分类:
iOS
标签:
收藏成功!
已添加到「」, 点击更改