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

文章图片

文章图片
问题即出现在上述step1,step2,step3的执行顺序上。在异常情况下，会偶现执行顺序为：step1->step3->step2,且step3不再被触发（allDataReceived），进而导致图片最终的内容未渲染上屏。
解决方案：目前暂无有效的解决办法，通过配置suppressesIncrementalRendering配置为YES某种程度上可以缓解问题，但并无法根治且对体验略有影响。
（2）问题二：iOS12及以下系统系统同步AJAX导致Crash
问题表现：在WKWebView中如果出现Web页面发送syncrequest ，则可导致WebContent进程崩溃， WKWebView回调webViewWebContentProcessDidTerminate ，进而导致页面白屏等问题。此问题可明确是WebKit内部的BUG ，且已有相关Fix：
处理方案：对于Bug1 ，处理相对比较简答，即在网络请求回调error之前优先回调部分空数据，规避掉问题；但是对于Bug2 ，目前缺少有效的解决办法。
（3）问题三：301请求下SWAP导致页面无法转场问题
问题表现：如果页面中存在使用301做重定向的情况，可能会出现重定向页面无法加载的情况，进而导致页面异常、白屏等问题。
处理方案：关闭processSwapsOnNavigation ，将置为NO（内部属性）。
总的来说，虽然代理方案2相比代理方案1有很大的优势，但此方案因为版本限制等原因，目前使用量相比代理方案1略低。且与代理方案1相比，此方案的优势和劣势都很明显，如多图分片场景下可能导致图片无法展示的问题，目前未找到有效的解决办法。方案2是否可替代方案1在生产环境使用，还需使用同学自己斟酌。
2Cookie问题
根据官方文档及资料，我们可知WKWebView因为其"独立存储" ，导致Cookie和Cache与App不互通，进而有问题。但是这种表述较为模糊，且实际使用中WKWebView与App的Cookie并非完全隔离，这种模棱两可的表现很难让人搞清楚"通"或"不通"的边界在哪里。
下面首先根据自己对这块的理解，尝试说明下WKWebView使用Cookie问题到底是什么、以及背后的原因。由于苹果并未对全部代码开源，下有不少内容是自己的理解和推断，无法保证完全正确，仅介绍部分思路和判断，供大家在需要时参考。
Cookie管理策略
根据上节的背景介绍我们可知， iOSCookie相关内容，是在CFNetwork这一层由CFHTTPCookie、CFHTTPCookieStorage等来管理，是CFNetwork模块的一部分。且对于SessionCookie和持久化Cookie ，系统有着不同的管理策略：SessionCookie：内存中保存，进程周期内生效。在iOS移动端，一个App进程即对应于一个Session ，即SessionCookie可在进程内共享。持久化Cookie：这部分Cookie除保存内存以外，还会持久化到磁盘，可多次使用。本地文件存储在沙箱文件夹/Library/Cookies/Cookies.binarycookies；需要特别注意的是：持久化Cookie并非在产生之后立即同步到Cookies.binarycookies ，根据经验会有一个300ms~3s的延迟。
WKWebViewCookie问题
基于上节的iOSCookie管理、结合多进程模型，我们大概可以推断App与WKWebViewCookie管理模型，见如下简图：

文章图片

文章图片
注意：WKHTTPCookieStore为示意，画到了Networking进程，实际情况中此模块分散在WebContent、Networking以及UIProcess中，且各进程中的部分通过IPC桥接。
根据上图可以引导出WKWebViewCookie相关的2个核心点：
1）WKWebViewCookie问题具体是什么对于"SessionCookie"：App进程与WKWebView进程（WebContent+Networking）之间完全隔离。对于"持久化Cookie"：App进程与WKWebView进程（WebContent+Networking）之间同步存在时差。