CBNetworking:原始碼分析

Super邦發表於2016-08-11

為什麼要對AFNetworking進行多一層的封裝

對於AFNetworking進行二次封裝是很有必要的。事實上,在專案中大量使用第三方網路庫是有風險的,因為網路請求的使用遍佈整個應用,而一旦該對應的網路庫不再更新維護,或者我們有意願的去更換網路框架,修改將會有著巨大的難以承受的工作量。

這一個框架與其他框架有什麼不同

  • 本框架基於AFNetworking3.0的版本進行封裝,面向更新的版本。
  • 為網路請求的任務管理做了大量的工作,使得下載上傳,或者其他使用環境下的任務管理得以更輕鬆的實現。
  • 反其道而行,專為Post請求作出了快取處理,這一部分快取處理的使用與否,由使用者自行決定。
  • 自定義Get請求的快取策略,以時間為基準,嚴格把控快取的有效性。

介面設計

請求

這裡使用了新建NS_ENUM的方式來統一Post和Get介面。

從上面的程式碼我們可以看到,引數useCache決定著你是否使用Post請求的快取功能,而即便將其設定為NO,依然會自動開啟Get請求的快取功能。

資料解析方式

上面的NS_ENUM聯合上面的方法可以更改資料解析方式,更具靈活性。

檔案上傳,下載

針對檔案的下載和上傳的做出專門的設計。

任務管理

由上面的方法中,我們可以看到每一個方法都返回了一個任務物件CBURLSessionTask,這個物件繼承於NSURLSessionTask,如此我們可以直接的取到每次進行任務請求的物件,直接對其進行管理。但不止於此,我仍然寫了以下的幾個介面來更快捷更集中的對其進行管理。

通過這兩個方法,我們可以直接取消所有的請求,或者取消單個連結對應的請求。全域性性的執行取消操作,更方便。

快取處理

Post快取處理

由於蘋果官方的NSURLCache不支援Post請求的快取處理,所有這一部分的快取處理,我自己通過歸檔的方式來進行管理。

主要的方法如下:

值得注意的是,每一次進行快取,都通過HASH的方式對快取進行了加密,從而達到唯一快取和更加安全的目的。

Get請求的自定義

按道理,官方已經對於Get請求進行了很完善的快取處理,為什麼我還要自行處理呢?事實上,我並沒有自定義這一部分的處理,我僅對於NSURLCache加多了一層封裝,從而達到自定義策略的目的,主要的方法如下所示:

小結

更詳細的程式碼請大家點選下載檢視,謝謝大家的關注,如果可以,請點個star支援一下,謝謝。

相關文章