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

但具体是什么样形态的多进程？我们通过一张简图来说明下:

文章图片

文章图片
WKWebView(WebKit)包含3种进程：UIProcess,NetworkingProcess,WebContentProcess 。UIProcess：即App进程， WKWebView(WebKit)中部分模块运行在此进程，会负责启动其它进程。NetworkingProcess：即网络模块进程，主要负责WKWebView中网络请求相关功能；此进程App中只会有启动一次，多个WKWebView间共享。WebContentProcess：即Web模块进程，主要负责WebCore,JSCore相关模块的运行，是WKWebView的核心进程。此进程在App中会启动多次，每个WKWebView会有自己独立的WebContent进程。各个进程之间通过CoreIPC进程通信。
总的来说：在一个客户端App中，多个WKWebView使用中会共享一个UI进程(与App进程共享)、共享一个Networking进程、每个WKWebView实例独享一个WebContent进程。
示例：

文章图片

文章图片
此处关于WebContentProcess和NetworkingProcess的启动规则，官方文档并未解释特别清楚，且因为版本迭代等原因，文档与目前最新规则也略有出入。为避免混淆与歧义，下面结合WebKit源码稍作分析。
WebContent进程启动规则
根据官方文档描述：
规则是优先使用创建新进程，当进程上线超过某阈值之后则会共享，在WebKit内部由maximumProcessCount控制。但是此规则只对iOS13之前的系统生效， iOS13之后的系统， WKWebView每次创建实例都会启动一个新的WebContentPorcess 。相关实现如下。
iOS13前：

文章图片

文章图片

文章图片

文章图片
iOS13及以后：

文章图片

文章图片
Networking进程启动规则
Networking规则相对简单，确保在App生命周期内启动一例(Crash之后会重新创建) 。相关代码：

文章图片

文章图片
WKWebView在生产环境使用中，除去相对简单的使用和适配问题外，容易对开发者和前端同学造成困扰的问题有4个：请求代理问题Cookie管理问题全面屏适配问题WebContent进程崩溃问题
下面分别对这4例问题产生的原因、可尝试的解决方案以及不同方案下引入的问题做一下说明。
1请求代理问题
这一点应该是阻碍WKWebView铺开的首要问题。问题背景也相对简单，并非有什么技术实现上的难度，而是苹果官方不希望WKWebView请求被应用拦截，美其名曰"为了安全" 。但在实际使用场景中，我们又需要对WebView的请求进行代理以满足业务和性能诉求，典型场景如：离线包、流量监控等。
官方不支持、业务上又有使用场景，我们只能尝试通过"黑魔法"来解决。目前适用面比较多的解决方案有两个：通过[WKBrowsingContextControllerregisterSchemeForCustomProtocol:]来注册代理，为方便简称为代理方案1 。通过[WKWebViewConfigurationsetURLSchemeHandler:forURLScheme:]来注册，为方便简称为代理方案2 。
目前两种解决方案的实现方法都有较为丰富的资料和说明，在此不在赘述。
虽然这两种方案某种程度上可以"部分解决问题" ，但带来的副作用相对也不少，在生产环境中如何取舍还需具体开发同学来取舍。下面分别通过"代理方案1"和"代理方案2"代指来简单说明下，可以供大家选型时做一个参考。