iOS 端容器之 WKWebView 那些事熟悉iOS\macOSHybrid混合开发的同

熟悉iOS\macOSHybrid混合开发的同学应该都有体会， WKWebView虽然是苹果作为替代UIWebView\WebView而推出的"新"组件，但大部分开发者对它实在“爱不起来” 。毕竟对于国内大部分应用开发者来说，在实际使用中WKWebView所谓的“优势”未必能体现出来，但带来的“坑”却都着实都不浅。
目前社区或线上可查找的WKWebView相关资料，大多比较陈旧且人云亦云、复制粘贴类的居多。少部分真实实践和探索的开发者，或许也因时间或精力的原因，对问题和解决方案未能做详细的阐述。导致目前线上WKWebView相关的资料数量不少、但质量不高；且有不少文章存在对问题的背景解释不清，解决方案缺乏有效验证等问题。
我从事端容器领域开发多年，曾在生产环境方案设计上与WKWebView"对抗"多次。目前混合开发已经是现代App标配，一方面是对这么长时间用法经验上的总结，另外一方面也希望能够为还在抗争中的同学提供一些新视角或者解决思路，故准备结合WebKit部分源码，将自己对这个组件的理解以及部分问题解决方案整理分享一下。本文尝试说明3件事情：WKWebView使用中的典型问题有哪些为什么会出现这些问题这些问题的解决办法有哪些
iOS端网络设计和WKWebView设计特点我们可以通过官方资料来查阅。但为了后面更好的说明问题，下面我们重点回顾下与文章后续内容相关的两个基本知识点：iOS端网络设计与Cookie管理WKWebView多进程模型
1iOS网络设计与Cookie管理
Cookie管理是做混合开发过程中经常会涉及到的部分，在应用开发中我们知道可以通过NSHTTPCookie和NSHTTPCookieStorage来管理应用的Cookie 。但在系统层面Cookie是如何管理的、如何与网络层各模块进行联动，这对我们后面分析WKWebView中的Cookie问题有着至关重要的联系。
根据官方资料，我们可知iOS平台下网络相关模块大概关系如下：

文章图片

文章图片
从上至下模块依次为：WebKit：应用层，客户端App以及WKWebView处于这一层。NSURL：可以理解为对底层CF接口的封装扩展层， NSURLConnection、NSURLSession等处于这一层。CFNetwork：iOS网络模块核心实现层，是网络层设计中最重要的部分。负责网络协议组装发送接收等主要工作，与CoreFoundation框架关系紧密。BSDsocket：基于底层硬件接口的socket服务。
CFNetwork是整个网络系统的核心模块，负责组装请求、处理响应等：

文章图片

文章图片
核心内容包含：CFURLRequest：包括URL/header/body这些请求的信息。CFURLRequest会进一步转换成CFHTTPMessage 。CFHTTPMessage：主要是HTTP协议的定义和转换，把每一个请求request转换成标准的HTTP格式的文本。CFURLConnection：主要是处理请求任务。包括pthread线程、CFRunloop、请求队列的管理等等。提供了start、cancel等等操作的API 。CFHost：负责DNS ，有CFHostStartInfoResolution等函数，基于dns_async_start和getaddrinfo_async_start等方法。CFURLCache/CFURLCredential/CFHTTPCookie：处理缓存/证书/cookie相关的逻辑，都有对应的NS类。
从上面分析可知关键信息：iOSCookie管理相关模块处于CFNetwork这一层中。即对于请求Response中的"set-cookie"字段，在CFNetwork中被消费和处理。
2WKWebView多进程模型
通过官方资料，我们知道WKWebView相比UIWebView很大的一个变化是"多进程模型"：
WKWebView使各种问题的原因，有不少和多进程运行模式有很大的关系。
多进程模型详解