苹果供给的WKWebView运用简单方便，普通需求甚至只需寥寥数行代码便可完结中心功用，为开发者带来了便当。但是在WKWebView的功能改善中，我认为开发者还有许多工作可做。假如你也有这方面的爱好，无妨来听听我的看法～

WKWebView启动优化

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;

WKWebView启动优化

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

WKWebView启动优化

从代码上来看，首要做了如下几件工作：

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

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

剖析loadRequest:办法。 经过符号断点抓取函数栈，先看看函数栈。

WKWebView启动优化

源码剖析WebPageProxy::loadRequest这个办法究竟做了什么？

WKWebView启动优化

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

那先剖析hasRunningProcess里边做了什么工作：

WKWebView启动优化

首要便是经过一个m_hasRunningProcess的标识位，来判别当前的WKWebView有没有敞开WKWebView的进程。

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

WKWebView启动优化

首要操作如下：

  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初始化都阅历了那些工作吧，以一张图来展现。

WKWebView启动优化

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进行烘托。这一步也是并发执行。

用一张图来表示：

WKWebView启动优化

在HTML解析完结，并下载悉数的CSS,JS之后，才干够生成彻底的Render Tree，此刻的浏览器才干完好的烘托出网页内存。那么在此刻，咱们才认为网络资源恳求现已完结。

3. 解决计划

3.1 四个原则与三个方向

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

  1. 那些工作能够提早做
  2. 那些工作能够一同做
  3. 那些工作能够不用做
  4. 那些工作能够削减做

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

  1. WKWebView初始化阶段
  2. 浏览器资源恳求阶段
  3. 浏览器烘托阶段

3.2 webView初始化阶段调优

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

流程图如下：

WKWebView启动优化

需求留意的点：

  1. WKWebView入池后，需求loadRequest一个空页面，此刻才干能算真实发动初始化流程。
  2. WKWebView出池时，只要完结didFinish回调后，才干顺畅入池。防止因为delegate而引起其他反常。
  3. 复用的WKWebView的需求铲除backForwardList。

3.3 浏览器资源恳求阶调优

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

需求做到上叙四点，需求解决一个壁垒。WKWebView的网络阻拦以及WKWebView的资源管理。之前的文章我现已进行了共享，这个计划的特色是：能够完好的阻拦到WKWebView建议的网络恳求，并且阻拦时机是在访问浏览器缓存之前。经过这两个特色，就能很好的对WKWebView网络阶段进行操控和管理。

3.3.1 网络资源缓存池构建

缓存分为两级：

  1. 强缓存：不会向服务器建议恳求，直接从缓存中读取缓存。
  2. 协商缓存：当强缓存失败后，携带缓存标识字段向服务器建议恳求，由服务器依据缓存标识字段来决议是否运用缓存。

流程图如下：

WKWebView启动优化

3.3.2 资源预下载

经过浏览器网络资源恳求的剖析，能够得到一个结论：要想知道HTML里边的资源，就得先下载HTML并解析。那除掉这种计划，那还有其他办法能够知道HTML里边的资源呢？答案是：前端同学知道。那让前端同学在适宜的时机以适宜的方法告知咱们就好了。

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

适宜的方法：网页资源表。

资源表结构如下：

WKWebView启动优化

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

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

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

WKWebView启动优化

3.4 浏览器烘托阶段调优

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

3.4.1 HTML预解析

经过原理剖析，咱们现已知道HTML解析首要包括：生成DOM树，以及加载CSS,JS资源。
那么在将要翻开网页时，能够经过资源表中的信息，搜寻到HTML所需的CSS,JS资源。此刻能够将所需资源从磁盘加载到内存，亦或是建议网络恳求，如此即可模拟HTML解析作用。
流程图如下：

WKWebView启动优化

3.4.2 WebView发动流程调优

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

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

WKWebView启动优化

改为并发之后为：

WKWebView启动优化

4.总结

4.1 全体流程

WKWebView启动优化

4.2 计划总结

本文从背景开端叙述，扼要说明晰WKWebView发动优化的理由。
随后剖析了WKWebView初始化原理，浏览器获取资源以及烘托原理，正所谓了解问题的实质才干提出最佳计划。
最后结合四个原则：提早做，一同做，削减做，不要做。以及三个方向：WKWebView初始化，浏览器资源恳求，浏览器烘托。逐一给出阶段性的解决计划，大家能够学习参考，有更好的主意也欢迎沟通交流。
经过此次需求，我总结了如下心得：

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

相关文章

深化剖析WebKit
浅显易懂浏览器烘托原理
深化理解浏览器的缓存机制
从URL输入到页面展现究竟发生什么？