[[166105]]

前言

前些天幫公司做了網絡層的重構，當時就想做好了就分享給大家，后來接著做了新版本的需求，現在才有時間整理一下。

之前的網絡層使用的是直接拖拽導入項目的方式導入了AF，然后還修改了大量的源碼，時隔2年，AF已經更新換代很多次了，導致整個重構遷移非常的麻煩。不過看著前輩寫的代碼，肯定也是一個高人，許多思路和我的一樣，但是實現方式又不同，給我很好的參考。

在做網絡層架構的時候也參考了Casa大神的架構思想，但是還是有所不同。

本文沒有太多的理論，沒有太多的專業術語，一來是方便大家閱讀，二來我的基礎也沒那么好，沒有太多華麗的詞匯，對于架構來說主要是思路，有思路在，具體的實現就沒有問題了。

本文主要介紹以下幾點：

1.網絡接口規范

2.多服務器多環境設置

3.網絡層數據傳遞（請求和返回）

4.業務層對接方式

5.網絡請求怎么自動取消

6.網絡層錯誤處理

無Demo無文章，Demo下載：https://github.com/SummertimSadness/NetWorkingDemo

網絡接口規范

demo里面的請求示例是在網上找的，不符合我說的這套規范，僅作示例用

規范很重要，有合理的規范就可以精簡很多代碼邏輯，特別是接口的兼容，是最底層最基礎的設計，把接口規范放在前面來說

在做這次重構時，我提出了一些規范點，可以給大家參考

1.兩層三部分數據結構

接口返回數據第一次為字典，分為兩層三部分：code、msg、data

"code": 0, 
"msg": "", 
"data": { 
    "upload_log": true, 
    "has_update": false, 
    "admin_id": "529ecfd64" 
} 

• code：錯誤碼，可以記錄下來快速定位接口錯誤原因，可以定義一套錯誤碼，比如200正常，1重新登錄...

• msg：接口文案提示，包括錯誤提示，用來直接顯示給用戶，所以這一套錯誤提示就不能是什么一串英文錯誤了

• data：需要返回的數據，可以是字典，可以是數組

接口幫我們定義了code和msg，是不是我們就不需要做錯誤處理了？當然不是，服務端的錯誤邏輯畢竟是簡單的，具體到data里面的數據處理可能還有錯誤，所以錯誤的處理是必不可少的，下面會單獨對錯誤處理做介紹

2.網絡請求參數上傳方式統一

這里一般都能做到，也有額外的，比如我們的一個服務器接口做的比較早，當時POST接口使用的就不規范，普通的應用信息channelID、device_id使用的是拼接在字符串后面的方式，而真正的請求參數則需要轉成json放在一個字段里面傳遞，就是接口GET、POST并存的方式，造成網絡層需要做特殊處理

所以說標準的GET、POST請求方式是很有必要的

3.關于Null類型

大家都知道Null類型在iOS里面是很特殊的，我的建議是放在客戶端來做，原因有很多：

1）接口的規范定義并不是每個公司都是從一開始就能定義好的，老接口如果要把Null字段去掉的改動非常大

2）客戶端用過一個接口過濾也可以解決，一勞永逸，不用再擔心因為某天接口的問題出現崩潰，而且通過一些Model的第三方庫也可以很好的解決這個問題。這里不得說下swift的類型檢測真是太方便了，之前一個項目用swift寫的，代碼規范一點，根本不會出現因為參數類型問題引起崩潰

多服務器多環境設置

這部分基本上是照搬casa大神的設計，這里我延伸了一個多環境的設計，小的項目一般都是一個服務器，但是像淘寶之類的項目一個服務器顯然是不可能的，多個服務器的設計還是非常普遍的。根據一個枚舉變量通過ServerFactory單例生成獲取對應的服務器配置

1.服務器環境

標準的APP是有4個環境的，開發、測試、預發、正式，特別是服務器的代碼，不能說所有的代碼更改都在正式環境下，應該從開發->測試->預發->正式做代碼的更新，開發就是新需求和優化的時候的更改，測試就是提交給測試人員后的更改，這個時候更改是在一個新的分支上，完成后要和合并到測試分支上并合并到開發分支上，預發這時候的變動就比較小了，一般會在測試人員完成后發布給全公司的人來測試，有問題了才會更改，更改后同樣合并到開發分支，正式則是線上發布版本的緊急BUG修復，修改完后同樣合并到開發分支上。所以開發分支是一直都是最新的。在此基礎上可能會有其他的環境，比如hotfix環境，自定義的h5/后臺本地調試的環境。

客戶端同樣存在這些環境，并且要提供切換的入口。

在我的demo中提供了兩套設置，一套是第一次安裝應用的初始化環境（宏定義），另外是手動切換環境的設置(枚舉EnvironmentType)。這里有一個比較繞的邏輯，宏定義的正式環境設置高于手動切換環境設置，手動切換環境設置高于宏定義其他環境

//宏定義環境設置 
#if !defined YA_BUILD_FOR_DEVELOP && !defined YA_BUILD_FOR_TEST && !defined YA_BUILD_FOR_RELEASE && !defined YA_BUILD_FOR_PRERELEASE 
#define YA_BUILD_FOR_DEVELOP 
//#define YA_BUILD_FOR_TEST 
//#define YA_BUILD_FOR_PRERELEASE 
//#define YA_BUILD_FOR_HOTFIX 
//#define YA_BUILD_FOR_RELEASE      //該環境的優先級最高 
#endif 
//手動環境切換設置 
#ifdef YA_BUILD_FOR_RELEASE 
//優先宏定義正式環境 
self.environmentType = EnvironmentTypeRelease; 
#else 
//手動切換環境后會把設置保存 
NSNumber *type = [[NSUserDefaults standardUserDefaults] objectForKey:@"environmentType"]; 
if (type) { 
    //優先讀取手動切換設置 
    self.environmentType = (EnvironmentType)[type integerValue]; 
} else { 
    #ifdef YA_BUILD_FOR_DEVELOP 
    self.environmentType = EnvironmentTypeDevelop; 
    #elif defined YA_BUILD_FOR_TEST 
    self.environmentType = EnvironmentTypeTest; 
    #elif defined YA_BUILD_FOR_PRERELEASE 
    self.environmentType = EnvironmentTypePreRelease; 
    #elif defined YA_BUILD_FOR_HOTFIX 
    self.environmentType = EnvironmentTypeHotFix; 
    #endif 
} 
#endif 

所以當宏定義正式環境存在的時候是不能手動切換環境的，用于普通用戶的發布版本，但是其他宏定義環境時是可以切換到正式環境的。

半個坑

另外手動切換自定義的環境是在基類中實現的，而其他的環境配置是在協議中實現的，這就和其他環境地址的配置不統一了。

可以這樣理解，這里的基類是為了提供已返回值，協議是為了返回值的靈活，既然自定義環境的地址配置不需要靈活性，自然是放在基類好。思路是大方向，實現是靈活的，如果非要放在協議中實現也無不可以，無非是賦值粘貼幾次一樣的代碼，但是一模一樣的代碼是我最不喜歡看到的，所以就放在基類了。如果有更好的解決方案歡迎提供

2.擴展性

model提供的是高擴展性，針對不同的不服務器添加更多的配置，比如加密方法，比如數據解析方法...前面提到了，統一的規范有的時候不是一時半會就能做好的，兼容就成了需求，這個時候不同服務器的個性化設置就可以在協議中聲明并實現了，基類提供返回值就好

網絡層數據傳遞（請求和返回）

網絡層數據傳遞

Client、BaseEngine/DataEngine、RequestDataModel數據傳遞

網絡請求的發生在我理解中分兩步，一步是數據的整理，一步是生成Request并發起請求，基于這個思想我拆分出了Client和Engine，然后又把URLRequestGenerator從Client中拆分出來，Engine拆分出了下層的BaseEngine和面向不同業務的DataEngine，

而從BaseEngine到Client，再到URLRequestGenerator是要做數據傳遞的，請求參數和返回參數，所以又有了RequestDataModel

RequestDataModel

@interface YAAPIBaseRequestDataModel : NSObject 
/** 
*  網絡請求參數 
*/ 
@property (nonatomic, strong) NSString *apiMethodPath;              //網絡請求地址 
@property (nonatomic, assign) YAServiceType serviceType;            //服務器標識 
@property (nonatomic, strong) NSDictionary *parameters;             //請求參數 
@property (nonatomic, assign) YAAPIManagerRequestType requestType;  //網絡請求方式 
@property (nonatomic, copy) CompletionDataBlock responseBlock;      //請求著陸回調 
// upload 
// upload file 
@property (nonatomic, strong) NSString *dataFilePath; 
@property (nonatomic, strong) NSString *dataName; 
@property (nonatomic, strong) NSString *fileName; 
@property (nonatomic, strong) NSString *mimeType; 
// download 
// download file 
// progressBlock 
@property (nonatomic, copy) ProgressBlock uploadProgressBlock; 
@property (nonatomic, copy) ProgressBlock downloadProgressBlock; 
@end 

可以看出來RequestDataModel屬性都是網絡請求發起和返回的必要參數，這樣做的好處真的是太大了，不知道大家有沒有這樣的場景：因為請求參數的不同做了好多方法接口暴露出去，最后調起的還是同一個方法，而且一旦方法寫的多了，最后連應該調用哪個方法都不知道了。我就遇到過，所以現在我的網絡請求調起是這樣的：

//沒有回調，沒有其他的參數，只有一個dataModel，節省了你所有的方法 
[[YAAPIClient sharedInstance] callRequestWithRequestModel:dataModel]; 

生成NSURLRequest是這樣的：

NSURLRequest *request = [[YAAPIURLRequestGenerator sharedInstance] generateWithYAAPIRequestWithRequestDataModel:requestModel]; 

可以看到我的demo里面的YAAPIClient類和YAAPIURLRequestGenerator類方法至少，方法少就意味著邏輯簡單明了，方便閱讀，兩個類的代碼行數都是120行，120行實現了網絡請求的發起和著陸，你能想象嗎

另外RequestDataModel帶來的另外一個好處就是高擴展性，你有沒有遇到網絡層需要添加刪除一個參數導致調用方法修改了，然后很多地方都要修改方法？用RequestDataModel只需要添加刪除參數就行了，只需要改方法體，這個改方法體和同時改方法名方法體是完全兩個工作量。哈哈，有點賣虎皮膏藥的感覺。這個的確是我的得意創新點

Client

Client做兩個操作，一個是生成NSURLRequest，一個是生成NSURLSessionDataTask并發起，另外還要暴露取消操作給Engine，

URLRequestGenerator是生成NSURLRequest，URLRequestGenerator會對dataModel進行加工解析，生成對應服務器的NSURLRequest

然后Client通過NSURLRequest生成NSURLSessionDataTask

Client和URLRequestGenerator都是單例

- (void)callRequestWithRequestModel:(YAAPIBaseRequestDataModel *)requestModel{ 
    NSURLRequest *request = [[YAAPIURLRequestGenerator sharedInstance] 
    generateWithRequestDataModel:requestModel]; 
    AFURLSessionManager *sessionManager = self.sessionManager; 
    NSURLSessionDataTask *task = [sessionManager 
    dataTaskWithRequest:request 
    uploadProgress:requestModel.uploadProgressBlock 
    downloadProgress:requestModel.downloadProgressBlock 
    completionHandler:^(NSURLResponse * _Nonnull response, 
    id  _Nullable responseObject, 
    NSError * _Nullable error) 
    { 
        //請求著陸 
    }]; 
    [task resume]; 
} 

取消接口參考了casa大神的設計，使用NSNumber *requestID來做task的綁定，就不多做介紹了

BaseEngine/DataEngine

Engine或者說是APIManager在我的設計中既不是離散的也不是集約的

casa大神的理論

集約型API調用其實就是所有API的調用只有一個類，然后這個類接收API名字，API參數，以及回調著陸點（可以是target-action，或者block，或者delegate等各種模式的著陸點）作為參數。然后執行類似startRequest這樣的方法，它就會去根據這些參數起飛去調用API了，然后獲得API數據之后再根據指定的著陸點去著陸。比如這樣：

[APIRequest startRequestWithApiName:@"itemList.v1" params:params success:@selector(success:) fail:@selector(fail:) target:self]; 

離散型API調用是這樣的，一個API對應于一個APIManager，然后這個APIManager只需要提供參數就能起飛，API名字、著陸方式都已經集成入APIManager中。比如這樣：

@property (nonatomic, strong) ItemListAPIManager *itemListAPIManager; 
// getter 
-(ItemListAPIManager *)itemListAPIManager 
{ 
    if (_itemListAPIManager == nil) { 
        _itemListAPIManager = [[ItemListAPIManager alloc] init]; 
        _itemListAPIManager.delegate = self; 
    } 
    return _itemListAPIManager; 
} 
// 使用的時候就這么寫： 
[self.itemListAPIManager loadDataWithParams:params]; 

各自的優點就不說了，但是由此延伸出幾個問題：

1.參數的傳遞使用字典對于網絡層來說是不可知的，而且業務層需要去關注接口字段的變化，其實是沒有必要的

2.離散型API會造成Manager大爆炸

3.集約型會造成取消操作不方便

4.取消操作并不是每個接口必須的，如果寫成部分離散的部分集約的，代碼的整體結構...我是個有強迫癥的人，看不得這樣的代碼

所以我的設計主要就解決了上面的這些問題

1.面向業務層的DataEngine只傳遞必要的參數進來，不使用字典,比如

@interface SearchDataEngine : NSObject 
+ (YABaseDataEngine *)control:(NSObject *)control 
searchKey:(NSString *)searchKey 
complete:(CompletionDataBlock)responseBlock; 
@end 

control暫時先不管，是做自動取消的，后面再介紹。

searchKey就是搜索的關鍵字

在調用的時候就是這樣

self.searchDataEngine = [SearchDataEngine control:self searchKey:@"關鍵字" complete:^(id data, NSError *error) { 
    if (error) { 
        NSLog(@"%@",error.localizedDescription); 
    } else { 
        NSLog(@"%@",data); 
    } 
}]; 

2.我按業務層來劃分DataEngine，比如BBSDataEngine、ShopDataEngine、UserInforDataEngine...每個DataEngine里面包含各自業務的所有網絡請求接口，這樣就不會出現DataEngine大爆炸，像我們的項目有300多個接口，拆分后有十幾個DataEngine，如果使用離散型API設計，那畫面太美我不敢看??

3.BaseEngine提供取消操作

每個接口生成一個BaseEngine實例，持有Client返回的requestID，所以就可以做取消操作，簡單的使用場景

#import "ViewController.h" 
#import "SearchDataEngine.h" 
@interface ViewController () 
@property (nonatomic, strong) YABaseDataEngine *searchDataEngine; 
@end 
@implementation ViewController 
- (void)viewDidLoad { 
    [super viewDidLoad]; 
    // Do any additional setup after loading the view, typically from a nib. 
    [self.searchDataEngine cancelRequest]; 
    self.searchDataEngine = [SearchDataEngine control:self searchKey:@"關鍵字" complete:^(id data, NSError *error) { 
    if (error) { 
        NSLog(@"%@",error.localizedDescription); 
    } else { 
        NSLog(@"%@",data); 
    } 
    }]; 
} 
@end 

4.返回的YABaseDataEngine實例ViewController不是必須持有的，當有需要取消操作的時候再去持有就行了

這樣的設計就集成了集約型和離散型的有點，又解決了集約型和離散型的缺點

網絡請求怎么自動取消

當一個頁面的請求正在天上飛的時候，用戶等了好久不耐煩了，小手點了個back，然后ViewController被pop被回收。此時請求的著陸點就沒了。這是很危險的情況，著陸點要是沒了，就很容易crash的。

casa大神說在BaseDataEngine的dealloc里面做取消網絡請求操作，我也是這樣想的，但是casa大神說要把BaseDataEngine綁定給ViewController，當ViewController銷毀時BaseDataEngine也就跟著銷毀了，這樣我也是同意的，但是要讓我不管什么情況都要給ViewController添加BaseDataEngine變量來保存BaseDataEngine這是我萬萬不能接受的，而且有的ViewController會發起兩三種網絡請求，難道要我添加兩三個變量？代碼入侵太大，所以這里偷偷使用了一個巧，使用了runtime，給ViewController添加一個字典，來保存requestID和BaseDataEngine，這樣對于ViewController來說就不是必須要寫變量來持有BaseDataEngine了，所以就出現了上面的DataEngine里面要把control傳遞進來的樣子

在發起請求的時候進行綁定

[control.networkingAutoCancelRequests setEngine:self requestID:self.requestID]; 

在請求完成的時候進行刪除

[weakControl.networkingAutoCancelRequests removeEngineWithRequestID:engine.requestID]; 

公司上個大神的做法

雖然使用control的做法很方便，但是如果說要把現在已有的接口都添加一個control字段的工作量也是很大的，如果已有的接口是使用字典傳遞給DataEngine的，這里給大家一個公司上個大神的做法，使用內存地址，將內存地址添加到字典中去，用內存地址做key綁定，也是可以的。如果是像我這樣直接把關鍵參數傳遞過來的，不是用的字典，就不行了。

NSString *memoryAddress = [NSString stringWithFormat:@"%p", self]; 

網絡層錯誤處理

說實話，錯誤處理該放在按個地方我也是糾結了好久，也和公司同事討論了好久，最終定下來了一套方案，僅供大家參考。

我們將錯誤處理分為兩個步驟，一個是錯誤解析，一個是錯誤的UI展示

大家可以看到我設計的接口返回數據是標準的id data, NSError *error,所以我的想法是Client就把error處理好，不管你是網絡超時錯誤也好，或者是數據格式不正確也好，都error解析完整，把code錯誤碼定義好，上層根據需要通過code來做具體的UI展示，因為有的界面的錯誤需要用戶的點擊確認，有的頁面的錯誤只是一閃而過的提示框，把error交給BaseEngine或者DataEngine來處理errorUI，所以我定義了一套errorUI的枚舉，當BaseEngine拿到error的時候就去做錯誤的展示

總結

架構的設計更多的是思路，我希望的是大家能通過我們提供的思路取其精華去其糟粕，總會設計會最適合你的項目的架構的

另外我的這套設計存在的爭議的點可能會有很多，有一部分我已經在文中提到了，如果大家有什么其他的想法我們再討論

1.關于block

對于block和delegate的選擇，我更傾向于block，只有一個原因，因為block的結構更方便閱讀，這一個優點我覺得足以秒殺他所有的缺點，可以這樣說，我現在的項目基本上很少用到delegate了。

什么時候自定義delegate？就是當你的不同時期的回調超過2次的時候(不包含2次)，3次回調就看情況了，如果要處理的邏輯比較少就使用block，多的話就使用delegat，一旦超過3次，基本上就不會考慮block，希望大家也不要對block存在偏見，延遲生命周期什么的都是可以解決的，一個宏定義就解決了,順便給出strongSelf，如果這么方便的宏都不愿意使用，那是真的不適合用block了，誰也救不了你

#define WEAKSELF typeof(self) __weak weakSelf = self; 
#define STRONGSELF typeof(weakSelf) __strong strongSelf = weakSelf; 

2.交付什么樣的數據給ViewController？是model還是data

這個有什么好爭議的嗎？有DataEngine在，交付什么樣的數據還不是你說了算。

底層的BaseEngine和Client當然還是data比較合適，到了DataEngine層，你想交付什么樣的數據就交什么樣的數據，可以看業務層的需求，有的接口根本就不包含model，你非要統一所有的接口都返回model這不是扯淡嗎，所以我的建議是根據接口的實際情況來，統一規范，我們的設計因為有些接口是不需要model的，以后就統一返回data

3.優化

我的這套設計只是基本思路，還有很多優化的點，我知道。

這部分就是各顯神通的地方了，不是我藏私，而是現在的項目對于網絡層沒有太多的優化點，所以我也沒做太多，做的部分敏感代碼太多，實在是沒辦法拆出來，不過可以告訴大家一個小的優化點，errorUI的處理可以考慮做成隊列，比如需要用戶點擊確定的彈出框，而且內容都是一樣的，放在隊列里面只顯示一次就好

4.為什么業務層沒有使用RequestDataModel

model就是對象，下層主要是用來做數據傳遞的，用model沒有問題；而向上到業務層的時候，更多的理念是方法的調用，而且方法的定義更有針對性，這個時候用model就不合適了。就好像超市一樣，進貨的時候是使用集裝箱拉貨的，所有的東西都裝在一起，當到柜臺的時候就會一個個的分類擺好。