iOS網路請求庫

摘要： 這已經是老生常談的問題了。 作為一個入門級、大眾級的封裝，彷彿在網上隨隨便便就能找到一套適用於自己的方案。在afnetworking一統天下之後（得到了蘋果官方認可），基於其afnetworking的封裝也越來越全面、強大。 但是，每一個開發者都想擁有屬於自己的網路請求庫☺，而且很多別...

這已經是老生常談的問題了。

作為一個入門級、大眾級的封裝，彷彿在網上隨隨便便就能找到一套適用於自己的方案。在afnetworking一統天下之後（得到了蘋果官方認可），基於其afnetworking的封裝也越來越全面、強大。

但是，每一個開發者都想擁有屬於自己的網路請求庫☺，而且很多別人的封裝用起來隔靴搔癢，所以我們在整理了專案內所有網路請求的痛點之後，搞了一套最適合我們自己的方案。

我們現在就用最流行的“影響地圖”來解構這套框架。

這套方案能為我們帶來什麼

相比於afnetworking，ZZCHTTPSession提供了以下功能：

• 支援硬碟快取網路請求內容
• 支援記憶體快取網路請求內容（參考sdwebimage，分為記憶體快取和硬碟快取）
• 支援快取同一URL，某個引數value不同的情況
• 支援快取的統一清除管理
• 保證返回 JSON 內容的合法性
• 支援統一設定URL地址，測試域名、自定義域名管理
• 請求和回撥的分離，比如登陸之後，只需要管理需要重新請求的signal就好了，不用回到具體的頁面處理。
• 支援批量的網路請求傳送，並統一設定它們的回撥（直接把signal作為陣列進行請求）
• 可以統一為網路請求加上一些引數，或者修改一些路徑。

適用專案

除了URL的管理稍顯複雜之外，其他都儘量向輕量級，適用性靠攏。

適合中小型專案的開發使用，個人開發尤其推薦（使用鏈式的方式傳參，完全是不想宣告那麼多的API啊，儘管有一部分開發試聽抗拒這種方式的:joy:）。

支援大部分APP對URL管理、記憶體硬碟快取、多個請求管理、model管理的要求。對依賴路由的APP能發揮最大優勢。（完全解耦）

基本思想

ZZCURLManagement配置URL，ZZCHTTPSessionSignal配置請求，建議加一個協議層，用來管理所有的signal。

協議層使用ZZCHTTPServer的分類。

協議層：

@interface ZZCHTTPServer (Home)
+ (ZZCHTTPSessionSignal *)getHomeBaseInfoSignal;
@end

NSString * const home_base_info = @"home_base_info";
@implementation ZZCHTTPServer (Home)
+ (void)load{
setDefaultUrl(home_base_info, @"/app_v3/api/baseInfo.php");
}

+ (ZZCHTTPSessionSignal *)getHomeBaseInfoSignal{
return [ZZCHTTPServer singletonPatternSignalWithUrlId:home_base_info maker:^(ZZCHTTPRequestMaker * _Nonnull make) {
make.get().cachePolicy(ZZCHTTPRequestCachePolicyCache);
}];
}
@end

請求回撥：

[ZZCHTTPServer getHomeBaseInfoSignal].complete = ^(NSInteger code, NSString * _Nonnull msg) {
NSLog(@"getHomeBaseInfoSignal%ld%@",code,msg);
};

發起請求：

[[ZZCHTTPServer getHomeBaseInfoSignal] request];