系列文章：
- 《37- WKWebView項(xiàng)目實(shí)踐分享（一）- UIWebView回顧介紹》
- 《43- WKWebView項(xiàng)目實(shí)踐分享（二）- WKWebView介紹》
- 《38- WKWebView項(xiàng)目實(shí)踐分享（三）- native和webView交互》
- 《39- WKWebView項(xiàng)目實(shí)踐分享（四） - 先了解下Cookie》
- 《40- WKWebView項(xiàng)目實(shí)踐分享（五）- WKWebView如何加Cookie》
- 《41- WKWebView項(xiàng)目實(shí)踐分享（六）- 項(xiàng)目實(shí)踐：User Agent瞬雹、跨域、重定向及其它》
第一坑: WKProcessPool
知識(shí)點(diǎn)復(fù)習(xí)：
看過騰訊Bugly的那篇 《WKWebView 那些坑》,我們知道WKProcessPool可以解決不同的WKWebView 之間共享 Cookie（session Cookie and persistent Cookie）數(shù)據(jù), 具體的做法是創(chuàng)建一個(gè)單利,來(lái)持有WKProcessPool。
場(chǎng)景：在H5中點(diǎn)擊一些鏈接鹰祸，它是會(huì)在當(dāng)前的webView基礎(chǔ)上稚疹，重新創(chuàng)建一個(gè)webView來(lái)展示的，而不是在當(dāng)前webView上展示垂蜗。 具體創(chuàng)建方式就是回調(diào)在第二章中執(zhí)行WKUIDelegate的代理方法钾恢。
解決這一個(gè)問題的方式，具體代碼如下:
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
遇到的坑：
這樣雖然可以解決創(chuàng)新創(chuàng)建的WKWebView的cookie訪問問題滴铅，但是因?yàn)槭菃卫钟械模?dāng)我們切換用戶登錄之后就乓，webView會(huì)出現(xiàn)帶有上一個(gè)用戶Cookie的問題汉匙，這對(duì)于設(shè)計(jì)到積分和金錢的業(yè)務(wù)就很麻煩了拱烁，H5以為是上一個(gè)用戶登錄的。 解決方法噩翠， 切換登錄的時(shí)候戏自，將單利持有的proceressPool銷毀掉，代碼如下:
[LLWKProcessPoolUtil destroyInstance];
但是這樣伤锚，我們會(huì)有另外一個(gè)問題擅笔，發(fā)生在iOS8~iOS10，proceressPool銷毀之后進(jìn)入再次進(jìn)入webView進(jìn)行登錄屯援，按照我們第四章中的Cookie策略猛们，Cookie死活沒有了。 比如得重新重新走一遍創(chuàng)建WKWebView狞洋，然后請(qǐng)求url的步驟才能生效弯淘。 好吧，原因是這個(gè)時(shí)候吉懊，document.Cookie也隨之丟失了庐橙。
解決辦法：
解決方法，你也想到了借嗽，重新給document.Cookie賦值态鳖。
第二坑：User Agent
知識(shí)點(diǎn)復(fù)習(xí)：
我們加User Agent，就是方便H5后臺(tái)知道恶导，這個(gè)H5頁(yè)面是從咱公司APP進(jìn)去的郁惜。方便識(shí)別來(lái)源，做大數(shù)據(jù)和廣告數(shù)據(jù)統(tǒng)計(jì)甲锡。
遇到的坑：
之前的寫法兆蕉，是直接股改webView原生的User Agent。后來(lái)上線過程中缤沦，遇到一個(gè)廣告客戶的H5鏈接怎么都打不開虎韵，一直在重定向循環(huán)。
但是我們新建一個(gè)純凈WKWebView是可以正常打開的缸废。經(jīng)過仔細(xì)排查包蓝，才發(fā)現(xiàn)是User Agent的鍋。有些H5的后臺(tái)是根據(jù)設(shè)備瀏覽器上傳的User Agent來(lái)判斷設(shè)備的webView是否安全或者是否可以讓該webView打開網(wǎng)頁(yè)企量。很顯然测萎，他們是根據(jù)webView原生的來(lái)判定的。
解決辦法：
設(shè)置的時(shí)候不要覆蓋手機(jī)原生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
第三坑：后臺(tái)H5頁(yè)面不支持https://
遇到的坑：
最新測(cè)試反饋一個(gè)H5頁(yè)面有問題, 具體是在iOS上某些點(diǎn)擊不跳轉(zhuǎn). 開始以為是webView的問題, 新建項(xiàng)目加載這個(gè)鏈接也有問題. 并且在mac電腦的瀏覽器上也有相同問題. 但是同事打開就沒問題. 奇怪了. 都是mac電腦, 都是一個(gè)瀏覽器. 難道是鏈接的鍋? 后來(lái)發(fā)現(xiàn)還真是, 我這邊加載的"https://xxxxxxxx", 同事加載的是"http://xxxxxxxx". "https://xxxxxxxx"這個(gè)有問題.
解決辦法：
通知H5, iOS加載"http://xxxxxxxx"
第四坑：Request Header中寫入自定義Host導(dǎo)致請(qǐng)求個(gè)別網(wǎng)頁(yè)失敗
遇到的坑：
上一個(gè)離職的同事在寫webView請(qǐng)求的時(shí)恕汇，手動(dòng)在Request Header中設(shè)置了一次Host腕唧，這么做的原因不太清楚或辖，可能是因?yàn)榉?wù)器識(shí)別請(qǐng)求來(lái)源。之后很長(zhǎng)時(shí)間里也沒有問題枣接，但是前段時(shí)間有一天請(qǐng)求某個(gè)webView總是白屏颂暇，經(jīng)過排除法，最終確定是因?yàn)橹貙懥?code>Host但惶。代碼中設(shè)置Host的方法是這樣的：
[request addValue:request.URL.host forHTTPHeaderField:@"Host"];
解決辦法：
不手動(dòng)在Request Header設(shè)置了一遍Host耳鸯，刪除這一行代碼。
交流
希望能和大家交流技術(shù)
Blog:http://www.lilongcnc.cc
