緩存組件應該說是每個客戶端程式必備的核心組件，試想對於每個界面的訪問都必須重新請求勢必降低用戶體驗。但是如何處理客戶端緩存貌似並沒有統一的解決方案，多數開發者選擇自行創建資料庫直接將伺服器端請求的JSON（或Model）緩存起來，下次請求則查詢資料庫檢查緩存是否存在；另外還有些開發者會選擇以歸檔文件... ...
概覽
緩存組件應該說是每個客戶端程式必備的核心組件，試想對於每個界面的訪問都必須重新請求勢必降低用戶體驗。但是如何處理客戶端緩存貌似並沒有統一的解決方案，多數開發者選擇自行創建資料庫直接將伺服器端請求的JSON（或Model）緩存起來，下次請求則查詢資料庫檢查緩存是否存在；另外還有些開發者會選擇以歸檔文件的方式保存緩存數據，每次請求資源之前檢查相應的緩存文件。事實上iOS系統自身就提供了一套緩存機制，本文將結合URL Loading System介紹一下如何利用系統自身緩存設計來實現一套緩存機制，使用這套緩存設計你無需自己編寫記憶體和磁碟存儲，無需自行檢查緩存過期策略就能輕鬆實現數據緩存。
URL Loading System
URL Loading System是類和協議的集合，使用URL Loading System iOS系統和伺服器端進行網路交互。URL作為其中的核心，能夠讓app和資源進行輕鬆的交互。為了增強URL的功能Foundation提供了豐富的類集合，能夠讓你根據地址載入資源、上傳資源到伺服器、管理cookie、控制響應緩存（這也是我們今天的重點內容）、處理證書和認證、擴展用戶協議（後面也會提到相關內容）等，因此URL緩存之前熟悉URL Loading System是必要的。下圖一系列集合的關係：
本文代碼一律使用Swift編寫，但是鑒於很多朋友接觸URL Loading System都是從Objective-C開始，所以文章中文字部分還是採用OC命名，其區別不大，主要是少了NS首碼。
NSURLProtocol
URL Loading System預設支持http、https、ftp、file和data 協議，但是它同樣也支持你註冊自己的類來支持更多應用層網路協議，當然你也可以指定其他屬性到URL reqeust和URL response上。具體而言NSURLProtocl可以實現以下需求（包含但不限）：
- 重定向網路請求（或進行功能變數名稱轉化、攔截等，例如：netfox）
- 忽略某些請求，使用本地緩存數據
- 自定義網路請求的返回結果 （比如：GYHttpMocking）
- 進行網路全局配置
NSURLProtocol類似中間人設計，將網路求細節提供給開發者，而又以一種優雅的方式暴漏出來。NSURLProtocol的定義更像是一個URL協議，儘管它繼承自NSObject卻不能直接使用，使用時自定義協議繼承NSURLProtocol，然後在app啟動時註冊即可，這樣一來所有請求細節開發者只需要在自己的類中控制即可（這個設計確實完美
