前言：知識體系的快速建立總是需要踩在前人的肩膀上锤窑，很感謝有分享精神的開發(fā)者蜕青，只有分享才能讓知識快速傳播瘟栖，才能推動技術(shù)更快發(fā)展。
UIWebview中對請求進(jìn)行攔截蜡豹，我們的做法是注冊一個自定義的NSURLProtocol子類麸粮，然后在子類中對請求追加一些額外操作。
而在WKWebview中镜廉，我們注冊一個自定義的protol類后弄诲，除了一開始的時候會調(diào)用+ [NSURLProtocol canInitWithRequest:] 方法，之后的整個請求就與NSURLProtocol無關(guān)了桨吊。難道真是WKWebview不支持NSURLProtocol了嗎威根？
經(jīng)過查證凤巨，有前人已經(jīng)做了一番探索视乐，并給出來答案。下面詳細(xì)講一下：
1敢茁、在webkit的源碼中：Apple在單元測試TestProrocol.mm中用到了NSURLProtocol 佑淀，注冊了一個自定義的protocol。代碼如下：
+ (void)registerWithScheme:(NSString *)scheme
{
testScheme = [scheme retain];
[NSURLProtocol registerClass:[self class]];//這里還是注冊了自定義的urlProtocol
#if WK_API_ENABLED
[WKBrowsingContextController registerSchemeForCustomProtocol:testScheme]; //而且為自定義的protocol這里綁定了scheme
#endif
}
從上面的代碼中我們可以看到：在WKBrowsingContextController中通過registerSchemeForCustomProtocol :注冊了一個scheme彰檬，而這個scheme很有可能是用來同WKWebview中請求URL的scheme做匹配的伸刃，只有匹配成功，才會執(zhí)行去執(zhí)行自定義的URLProtocol逢倍。
至于為什么要做這種匹配捧颅，有人給出的答案是：因為WKWebview是通過Webkit的IPC消息分發(fā)機(jī)制來進(jìn)行進(jìn)程間通信的，IPC的代價還是很大的较雕。我們可以斷點看一下堆棧碉哑。
2挚币、我們仿照測試用例代碼進(jìn)行改造：
Class cls = NSClassFromString(@"WKBrowsingContextController");
SEL sel = NSSelectorFromString(@"registerSchemeForCustomProtocol:");
if([cls respondsToSelector:sel]) {
//這里我們只需要匹配http和https的scheme
[cls performSelector:sel withObject:@"http"];
[cls performSelector:sel withObject:@"https"];
}
果然注冊后我們自定義的URLProtocol就可以被執(zhí)行到。（js 執(zhí)行的網(wǎng)絡(luò)請求應(yīng)該還是不會被攔截到）
3扣典、避免Apple檢查到使用私有API
這里WKBrowsingContextController和registerSchemeForCustomProtocol:很明顯是兩個私有的類和方法妆毕。如果直接用可能會違反蘋果的審核原則。
這里作者提到sunny關(guān)于Apple檢測是否使用私有API的一些總結(jié)：
1贮尖、是否 link 了私有 framework 或者公開 framework 中的私有符號笛粘，這可以防止開發(fā)者把私有 header 都 dump 出來供程序直接調(diào)用。
2湿硝、同上薪前，使用@selector(_private_sel)加上-performSelector:的方式直接調(diào)用私有 API。
3图柏、掃描所有符號序六，查看是否有繼承自私有類，重載私有方法蚤吹，方法名是否有重合例诀。
4、掃描所有string裁着，看字符串常量段是否出現(xiàn)和私有 API 對應(yīng)的繁涂。
針對改造用到的兩處私有API，原作者分別提供了解決方法：
1二驰、WKBrowsingContextController：
這個私有類的獲取通過KVC方式扔罪，獲取一個沒有入?yún)⒌膕elector的返回值。這里的selector是： - browsingContextController , 定義在WKWebview.h的中桶雀。
Class cls = [[[WKWebView new] valueForKey:@"browsingContextController"] class];
這里有兩點讓人欽佩：（文末會附上連接）
（1）使用kvc來獲取無入?yún)⒌膕elector的返回值矿酵。
（2）WKWebview runtime的源碼原作能夠去讀，很不容易矗积。這里是iOS10的runtime 源碼全肮，11上也可驗證。
2棘捣、registerSchemeForCustomProtocol：這個私有API辜腺，則是通過NSSelectorFromString:方式來獲得。
return NSSelectorFromString(@"registerSchemeForCustomProtocol:");
至此乍恐，關(guān)于WKWebview支持NSURLProtocol的改造可以說已經(jīng)完成评疗。還是那句話：源碼面前了無秘密。
既然已經(jīng)跟到了這里茵烈，還是稍微了解了下webkit的大體結(jié)構(gòu)：但是不做深究：感興趣可以參考源碼和以下博客：webkit2解析
這種解決方法的兩個不足：（來源騰訊bugly）
1百匆、post請求body數(shù)據(jù)被清空。
NSURLProtocol不被執(zhí)行原因：WKWebview是在獨立的進(jìn)程中進(jìn)行網(wǎng)絡(luò)請求呜投。請求數(shù)據(jù)不經(jīng)過app主進(jìn)程加匈，因此在WKWebview上使用注冊的NSURLProtocol寄症，也無法攔截請求。
body被清掉原因：webkit2中使用MessageQueue進(jìn)行進(jìn)程間通信矩动，會把網(wǎng)絡(luò)請求encode成一個message有巧，通過IPC發(fā)送給App process進(jìn)程。出于性能的原因悲没，encode 的時候 HTTPBody 和 HTTPBodyStream 這兩個字段被丟棄掉了
2篮迎、在 WKWebView 上通過 loadRequest 發(fā)起的 post 請求 body 數(shù)據(jù)會丟失的問題也是由于這個原因
針對這個問題我們的思路是：
1、替換url 的scheme ,修改為自定義的scheme示姿。例如：sinaCustomScheme://www.sina.com.cn
2甜橱、根據(jù)新生成的url，創(chuàng)建一個新的request栈戳，并將body數(shù)據(jù)存放到請求頭中岂傲。
3、通過上面的方式注冊自定義的scheme子檀。
4镊掖、在自定義的NSURLProtocol中，將url的scheme替換為原來的scheme褂痰。即：http://www.sina.com.cn亩进，并從requestHeader中取出body，并使用NSURLSession發(fā)起新的網(wǎng)絡(luò)請求缩歪。
3归薛、對ATS支持不好。
測試發(fā)現(xiàn)一旦打開ATS開關(guān)：Allow Arbitrary Loads 選項設(shè)置為NO匪蝙，同時通過 registerSchemeForCustomProtocol 注冊了 http(s) scheme主籍，WKWebView 發(fā)起的所有 http 網(wǎng)絡(luò)請求將被阻塞（即便將Allow Arbitrary Loads in Web Content 選項設(shè)置為YES）；
參閱：
webkit探究
wkwebview探究
