WKWebView不支持NSURLProtocol
前段時間總結(jié)過《WKWebView從入門到趟坑》，其中提到 NSURLProtocol 攔截支持和緩存的痛點。在 UIWebView 時代，按照下面的方式注冊一個自定義的 NSURLProtocol 和 CustomURLCache 的子類，
// 注冊url攔截
[NSURLProtocol registerClass:[CustomURLProtocol class]];
// 注冊緩存加載
[NSURLCache setSharedURLCache:[CustomURLCache new]];
然后就可以在其實現(xiàn)中對 app 內(nèi)所有的網(wǎng)絡(luò)請求進行攔截，并加載本地的離線資源（很多 Hybird 框架都是基于此原理）。但在 WKWebView 中的請求卻完全不遵從這一規(guī)則，網(wǎng)絡(luò)上文章一般都解釋說 WKWebView 的請求是在單獨的進程里，所以不走 NSURLProtocol。
斷點調(diào)用棧也顯示 WKWebView 在加載 page 時候的確使用的是 WebKit 的 IPC 消息收發(fā)/分發(fā)機制 MessageQueue 進行進程之間的通信，但也發(fā)現(xiàn)它竟然調(diào)用到了
+ [NSURLProtocol canInitWithRequest:]
之后的流程就不在執(zhí)行 NSURLProtocol 相關(guān)的方法了，既然調(diào)用了一個 canInitWithRequest，至少說明 WKWebView 還是引用了 NSURLProtocol 類或其子類，只是不知道什么原因沒有實現(xiàn)其他調(diào)用（很多人都評論 WKWebView 是未開發(fā)完善的半成品）。
好在 WKWebView 的內(nèi)核是基于開源的 WebKit，讓好奇地開發(fā)者們能夠翻看源碼一探究竟，傳送門。在一個測試用例下 AlwaysRevalidatedURLSchemes.mm，看到了熟悉的 WKWebView 加載流程代碼，如下圖：
注意紅色標記處，正是 UIWebView 時代 NSURLProtocol 攔截方式，可見源碼上 WKWebView 似乎是支持 NSURLProtocol 的，在 WebKit.framework 中并沒有 WKBrowsingContextController 的身影，說明這是個未開放的類，它到底是個什么鬼呢？猜測它可能與 NSURLProtocol 有關(guān)。
WebKit 源碼淺析
眾所周知，WebKit 源碼由三大部分組成：
WebCore：HTML 排版引擎核心，主要包含 Loader，Parser(DOM，Render)，Layout，Paint等模塊
WebKit：移植層，主要包括 GUI，F(xiàn)ile System，Thread，圖片解碼等與平臺相關(guān)的模塊
JavaScriptCore：JS 虛擬機，主要用于操作 DOM，解析執(zhí)行 JavaScript 代碼
其源碼架構(gòu)如下：
與 WebKit.framework 相關(guān)的源碼腦圖如下：
紅色標記處即蘋果并未開放出來的接口類，其中：
1、WKScrollView 負責 Page 的一些滑動，手勢操作等。
2、WebContenView 負責 Page 的渲染。
3、WKBrowsingContextController 負責瀏覽器的交互處理，提供了一些通用的操作，如加載，前進，后退，刷新等。
4、WKBrowsingContextControllerHandel 提供可擴展的操作的抽象，插件化實現(xiàn)各種瀏覽器功能。
5、WebPageProxy 是 WebKit 的 Page 代理，實現(xiàn) UI Process 層和 Web Process 層的接口。
6、WebProcessPool 通過讓所有 WKWebView 共享同一個 WKProcessPool 實例，可以實現(xiàn)多個 WKWebView 之間共享數(shù)據(jù)。不過 WKProcessPool 實例在 app 殺進程重啟后會被重置，無法實現(xiàn)本地化保存。
參考博文中提到的：
http://blog.csdn.net/horkychen/article/details/8589449
可以很清楚地了解 WKView（WKWebView 是其在 iOS 平臺的一個實例）在 WebKit 中的初始化流程：
1、根據(jù)配置項 WKWebViewConfiguration 創(chuàng)建新 WKWebView，同時會初始化 WKScrollView 和 WKContentView；
2、WKContentView 從進程池 WKProcessPool 中分配 WebProcessProxy 和 WebPageProxy，同時根據(jù)當前 Page 初始化 WKBrowsingContextController，提供了大部分交互操作功能；
3、WKWebView 在獨立于 App Process 進程之外的 Network Process 進程中執(zhí)行網(wǎng)絡(luò)請求，請求數(shù)據(jù)不經(jīng)過主進程，因此，在 WKWebView 上直接使用 NSURLProtocol 無法攔截請求。
其中有兩個方法是前面測試用例中見到的：
可見內(nèi)部對全局的 WebProcessPool 進行了自定義 scheme 的注冊和注銷。繼續(xù)查看 WebProcessPool 的源碼：
發(fā)現(xiàn)其實 WKWebView 也會將 Cookie 存儲于 NSHTTPCookieStorage，同樣Cache 也會存儲于 NSURLCache 中，只是 SandboxExtension 會把數(shù)據(jù) encode 成一個 Message 通過 IPC 發(fā)送給 App Process 進行異步存儲的，這就會存在時機問題，并不是業(yè)界普遍認為 WKWebView 擁有自己的私有存儲。
在 globalURLSchemesWithCustomProtocolHandlers() 中獲取的即是已注冊的自定義 scheme。從前面的源碼中可見這些已注冊的 scheme 被當作配置參數(shù) (NetworkProcessCreationParameters) 傳遞給 Network Process 進程，而在其初始化中
CustomProtocolManager 通過 WKCustomProtocol 負責攔截處理自定義的 scheme，同時把 Network Process 中發(fā)起的網(wǎng)絡(luò)請求發(fā)送到 App Process 進程，交由 CustomProtocolManagerProxy 代理重新發(fā)起實際的網(wǎng)絡(luò)請求，最后把響應(yīng)信息交還給 WKCustomProtocol 進行處理。
總結(jié)一下流程如下：
1、WKBrowsingContextController 通過 registerSchemeForCustomProtocol 向 WebProcessPool 注冊全局自定義 scheme
2、WebProcessPool 使用已注冊的 scheme 初始化 Network Process 進程配置，同時設(shè)置 CustomProtocolManager，負責把網(wǎng)絡(luò)請求通過 IPC 發(fā)送到 App Process 進程、也接收從 App Process 進程返回的網(wǎng)絡(luò)響應(yīng) response
3、CustomProtocolManager 注冊了 NSURLProtocol 的子類 WKCustomProtocol，負責攔截網(wǎng)絡(luò)請求處理
4、CustomProtocolManagerProxy 中的 WKCustomProtocolLoader 使用 NSURLConnection 發(fā)送實際的網(wǎng)絡(luò)請求，并將響應(yīng) response 返回給 CustomProtocolManager
至此，完成了一個完整的網(wǎng)絡(luò)請求代理攔截處理流程。可見 WKWebView 源碼是支持 NSURLProtocol 攔截的。
如何讓 WKWebView 支持 NSURLProtocol
既然知道了源碼邏輯，就可以仿照測試用例中的代碼來實驗上述結(jié)論，這個已經(jīng)有大牛完成了 Demo 例子，這里就只貼出自己測試時候的關(guān)鍵代碼。
實驗結(jié)果證實 WKWebView 是支持 NSURLProtocol 攔截的，只是 WebKit.framework 還不完善。
?額外提一下，越來越多的人開始適配 WKWebView，也趟了不少坑，總結(jié)了不少經(jīng)驗，其中騰訊 Bugly 公眾號上總結(jié)的《WKWebView 那些坑》非常深入。也解決了本人遇到 post 請求 body 數(shù)據(jù)丟失問題的疑惑，受益匪淺。
