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