系列文章：
第一坑: WKProcessPool
知識點復習：
看過騰訊Bugly的那篇 《WKWebView 那些坑》,我們知道WKProcessPool可以解決不同的WKWebView 之間共享 Cookie（session Cookie and persistent Cookie）數據, 具體的做法是創建一個單利,來持有WKProcessPool。
場景：在H5中點擊一些鏈接，它是會在當前的webView基礎上，重新創建一個webView來展示的，而不是在當前webView上展示。 具體創建方式就是回調在第二章中執行WKUIDelegate的代理方法。
解決這一個問題的方式，具體代碼如下:
WKWebViewConfiguration * webConfiguration = [[WKWebViewConfiguration alloc]init];
webConfiguration.processPool = [LLWKProcessPoolUtil sharedInstance].wkProcessPool;
@interface LLWKProcessPoolUtil : NSObject
+ (LLWKProcessPoolUtil *)sharedInstance;
/// WKProcessPool
@property (nonatomic, strong) WKProcessPool *wkProcessPool;
/// 銷毀wkProcessPool單例屬性
- (void)destroyInstance;
@end
#import "LLWKProcessPoolUtil.h"
@implementation LLWKProcessPoolUtil
+ (LLWKProcessPoolUtil *)sharedInstance
{
static dispatch_once_t once;
static YCWKProcessPoolUtil * __singleton__;
dispatch_once( &once, ^{
__singleton__ = [[LLWKProcessPoolUtil alloc] init];
});
return __singleton__;
}
#pragma mark - 不同webView中的Cookie
static WKProcessPool *__singlePool__ = nil;
static dispatch_once_t onceTokenPool;
- (WKProcessPool *)wkProcessPool
{
dispatch_once( &onceTokenPool, ^{
__singlePool__ = [[WKProcessPool alloc] init];
});
return __singlePool__;
}
- (void)destroyInstance
{
onceTokenPool = 0;
__singlePool__ =nil;
}
@end
遇到的坑：
這樣雖然可以解決創新創建的WKWebView的cookie訪問問題，但是因為是單利持有的，當我們切換用戶登錄之后，webView會出現帶有上一個用戶Cookie的問題，這對于設計到積分和金錢的業務就很麻煩了，H5以為是上一個用戶登錄的。 解決方法， 切換登錄的時候，將單利持有的proceressPool銷毀掉，代碼如下:
[LLWKProcessPoolUtil destroyInstance];
但是這樣，我們會有另外一個問題，發生在iOS8~iOS10，proceressPool銷毀之后進入再次進入webView進行登錄，按照我們第四章中的Cookie策略，Cookie死活沒有了。 比如得重新重新走一遍創建WKWebView，然后請求url的步驟才能生效。 好吧，原因是這個時候，document.Cookie也隨之丟失了。
解決辦法：
解決方法，你也想到了，重新給document.Cookie賦值。
第二坑：User Agent
知識點復習：
我們加User Agent，就是方便H5后臺知道，這個H5頁面是從咱公司APP進去的。方便識別來源，做大數據和廣告數據統計。
遇到的坑：
之前的寫法，是直接股改webView原生的User Agent。后來上線過程中，遇到一個廣告客戶的H5鏈接怎么都打不開，一直在重定向循環。
但是我們新建一個純凈WKWebView是可以正常打開的。經過仔細排查，才發現是User Agent的鍋。有些H5的后臺是根據設備瀏覽器上傳的User Agent來判斷設備的webView是否安全或者是否可以讓該webView打開網頁。很顯然，他們是根據webView原生的來判定的。
解決辦法：
設置的時候不要覆蓋手機原生User Agent， 我們要把我們自己公司的自定義User Agent字段追加到原生后邊。也就是『原生User-Agent + 我們自己的User Agent』。比如：
Mozilla/5.0 (iPhone; CPU iPhone OS 12_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/16B91 LiLong=123445 LiLongBBB=Baidu
第三坑：后臺H5頁面不支持https://
遇到的坑：
最新測試反饋一個H5頁面有問題, 具體是在iOS上某些點擊不跳轉. 開始以為是webView的問題, 新建項目加載這個鏈接也有問題. 并且在mac電腦的瀏覽器上也有相同問題. 但是同事打開就沒問題. 奇怪了. 都是mac電腦, 都是一個瀏覽器. 難道是鏈接的鍋? 后來發現還真是, 我這邊加載的"https://xxxxxxxx", 同事加載的是"http://xxxxxxxx". "https://xxxxxxxx"這個有問題.
解決辦法：
通知H5, iOS加載"http://xxxxxxxx"
第四坑：Request Header中寫入自定義Host導致請求個別網頁失敗
遇到的坑：
上一個離職的同事在寫webView請求的時，手動在Request Header中設置了一次Host，這么做的原因不太清楚，可能是因為服務器識別請求來源。之后很長時間里也沒有問題，但是前段時間有一天請求某個webView總是白屏，經過排除法，最終確定是因為重寫了Host。代碼中設置Host的方法是這樣的：
[request addValue:request.URL.host forHTTPHeaderField:@"Host"];
解決辦法：
不手動在Request Header設置了一遍Host，刪除這一行代碼。
交流
希望能和大家交流技術
Blog:http://www.lilongcnc.cc
