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

代理方案1
此为最早出现的WKWebView请求代理方案，可满足iOS9及以后应用使用（目前最新为iOS14）。根据之前调研分析，业界大部分有代理需求的App采用此方案或变种方案。
1）方案思路
通过WKBrowsingContextController将http(s)注册到Networking的m_registeredSchemes数组中。对于数组中的Scheme ， WebKit在发起请求时会通过WKCustomProtocol将请求发送到App所在的进程，并由App进程来执行发送。
由于从Networking进程将数据发送到App进程时， WebKit内有意剥离了Body部分(见WebCoreArgumentCodersMac.mm)：

文章图片

文章图片
故需要对携带body的请求做一些特殊处理。处理方案是通过在WKWebView内注入脚本，重写掉WebView内请求发送相关方法。在请求发送之前将body部分序列化之后通过bridge传递到App进程暂存。
App进程代理WKWebView请求时，根据规则按需拼接缓存的body ，完成之后再进行发送动作。
2）方案弊端
此方案虽然适用面较广，但是弊端也很明显。主要有两方面：
（1）问题一：无法定向处理、只能一刀切即如果App采用此方案，对其所有WKWebView实例的发送的请求都需要代理。如果有WKWebView实例中并未注入脚本或者执行代理，则可能导致请求无法发送、发送缺少body等问题，常见于一些集成的二方库、三方库中的WKWebView实例。
（2）问题二：重写脚本完备性很难保障由于需要在JS层重写请求发送逻辑，比如form表单提交、AJAX、Fetch等接口，重写接口的质量直接决定方案的完备度。且WKWebView原设计有不少能力在c++层面实现，仅在JS重写无法保证对齐。目前已知的问题有：对于同步请求，此方案目前无法支持。对于流式请求，比如上传场景，目前支持度较差。只能在JS侧全量读取之后再进行发送。无法处理FetchAPIStream返回值。当使用Form表单提交内容包含大块数据时，可能出现丢失、Crash等情况。
代理方案2
此方案是基于苹果在iOS11上开放的[WKWebViewConfigurationsetURLSchemeHandler:forURLScheme:]接口做"扩展"来实现。对于iOS11.3以后的设备，此方案具备较好实用性（WebKit处理了部分Body传递问题）。
1）方案思路[WKWebViewConfigurationsetURLSchemeHandler:forURLScheme:]可以在WKWebView实例上注册自定义请求Scheme 。如果WKWebView发送的请求匹配注册Scheme ，则会代理到UI进程(App进程)执行发送动作。WKWebView内部默认不支持注册http(s)等标准Scheme ，但是有"黑魔法"可绕过限制。对于AJAX发送BLOB数据时，也会出现body丢失的情况，可以参考代理方案1中类似的方案来解决。
2）方案优
代理方案2相对方案1两个巨大的优势在于：不用一刀切，配置与WKWebView实例绑定：即可以定向处理我们需要处理的WKWebView实例，对于三方库中的对象，完全可以做到无影响，安全性大大提高。不用重写所有发送请求：大部分情况下请求中的body是可以被携带到App进程，即我们只需定向处理部分异常即可，健壮性大大提升。
3）方案弊端
此方案除去有iOS11.3的系统版本限制外，在具体运行中也有也有不少很难处理的问题，主要如下：
（1）问题一：多图分片下载情况下， WKWebView内部存在处理时序存在BUG
问题表现：在WKWebView中加载大图、且大图数据存在存在分片返回时， WKWebView内部时序处理异常可能导致图片无法展示、图片展示不完整等问题。具体可结合WebKit中对图片加载的流程来简单说明下：