前言
網路層在一個App中也是一個不可缺少的部分，工程師們在網路層能夠發揮的空間也比較大。另外，蘋果對網路請求部分已經做了很好的封裝，業界的AFNetworking也被廣泛使用。其它的ASIHttpRequest，MKNetworkKit啥的其實也都還不錯，但前者已經棄坑，後者也在棄坑的邊緣。在實際的App開發中，Afnetworking已經成為了事實上各大App的標準配置。
網路層在一個App中承載了API呼叫，使用者操作日誌記錄，甚至是即時通訊等任務。我接觸過一些App（開源的和不開源的）的程式碼，在看到網路層這一塊時，尤其是在看到各位架構師各顯神通展示了各種技巧，我非常為之感到興奮。但有的時候，往往也對於其中的一些缺陷感到失望。
關於網路層的設計方案會有很多，需要權衡的地方也會有很多，甚至於爭議的地方都會有很多。但無論如何，我都不會對這些問題做出任何逃避，我會在這篇文章中給出我對它們的看法和解決方案，觀點絕不中立，不會跟大家打太極。
這篇文章就主要會講這些方面：
- 網路層跟業務對接部分的設計
- 網路層的安全機制實現
- 網路層的優化方案
網路層跟業務對接部分的設計
在安居客App的架構更新換代的時候，我深深地感覺到網路層跟業務對接部分的設計有多麼重要，因此我對它做的最大改變就是針對網路層跟業務對接部分的改變。網路層跟業務層對接部分設計的好壞，會直接影響到業務工程師實現功能時的心情。
在正式開始講設計之前，我們要先討論幾個問題：
- 使用哪種互動模式來跟業務層做對接？
- 是否有必要將API返回的資料封裝成物件然後再交付給業務層？
- 使用集約化呼叫方式還是離散型呼叫方式去呼叫API？
這些問題討論完畢之後，我會給出一個完整的設計方案來給大家做參考，設計方案是魚，討論的這些問題是漁，我什麼都授了，大家各取所需。
使用哪種互動模式來跟業務層做對接？
這裡其實有兩個問題：
- 以什麼方式將資料交付給業務層？
- 交付什麼樣的資料給業務層？
以什麼方式將資料交付給業務層？
iOS開發領域有很多物件間資料的傳遞方式，我看到的大多數App在網路層所採用的方案主要集中於這三種：Delegate，Notification，Block。KVO和Target-Action我目前還沒有看到有使用的。
目前我知道邊鋒主要是採用的block，大智慧主要採用的是Notification，安居客早期以Block為主，後面改成了以Delegate為主，阿里沒發現有通過Notification來做資料傳遞的地方（可能有），Delegate、Block以及target-action都有，阿里iOS App網路層的作者說這是為了方便業務層選擇自己合適的方法去使用。這裡大家都是各顯神通，每次我看到這部分的時候，我都喜歡問作者為什麼採用這種互動方案，但很少有作者能夠說出個條條框框來。
然而在我這邊，我的意見是以Delegate為主，Notification為輔。原因如下：
- 儘可能減少跨層資料交流的可能，限制耦合
- 統一回撥方法，便於除錯和維護
- 在跟業務層對接的部分只採用一種對接手段（在我這兒就是隻採用delegate這一個手段）限制靈活性，以此來交換應用的可維護性
儘可能減少跨層資料交流的可能，限制耦合
什麼叫跨層資料交流？就是某一層（或模組）跟另外的與之沒有直接對接關係的層（或模組）產生了資料交換。為什麼這種情況不好？嚴格來說應該是大部分情況都不好，有的時候跨層資料交流確實也是一種需求。之所以說不好的地方在於，它會導致程式碼混亂，破壞模組的封裝性。我們在做分層架構的目的其中之一就在於下層對上層有一次抽象，讓上層可以不必關心下層細節而執行自己的業務。
所以，如果下層細節被跨層暴露，一方面你很容易因此失去鄰層對這個暴露細節的保護；另一方面，你又不可能不去處理這個細節，所以處理細節的相關程式碼就會散落各地，最終難以維護。
說得具象一點就是，我們考慮這樣一種情況：A<-B<-C。當C有什麼事件，通過某種方式告知B，然後B執行相應的邏輯。一旦告知方式不合理，讓A有了跨層知道C的事件的可能，你 就很難保證A層業務工程師在將來不會對這個細節作處理。一旦業務工程師在A層產生處理操作，有可能是補充邏輯，也有可能是執行業務，那麼這個細節的相關處理程式碼就會有一部分散落在A層。然而前者是不應該散落在A層的，後者有可能是需求。另外，因為B層是對A層抽象的，執行補充邏輯的時候，有可能和B層針對這個事件的處理邏輯產生衝突，這是我們很不希望看到的。
那麼什麼情況跨層資料交流會成為需求？在網路層這邊，訊號從2G變成3G變成4G變成Wi-Fi，這個是跨層資料交流的其中一個需求。不過其他的跨層資料交流需求我暫時也想不到了，哈哈，應該也就這一個吧。
嚴格來說，使用Notification來進行網路層和業務層之間資料的交換，並不代表這一定就是跨層資料交流，但是使用Notification給跨層資料交流開了一道口子，因為Notification的影響面不可控制，只要存在例項就存在被影響的可能。另外，這也會導致誰都不能保證相關處理程式碼就在唯一的那個地方，進而帶來維護災難。作為架構師，在這裡給業務工程師限制其操作的靈活性是必要的。另外，Notification也支援一對多的情況，這也給程式碼散落提供了條件。同時，Notification所對應的響應方法很難在編譯層面作限制，不同的業務工程師會給他取不同的名字，這也會給程式碼的可維護性帶來災難。
手機淘寶架構組的俠武同學曾經給我分享過一個問題，在這裡我也分享給大家：曾經有一個工程師在監聽Notification之後，沒有寫釋放監聽的程式碼，當然，找到這個原因又是很漫長的一段故事，現在找到原因了，然而監聽這個Notification的物件有那麼多，不知道具體是哪個Notificaiton，也不知道那個沒釋放監聽的物件是誰。後來折騰了很久大家都沒辦法的時候，有一個經驗豐富的工程師提出用hook（Method Swizzling）的方式，最終找到了那個沒釋放監聽的物件，bug修復了。
我分享這個問題的目的並不是想強調Notification多麼多麼不好，Notification本身就是一種設計模式，在屬於他的問題領域內，Notification是非常好的一種解決方案。但我想強調的是，對於網路層這個問題領域內來看，架構師首先一定要限制程式碼的影響範圍，在能用影響範圍小的方案的時候就儘量採用這種小的方案，否則將來要是有什麼奇怪需求或者出了什麼小問題，維護起來就非常麻煩。因此Notification這個方案不能作為首選方案，只能作為備選。
那麼Notification也不是完全不能使用，當需求要求跨層時，我們就可以使用Notification，比如前面提到的網路條件切換，而且這個需求也是需要滿足一對多的。
所以，為了符合前面所說的這些要求，使用Delegate能夠很好地避免跨層訪問，同時限制了響應程式碼的形式，相比Notification而言有更好的可維護性。
然後我們順便來說說為什麼儘量不要用block。
- block很難追蹤，難以維護
我們在除錯的時候經常會單步追蹤到某一個地方之後，發現尼瑪這裡有個block，如果想知道這個block裡面都做了些什麼事情，這時候就比較蛋疼了。
|
1 2 3 4 5 6 7 8 |
- (void)someFunctionWithBlock:(SomeBlock *)block { ... ... -> block(); //當你單步走到這兒的時候，要想知道block裡面都做了哪些事情的話，就很麻煩。 ... ... } |
- block會延長相關物件的生命週期
block會給內部所有的物件引用計數加一，這一方面會帶來潛在的retain cycle，不過我們可以通過Weak Self的手段解決。另一方面比較重要就是，它會延長物件的生命週期。
在網路回撥中使用block，是block導致物件生命週期被延長的其中一個場合，當ViewController從window中卸下時，如果尚有請求帶著block在外面飛，然後block裡面引用了ViewController（這種場合非常常見），那麼ViewController是不能被及時回收的，即便你已經取消了請求，那也還是必須得等到請求著陸之後才能被回收。
然而使用delegate就不會有這樣的問題，delegate是弱引用，哪怕請求仍然在外面飛，，ViewController還是能夠及時被回收的，回收之後指標自動被置為了nil，無傷大雅。
所以平時儘量不要濫用block，尤其是在網路層這裡。
統一回撥方法，便於除錯和維護
前面講的是跨層問題，區分了Delegate和Notification，順帶談了一下Block。然後現在談到的這個情況，就是另一個採用Block方案不是很合適的情況。首先，Block本身無好壞對錯之分，只有合適不合適。在這一節要講的情況裡，Block無法做到回撥方法的統一，除錯和維護的時候也很難在呼叫棧上顯示出來，找的時候會很蛋疼。
在網路請求和網路層接受請求的地方時，使用Block沒問題。但是在獲得資料交給業務方時，最好還是通過Delegate去通知到業務方。因為Block所包含的回撥程式碼跟呼叫邏輯放在同一個地方，會導致那部分程式碼變得很長，因為這裡麵包括了呼叫前和呼叫後的邏輯。從另一個角度說，這在一定程度上違背了single function，single task的原則，在需要呼叫API的地方，就只要寫API呼叫相關的程式碼，在回撥的地方，寫回撥的程式碼。
然後我看到大部分App裡，當業務工程師寫程式碼寫到這邊的時候，也意識到了這個問題。因此他們會在block裡面寫個一句話的方法接收引數，然後做轉發，然後就可以把這個方法放在其他地方了，繞過了Block的回撥著陸點不統一的情況。比如這樣：
|
1 2 3 4 5 |
[API callApiWithParam:param successed:^(Response *response){ [self successedWithResponse:response]; } failed:^(Request *request, NSError *error){ [self failedWithRequest:request error:error]; }]; |
這實質上跟使用Delegate的手段沒有什麼區別，只是繞了一下，不過還是沒有解決統一回撥方法的問題，因為block裡面寫的方法名字可能在不同的ViewController物件中都會不一樣，畢竟業務工程師也是很多人，各人有各人的想法。所以架構師在這邊不要貪圖方便，還是使用delegate的手段吧，業務工程師那邊就能不用那麼繞了。Block是目前大部分第三方網路庫都採用的方式，因為在傳送請求的那一部分，使用Block能夠比較簡潔，因此在請求那一層是沒有問題的，只是在交換資料之後，還是轉變成delegate比較好，比如AFNetworking裡面：
|
1 2 3 4 5 6 7 8 9 |
[AFNetworkingAPI callApiWithParam:self.param successed:^(Response *response){ if ([self.delegate respondsToSelector:@selector(successWithResponse:)]) { [self.delegate successedWithResponse:response]; } } failed:^(Request *request, NSError *error){ if ([self.delegate respondsToSelector:@selector(failedWithResponse:)]) { [self failedWithRequest:request error:error]; } }]; |
這樣在業務方這邊回撥函式就能夠比較統一，便於維護。
綜上，對於以什麼方式將資料交付給業務層？這個問題的回答是這樣：
儘可能通過Delegate的回撥方式交付資料，這樣可以避免不必要的跨層訪問。當出現跨層訪問的需求時（比如訊號型別切換），通過Notification的方式交付資料。正常情況下應該是避免使用Block的。
交付什麼樣的資料給業務層？
我見過非常多的App的網路層在拿到JSON資料之後，會將資料轉變成對應的物件原型。注意，我這裡指的不是NSDictionary，而是類似Item這樣的物件。這種做法是能夠提高後續操作程式碼的可讀性的。在比較直覺的思路里面，是需要這部分轉化過程的，但這部分轉化過程的成本是很大的，主要成本在於：
- 陣列內容的轉化成本較高：陣列裡面每項都要轉化成Item物件，如果Item物件中還有類似陣列，就很頭疼。
- 轉化之後的資料在大部分情況是不能直接被展示的，為了能夠被展示，還需要第二次轉化。
- 只有在API返回的資料高度標準化時，這些物件原型（Item）的可複用程度才高，否則容易出現型別爆炸，提高維護成本。
- 除錯時通過物件原型檢視資料內容不如直接通過NSDictionary/NSArray直觀。
- 同一API的資料被不同View展示時，難以控制資料轉化的程式碼，它們有可能會散落在任何需要的地方。
其實我們的理想情況是希望API的資料下發之後就能夠直接被View所展示。首先要說的是，這種情況非常少。另外，這種做法使得View和API聯絡緊密，也是我們不希望發生的。
在設計安居客的網路層資料交付這部分時，我新增了reformer（名字而已，叫什麼都好）這個物件用於封裝資料轉化的邏輯，這個物件是一個獨立物件，事實上，它是作為Adaptor模式存在的。我們可以這麼理解：想象一下我們洗澡時候使用的蓮蓬頭，水管裡出來的水是API下發的原始資料。reformer就是蓮蓬頭上的不同水流擋板，需要什麼模式，就撥到什麼模式。
在實際使用時，程式碼觀感是這樣的：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
先定義一個protocol： @protocol ReformerProtocol <NSObject> - (NSDictionary)reformDataWithManager:(APIManager *)manager; @end 在Controller裡是這樣： @property (nonatomic, strong) id<ReformerProtocol> XXXReformer; @property (nonatomic, strong) id<ReformerProtocol> YYYReformer; #pragma mark - APIManagerDelegate - (void)apiManagerDidSuccess:(APIManager *)manager { NSDictionary *reformedXXXData = [manager fetchDataWithReformer:self.XXXReformer]; [self.XXXView configWithData:reformedXXXData]; NSDictionary *reformedYYYData = [manager fetchDataWithReformer:self.YYYReformer]; [self.YYYView configWithData:reformedYYYData]; } 在APIManager裡面，fetchDataWithReformer是這樣： - (NSDictionary)fetchDataWithReformer:(id<ReformerProtocol>)reformer { if (reformer == nil) { return self.rawData; } else { return [reformer reformDataWithManager:self]; } } |
- 要點1：reformer是一個符合ReformerProtocol的物件，它提供了通用的方法供Manager使用。
- 要點2：API的原始資料（JSON物件）由Manager例項保管，reformer方法裡面取Manager的原始資料(manager.rawData)做轉換，然後交付出去。蓮蓬頭的水管部分是Manager，負責提供原始水流（資料流），reformer就是不同的模式，換什麼reformer就能出來什麼水流。
- 要點3：例子中舉的場景是一個API資料被多個View使用的情況，體現了reformer的一個特點：可以根據需要改變同一資料來源的展示方式。比如API資料展示的是“附近的小區”，那麼這個資料可以被列表（XXXView）和地圖（YYYView）共用，不同的view使用的資料的轉化方式不一樣，這就通過不同的reformer解決了。
- 要點4：在一個view用來同一展示不同API資料的情況，reformer是絕佳利器。比如安居客的列表view的資料來源可能有三個：二手房列表API，租房列表API，新房列表API。這些API返回來的資料的value可能一致，但是key都是不一致的。這時候就可以通過同一個reformer來做資料的標準化輸出，這樣就使得view程式碼複用成為可能。這體現了reformer另外一個特點：同一個reformer出來的資料是高度標準化的。形象點說就是：只要蓮蓬頭不換，哪怕水管的水變成海水或者汙水了，也依舊能夠輸出符合洗澡要求的淡水水流。舉個例子：
|
1 2 3 4 5 6 |
- (void)apiManagerDidSuccess:(APIManager *)manager { // 這個回撥方法有可能是來自二手房列表APIManager的回撥，也有可能是租房，也有可能是新房。但是在Controller層面我們不需要對它做額外區分，只要是同一個reformer出來的資料，我們就能保證是一定能被self.XXXView使用的。這樣的保證由reformer的實現者來提供。 NSDictionary *reformedXXXData = [manager fetchDataWithReformer:self.XXXReformer]; [self.XXXView configWithData:reformedXXXData]; } |
- 要點5：有沒有發現，使用reformer之後，Controller的程式碼簡潔了很多？而且，資料原型在這種情況下就沒有必要存在了，隨之而來的成本也就被我們繞過了。
reformer本質上就是一個符合某個protocol的物件，在controller需要從api manager中獲得資料的時候，順便把reformer傳進去，於是就能獲得經過reformer重新洗過的資料，然後就可以直接使用了。
更抽象地說，reformer其實是對資料轉化邏輯的一個封裝。在controller從manager中取資料之後，並且把資料交給view之前，這期間或多或少都是要做一次資料轉化的，有的時候不同的view，對應的轉化邏輯還不一樣，但是展示的資料是一樣的。而且往往這一部分程式碼都非常複雜，且跟業務強相關，直接上程式碼，將來就會很難維護。所以我們可以考慮採用不同的reformer封裝不同的轉化邏輯，然後讓controller根據需要選擇一個合適的reformer裝上，就像洗澡的蓮蓬頭，需要什麼樣的水流（資料的表現形式）就換什麼樣的頭，然而水（資料）都是一樣的。這種做法能夠大大提高程式碼的可維護性，以及減少ViewController的體積。
總結一下，reformer事實上是把轉化的程式碼封裝之後再從主體業務中拆分了出來，拆分出來之後不光降低了原有業務的複雜度，更重要的是，它提高了資料交付的靈活性。另外，由於Controller負責排程Manager和View，因此它是知道Manager和View之間的關係的，Controller知道了這個關係之後，就有了充要條件來為不同的View選擇不同的Reformer，並用這個Reformer去改造Mananger的資料，然後ViewController獲得了經過reformer處理過的資料之後，就可以直接交付給view去使用。Controller因此得到瘦身，負責業務資料轉化的這部分程式碼也不用寫在Controller裡面，提高了可維護性。
所以reformer機制能夠帶來以下好處：
- 好處1：繞開了API資料原型的轉換，避免了相關成本。
- 好處2：在處理單View對多API，以及在單API對多View的情況時，reformer提供了非常優雅的手段來響應這種需求，隔離了轉化邏輯和主體業務邏輯，避免了維護災難。
- 好處3：轉化邏輯集中，且將轉化次數轉為只有一次。使用資料原型的轉化邏輯至少有兩次，第一次是把JSON對映成對應的原型，第二次是把原型轉變成能被View處理的資料。reformer一步到位。另外，轉化邏輯在reformer裡面，將來如果API資料有變，就只要去找到對應reformer然後改掉就好了。
- 好處4：Controller因此可以省去非常多的程式碼，降低了程式碼複雜度，同時提高了靈活性，任何時候切換reformer而不必切換業務邏輯就可以應對不同View對資料的需要。
- 好處5：業務資料和業務有了適當的隔離。這麼做的話，將來如果業務邏輯有修改，換一個reformer就好了。如果其他業務也有相同的資料轉化邏輯，其他業務直接拿這個reformer就可以用了，不用重寫。另外，如果controller有修改（比如UI互動方式改變），可以放心換controller，完全不用擔心業務資料的處理。
在不使用特定物件表徵資料的情況下，如何保持資料可讀性？
不使用物件來表徵資料的時候，事實上就是使用NSDictionary的時候。事實上，這個問題就是，如何在NSDictionary表徵資料的情況下保持良好的可讀性？
蘋果已經給出了非常好的做法，用固定字串做key，比如你在接收到KeyBoardWillShow的Notification時，帶了一個userInfo，他的key就都是類似UIKeyboardAnimationCurveUserInfoKey這樣的，所以我們採用這樣的方案來維持可讀性。下面我舉一個例子：
|
1 2 3 4 5 6 |
PropertyListReformerKeys.h extern NSString * const kPropertyListDataKeyID; extern NSString * const kPropertyListDataKeyName; extern NSString * const kPropertyListDataKeyTitle; extern NSString * const kPropertyListDataKeyImage; |
|
1 2 3 4 5 |
PropertyListReformer.h #import "PropertyListReformerKeys.h" ... ... |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
PropertyListReformer.m NSString * const kPropertyListDataKeyID = @"kPropertyListDataKeyID"; NSString * const kPropertyListDataKeyName = @"kPropertyListDataKeyName"; NSString * const kPropertyListDataKeyTitle = @"kPropertyListDataKeyTitle"; NSString * const kPropertyListDataKeyImage = @"kPropertyListDataKeyImage"; - (NSDictionary *)reformData:(NSDictionary *)originData fromManager:(APIManager *)manager { ... ... ... ... NSDictionary *resultData = nil; if ([manager isKindOfClass:[ZuFangListAPIManager class]]) { resultData = @{ kPropertyListDataKeyID:originData[@"id"], kPropertyListDataKeyName:originData[@"name"], kPropertyListDataKeyTitle:originData[@"title"], kPropertyListDataKeyImage:[UIImage imageWithUrlString:originData[@"imageUrl"]] }; } if ([manager isKindOfClass:[XinFangListAPIManager class]]) { resultData = @{ kPropertyListDataKeyID:originData[@"xinfang_id"], kPropertyListDataKeyName:originData[@"xinfang_name"], kPropertyListDataKeyTitle:originData[@"xinfang_title"], kPropertyListDataKeyImage:[UIImage imageWithUrlString:originData[@"xinfang_imageUrl"]] }; } if ([manager isKindOfClass:[ErShouFangListAPIManager class]]) { resultData = @{ kPropertyListDataKeyID:originData[@"esf_id"], kPropertyListDataKeyName:originData[@"esf_name"], kPropertyListDataKeyTitle:originData[@"esf_title"], kPropertyListDataKeyImage:[UIImage imageWithUrlString:originData[@"esf_imageUrl"]] }; } return resultData; } |
|
1 2 3 4 5 6 7 8 9 10 11 |
PropertListCell.m #import "PropertyListReformerKeys.h" - (void)configWithData:(NSDictionary *)data { self.imageView.image = data[kPropertyListDataKeyImage]; self.idLabel.text = data[kPropertyListDataKeyID]; self.nameLabel.text = data[kPropertyListDataKeyName]; self.titleLabel.text = data[kPropertyListDataKeyTitle]; } |
這一大段程式碼看下來，我如果不說一下要點，那基本上就白寫了哈：
我們先看一下結構：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
---------------------------------- ----------------------------------------- | | | | | PropertyListReformer.m | | PropertyListReformer.h | | | | | | #import PropertyListReformer.h | <------- | #import "PropertyListReformerKeys.h" | | NSString * const key = @"key" | | | | | | | ---------------------------------- ----------------------------------------- . /|\ | | | | --------------------------------- | | | PropertyListReformerKeys.h | | | | extern NSString * const key; | | | --------------------------------- |
使用Const字串來表徵Key，字串的定義跟著reformer的實現檔案走，字串的extern宣告放在獨立的標頭檔案內。
這樣reformer生成的資料的key都使用Const字串來表示，然後每次別的地方需要使用相關資料的時候，把PropertyListReformerKeys.h這個標頭檔案import進去就好了。
另外要注意的一點是，如果一個OriginData可能會被多個Reformer去處理的話，Key的命名規範需要能夠表徵出其對應的reformer名字。如果reformer是PropertyListReformer，那麼Key的名字就是PropertyListKeyXXXX。
這麼做的好處就是，將來遷移的時候相當方便，只要扔標頭檔案就可以了，只扔標頭檔案是不會導致拔出蘿蔔帶出泥的情況的。而且也避免了自定義物件帶來的額外程式碼體積。
另外，關於交付的NSDictionary，其實具體還是看view的需求，reformer的設計初衷是：通過reformer轉化出來的可以直接是View，或者是view直接可以使用的物件（包括NSDictionary）。比如地圖示點列表API的資料，通過reformer轉化之後就可以直接變成MKAnnotation，然後MKMapView就可以直接使用了。這裡說的只是當你的需求是交付NSDictionary時，如何保證可讀性的情況，再強調一下哈，reformer交付的是view直接可以使用的物件，交付出去的可以是NSDictionary，也可以是UIView，跟DataSource結合之後交付的甚至可以是UITableViewCell/UICollectionViewCell。不要被NSDictionary或所謂的轉化成model再交付的思想侷限。
綜上，我對交付什麼樣的資料給業務層？這個問題的回答就是這樣：
對於業務層而言，由Controller根據View和APIManager之間的關係，選擇合適的reformer將View可以直接使用的資料（甚至reformer可以用來直接生成view）轉化好之後交付給View。對於網路層而言，只需要保持住原始資料即可，不需要主動轉化成資料原型。然後資料採用NSDictionary加Const字串key來表徵，避免了使用物件來表徵帶來的遷移困難，同時不失去可讀性。
集約型API呼叫方式和離散型API呼叫方式的選擇？
集約型API呼叫其實就是所有API的呼叫只有一個類，然後這個類接收API名字，API引數，以及回撥著陸點（可以是target-action，或者block，或者delegate等各種模式的著陸點）作為引數。然後執行類似startRequest這樣的方法，它就會去根據這些引數起飛去呼叫API了，然後獲得API資料之後再根據指定的著陸點去著陸。比如這樣：
|
1 2 3 |
集約型API呼叫方式： [APIRequest startRequestWithApiName:@"itemList.v1" params:params success:@selector(success:) fail:@selector(fail:) target:self]; |
離散型API呼叫是這樣的，一個API對應於一個APIManager，然後這個APIManager只需要提供引數就能起飛，API名字、著陸方式都已經整合入APIManager中。比如這樣：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
離散型API呼叫方式： @property (nonatomic, strong) ItemListAPIManager *itemListAPIManager; // getter - (ItemListAPIManager *)itemListAPIManager { if (_itemListAPIManager == nil) { _itemListAPIManager = [[ItemListAPIManager alloc] init]; _itemListAPIManager.delegate = self; } return _itemListAPIManager; } // 使用的時候就這麼寫： [self.itemListAPIManager loadDataWithParams:params]; |
集約型API呼叫和離散型API呼叫這兩者實現方案不是互斥的，單看下層，大家都是集約型。因為發起一個API請求之後，除去業務相關的部分（比如引數和API名字等），剩下的都是要統一處理的：加密，URL拼接，API請求的起飛和著陸，這些處理如果不用集約化的方式來實現，作者非癲即痴。然而對於整個網路層來說，尤其是業務方使用的那部分，我傾向於提供離散型的API呼叫方式，並不建議在業務層的程式碼直接使用集約型的API呼叫方式。原因如下：
- 原因1：當前請求正在外面飛著的時候，根據不同的業務需求存在兩種不同的請求起飛策略：一個是取消新發起的請求，等待外面飛著的請求著陸。另一個是取消外面飛著的請求，讓新發起的請求起飛。集約化的API呼叫方式如果要滿足這樣的需求，那麼每次要呼叫的時候都要多寫一部分判斷和取消的程式碼，手段就做不到很乾淨。
前者的業務場景舉個例子就是重新整理頁面的請求，重新整理詳情，重新整理列表等。後者的業務場景舉個例子是列表多維度篩選，比如你先篩選了商品型別，然後篩選了價格區間。當然，後者的情況不一定每次篩選都要呼叫API，我們先假設這種篩選每次都必須要通過呼叫API才能獲得資料。
如果是離散型的API呼叫，在編寫不同的APIManager時候就可以針對不同的API設定不同的起飛策略，在實際使用的時候，就可以不必關心起飛策略了，因為APIMananger裡面已經寫好了。
- 原因2：便於針對某個API請求來進行AOP。在集約型的API呼叫方式下，如果要針對某個API請求的起飛和著陸過程進行AOP，這程式碼得寫成什麼樣。。。噢，尼瑪這畫面太美別說看了，我都不敢想。
- 原因3：當API請求的著陸點消失時，離散型的API呼叫方式能夠更加透明地處理這種情況。
當一個頁面的請求正在天上飛的時候，使用者等了好久不耐煩了，小手點了個back，然後ViewController被pop被回收。此時請求的著陸點就沒了。這是很危險的情況，著陸點要是沒了，就很容易crash的。一般來說處理這個情況都是在dealloc的時候取消當前頁面所有的請求。如果是集約型的API呼叫，這個程式碼就要寫到ViewController的dealloc裡面，但如果是離散型的API呼叫，這個程式碼寫到APIManager裡面就可以了，然後隨著ViewController的回收程式，APIManager也會被跟著回收，這部分程式碼就得到了呼叫的機會。這樣業務方在使用的時候就可以不必關心著陸點消失的情況了，從而更加關注業務。
- 原因4：離散型的API呼叫方式能夠最大程度地給業務方提供靈活性，比如reformer機制就是基於離散型的API呼叫方式的。另外，如果是針對提供翻頁機制的API，APIManager就能簡單地提供
loadNextPage方法去載入下一頁，頁碼的管理就不用業務方去管理了。還有就是，如果要針對業務請求引數進行驗證，比如使用者填寫註冊資訊，在離散型的APIManager裡面實現就會非常輕鬆。
綜上，關於集約型的API呼叫和離散型的API呼叫，我傾向於這樣：對外提供一個BaseAPIManager來給業務方做派生，在BaseManager裡面採用集約化的手段組裝請求，放飛請求，然而業務方呼叫API的時候，則是以離散的API呼叫方式來呼叫。如果你的App只提供了集約化的方式，而沒有離散方式的通道，那麼我建議你再封裝一層，便於業務方使用離散的API呼叫方式來放飛請求。
怎麼做APIManager的繼承？
如果要做成離散型的API呼叫，那麼使用繼承是逃不掉的。BaseAPIManager裡面負責集約化的部分，外部派生的XXXAPIManager負責離散的部分，對於BaseAPIManager來說，離散的部分有一些是必要的，比如API名字等，而我們派生的目的，也是為了提供這些資料。
我在這篇文章裡面列舉了種種繼承的壞處，呼籲大家儘量不要使用繼承。但是現在到了不得不用繼承的時候，所以我得提醒一下大家別把繼承用壞了。
在APIManager的情況下，我們最直覺的思路是BaseAPIManager提供一些空方法來給子類做過載，比如apiMethodName這樣的函式，然而我的建議是，不要這麼做。我們可以用IOP的方式來限制派生類的過載。
大概就是長這樣：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
BaseAPIManager的init方法裡這麼寫： // 注意是weak。 @property (nonatomic, weak) id<APIManager> child; - (instancetype)init { self = [super init]; if ([self confirmsToProtocol:@protocol(APIManager)]) { self.child = (id<APIManager>)self; } else { // 不遵守這個protocol的就讓他crash，防止派生類亂來。 NSAssert(NO, "子類必須要實現APIManager這個protocol。"); } return self; } protocol這麼寫，把原本要過載的函式都定義在這個protocol裡面，就不用在父類裡面寫空方法了： @protocol APIManager <NSObject> @required - (NSString *)apiMethodName; ... @end 然後在父類裡面如果要使用的話，就這麼寫： [self requestWithAPIName:[self.child apiMethodName] ......]; |
簡單說就是在init的時候檢查自己是否符合預先設計的子類的protocol，這就要求所有子類必須遵守這個protocol，所有針對父類的過載、覆蓋也都以這個protocol為準，protocol以外的方法不允許過載、覆蓋。而在父類的程式碼裡，可以不必遵守這個protocol，保持了未來維護的靈活性。
這麼做的好處就是避免了父類寫空方法，同時也給子類帶上了緊箍咒：要想當我的孩子，就要遵守這些規矩，不能亂來。業務方在實現子類的時候，就可以根據protocol中的方法去一一實現，然後約定就比較好做了：不允許過載父類方法，只允許選擇實現或不實現protocol中的方法。
關於這個的具體的論述在這篇文章裡面有，感興趣的話可以看看。
網路層與業務層對接部分的小總結
這一節主要是講了以下這些點：
- 使用delegate來做資料對接，僅在必要時採用Notification來做跨層訪問
- 交付NSDictionary給業務層，使用Const字串作為Key來保持可讀性
- 提供reformer機制來處理網路層反饋的資料，這個機制很重要，好處極多
- 網路層上部分使用離散型設計，下部分使用集約型設計
- 設計合理的繼承機制，讓派生出來的APIManager受到限制，避免混亂
- 應該不止這5點…
網路層的安全機制
判斷API的呼叫請求是來自於經過授權的APP
使用這個機制的目的主要有兩點：
- 確保API的呼叫者是來自你自己的APP，防止競爭對手爬你的API
- 如果你對外提供了需要註冊才能使用的API平臺，那麼你需要有這個機制來識別是否是註冊使用者呼叫了你的API
解決方案：設計簽名
要達到第一個目的其實很簡單，服務端需要給你一個金鑰，每次呼叫API時，你使用這個金鑰再加上API名字和API請求引數算一個hash出來，然後請求的時候帶上這個hash。服務端收到請求之後，按照同樣的金鑰同樣的演算法也算一個hash出來，然後跟請求帶來的hash做一個比較，如果一致，那麼就表示這個API的呼叫者確實是你的APP。為了不讓別人也獲取到這個金鑰，你最好不要把這個金鑰儲存在本地，直接寫死在程式碼裡面就好了。另外適當增加一下求Hash的演算法的複雜度，那就是各種Hash演算法（比如MD5）加點鹽，再回爐跑一次Hash啥的。這樣就能解決第一個目的了：確保你的API是來自於你自己的App。
一般情況下大部分公司不會出現需要滿足第二種情況的需求，除非公司開發了自己的API平臺給第三方使用。這個需求跟上面的需求有一點不同：符合授權的API請求者不只是一個。所以在這種情況下，需要的安全機制會更加複雜一點。
這裡有一個較容易實現的方案：客戶端呼叫API的時候，把自己的金鑰通過一個可逆的加密演算法加密後連著請求和加密之後的Hash一起送上去。當然，這個可逆的加密演算法肯定是放在在呼叫API的SDK裡面，編譯好的。然後服務端拿到加密後的金鑰和加密的Hash之後，解碼得到原始金鑰，然後再用它去算Hash，最後再進行比對。
保證傳輸資料的安全
使用這個機制的主要目的有兩點：
- 防止中間人攻擊，比如說運營商很喜歡往使用者的Http請求裡面塞廣告…
- SPDY依賴於HTTPS，而且是未來HTTP/2的基礎，他們能夠提高你APP在網路層整體的效能。
解決方案：HTTPS
目前使用HTTPS的主要目的在於防止運營商往你的Response Data裡面加廣告啥的（中間人攻擊），面對的威脅範圍更廣。從2011年開始，國外業界就已經提倡所有的請求（不光是API，還有網站）都走HTTPS，國內差不多晚了兩年（2013年左右）才開始提倡這事，天貓是這兩個月才開始做HTTPS的全APP遷移。
關於速度，HTTPS肯定是比HTTP慢的，畢竟多了一次握手，但掛上SPDY之後，有了連結複用，這方面的效能就有了較大提升。這裡的效能提升並不是說一個請求原來要500ms能完成，然後現在只要300ms，這是不對的。所謂整體效能是基於大量請求去討論的：同樣的請求量（假設100個）在短期發生時，掛上SPDY之後完成這些任務所要花的時間比不用SPDY要少。SPDY還有Header壓縮的功能，不過因為一個API請求本身已經比較小了，壓縮資料量所帶來的效能提升不會特別明顯，所以就單個請求來看，效能的提升是比較小的。不過這是下一節要討論的事兒了，這兒只是順帶說一下。
安全機制小總結
這一節說了兩種安全機制，一般來說第一種是標配，第二種屬於可選配置。不過隨著我國網際網路基礎設施的完善，移動裝置效能的提高，以及優化技術的提高，第二種配置的缺點（速度慢）正在越來越微不足道，因此HTTPS也會成為不久之後的未來App的網路層安全機制標配。各位架構師們，如果你的App還沒有掛HTTPS，現在就已經可以開始著手這件事情了。
網路層的優化方案
網路層的優化手段主要從以下三方面考慮：
- 針對連結建立環節的優化
- 針對連結傳輸資料量的優化
- 針對連結複用的優化
這三方面是所有優化手段的內容，各種五花八門的優化手段基本上都不會逃脫這三方面，下面我就會分別針對這三方面講一下各自對應的優化手段。
1. 針對連結建立環節的優化
在API發起請求建立連結的環節，大致會分這些步驟：
- 發起請求
- DNS域名解析得到IP
- 根據IP進行三次握手（HTTPS四次握手），連結建立成功
其實第三步的優化手段跟第二步的優化手段是一致的，我會在講第二步的時候一起講掉。
1.1 針對發起請求的優化手段
其實要解決的問題就是網路層該不該為此API呼叫發起請求。
- 1.1.1 使用快取手段減少請求的發起次數
對於大部分API呼叫請求來說，有些API請求所帶來的資料的時效性是比較長的，比如商品詳情，比如App皮膚等。那麼我們就可以針對這些資料做本地快取，這樣下次請求這些資料的時候就可以不必再發起新的請求。
一般是把API名字和引數拼成一個字串然後取MD5作為key，儲存對應返回的資料。這樣下次有同樣請求的時候就可以直接讀取這裡面的資料。關於這裡有一個快取策略的問題需要討論：什麼時候清理快取？要麼就是根據超時時間限制進行清理，要麼就是根據快取資料大小進行清理。這個策略的選擇要根據具體App的操作日誌來決定。
比如安居客App，日誌資料記錄顯示使用者平均使用時長不到3分鐘，但是使用者檢視房源詳情的次數比較多，而房源詳情資料量較大。那麼這個時候，就適合根據使用時長來做快取，我當時給安居客設定的快取超時時間就是3分鐘，這樣能夠保證這個快取能夠在大部分使用者使用時間產生作用。嗯，極端情況下做什麼快取手段不考慮，只要能夠服務好80%的使用者就可以了，而且針對極端情況採用的優化手段對大部分普通使用者而言是不必要的，做了反而會對他們有影響。
再比如網路圖片快取，資料量基本上都特別大，這種就比較適合針對快取大小來清理快取的策略。
另外，之前的快取的前提都是基於記憶體的。我們也可以把需要清理的快取儲存在硬碟上（APP的本地儲存，我就先用硬碟來表示了，雖然很少有手機硬碟的說法，哈哈），比如前面提到的圖片快取，因為圖片很有可能在很長時間之後，再被顯示的，那麼原本需要被清理的圖片快取，我們就可以考慮存到硬碟上去。當下次再有顯示網路圖片的需求的時候，我們可以先從記憶體中找，記憶體找不到那就從硬碟上找，這都找不到，那就發起請求吧。
當然，有些時效性非常短的API資料，就不能使用這個方法了，比如使用者的資金資料，那就需要每次都呼叫了。
- 1.1.2 使用策略來減少請求的發起次數
這個我在前面提到過，就是針對重複請求的發起和取消，是有對應的請求策略的。我們先說取消策略。
如果是介面重新整理請求這種，而且存在重複請求的情況（下拉重新整理時，在請求著陸之前使用者不斷執行下拉操作），那麼這個時候，後面重複操作導致的API請求就可以不必傳送了。
如果是條件篩選這種，那就取消前面已經傳送的請求。雖然很有可能這個請求已經被執行了，那麼取消所帶來的效能提升就基本沒有了。但如果這個請求還在佇列中待執行的話，那麼對應的這次連結就可以省掉了。
以上是一種，另外一種情況就是請求策略：類似使用者操作日誌的請求策略。
使用者操作會觸發操作日誌上報Server，這種請求特別頻繁，但是是暗地裡進行的，不需要使用者對此有所感知。所以也沒必要操作一次就發起一次的請求。在這裡就可以採用這樣的策略：在本地記錄使用者的操作記錄，當記錄滿30條的時候發起一次請求將操作記錄上傳到伺服器。然後每次App啟動的時候，上傳一次上次遺留下來沒上傳的操作記錄。這樣能夠有效降低使用者裝置的耗電量，同時提升網路層的效能。
小總結
針對建立連線這部分的優化就是這樣的原則：能不發請求的就儘量不發請求，必須要發請求時，能合併請求的就儘量合併請求。然而，任何優化手段都是有前提的，而且也不能保證對所有需求都能起作用，有些API請求就是不符合這些優化手段前提的，那就老老實實發請求吧。不過這類API請求所佔比例一般不大，大部分的請求都或多或少符合優化條件，所以針對傳送請求的優化手段還是值得做的。
1.2 & 1.3 針對DNS域名解析做的優化，以及建立連結的優化
其實在整個DNS鏈路上也是有DNS快取的，理論上也是能夠提高速度的。這個鏈路上的DNS快取在PC使用者上效果明顯，因為PC使用者的DNS鏈路相對穩定，訊號源不會變來變去。但是在移動裝置的使用者這邊，鏈路上的DNS快取所帶來的效能提升就不太明顯了。因為移動裝置的實際使用場景比較複雜，網路訊號源會經常變換，訊號源每變換一次，對應的DNS解析鏈路就會變換一次，那麼原鏈路上的DNS快取就不起作用了。而且訊號源變換的情況特別特別頻繁，所以對於移動裝置使用者來說，鏈路的DNS快取我們基本上可以預設為沒有。所以大部分時間是手機系統自帶的本地DNS快取在起作用，但是一般來說，移動裝置上網的需求也特別頻繁，專門為我們這個App所做的DNS快取很有可能會被別的DNS快取給擠出去被清理掉，這種情況是特別多的，使用者看一會兒知乎刷一下微博查一下地圖逛一逛點評再聊個Q，回來之後很有可能屬於你自己的App的本地DNS快取就沒了。這還沒完，這裡還有一個只有在中國特色社會主義的網際網路環境中才會有的問題：國內的網際網路環境由於GFW的存在，就使得DNS服務速度會比正常情況慢不少。
基於以上三個原因所導致的最終結果就是，API請求在DNS解析階段的耗時會很多。
那麼針對這個的優化方案就是，索性直接走IP請求，那不就繞過DNS服務的耗時了嘛。
另外一個，就是上面提到的建立連結時候的第三步，國內的網路環境分北網通南電信（當然實際情況更復雜，這裡隨便說說），不同服務商之間的連線，延時是很大的，我們需要想辦法讓使用者在最適合他的IP上給他提供服務，那麼就針對我們繞過DNS服務的手段有一個額外要求：儘可能不要讓使用者使用對他來說很慢的IP。
所以綜上所述，方案就應該是這樣：本地有一份IP列表，這些IP是所有提供API的伺服器的IP，每次應用啟動的時候，針對這個列表裡的所有IP取ping延時時間，然後取延時時間最小的那個IP作為今後發起請求的IP地址。
針對建立連線的優化手段其實是跟DNS域名解析的優化手段是一樣的。不過這需要你的伺服器提供服務的網路情況要多，一般現在的伺服器都是雙網路卡，電信和網通。由於中國特色的網際網路ISP分佈，南北網路之間存在瓶頸，而我們App針對連結的優化手段主要就是著手於如何減輕這個瓶頸對App產生的影響，所以需要維護一個IP列表，這樣就能就近連線了，就起到了優化的效果。
我們一般都是在應用啟動的時候獲得本地列表中所有IP的ping值，然後通過NSURLProtocol的手段將URL中的HOST修改為我們找到的最快的IP。另外，這個本地IP列表也會需要通過一個API來維護，一般是每天第一次啟動的時候讀一次API，然後更新到本地。
如果你還不熟悉NSURLProtocol應該怎麼玩，看完官方文件和這篇文章以及這個Demo之後，你肯定就會了，其實很簡單的。另外，剛才提到那篇文章的作者(mattt)還寫了這個基於NSURLProtocol的工具，相當好用，是可以直接拿來整合到專案中的。
不用NSURLProtocol的話，用其他手段也可以做到這一點，但那些手段未免又比較愚蠢。
2. 針對連結傳輸資料量的優化
這個很好理解，傳輸的資料少了，那麼自然速度就上去了。這裡沒什麼花樣可以講的，就是壓縮唄。各種壓縮。
3. 針對連結複用的優化
建立連結本身是屬於比較消耗資源的操作，耗電耗時。SPDY自帶連結複用以及資料壓縮的功能，所以服務端支援SPDY的時候，App直接掛SPDY就可以了。如果服務端不支援SPDY，也可以使用PipeLine，蘋果原生自帶這個功能。
一般來說業界內普遍的認識是SPDY優於PipeLine，然後即便如此，SPDY能夠帶來的網路層效率提升其實也沒有文獻上的圖表那麼明顯，但還是有效能提升的。還有另外一種比較笨的連結複用的方法，就是維護一個佇列，然後將佇列裡的請求壓縮成一個請求發出去，之所以會存在滯留在佇列中的請求，是因為在上一個請求還在外面飄的時候。這種做法最終的效果表面上看跟連結複用差別不大，但並不是真正的連結複用，只能說是請求合併。
還是說回來，我建議最好是用SPDY，SPDY和pipeline雖然都屬於連結複用的範疇，但是pipeline並不是真正意義上的連結複用，SPDY的連結複用相對pipeline而言更為徹底。SPDY目前也有現成的客戶端SDK可以使用，一個是twitter的CocoaSPDY，另一個是Voxer/iSPDY，這兩個庫都很活躍，大家可以挑合適的採用。
不過目前業界趨勢是傾向於使用HTTP/2.0來代替SPDY，不過目前HTTP/2.0還沒有正式出臺，相關實現大部分都處在demo階段，所以我們還是先SPDY搞起就好了。未來很有可能會放棄SPDY，轉而採用HTTP/2.0來實現網路的優化。這是要提醒各位架構師注意的事情。嗯，我也不知道HTTP/2.0什麼時候能出來。
漁說完了，魚來了
這裡是我當年設計並實現的安居客的網路層架構程式碼。當然，該脫敏的地方我都已經脫敏了，所以編不過是正常的，哈哈哈。但是程式碼比較齊全，重要地方註釋我也寫了很多。另外，為了讓大家能夠把這些程式碼看明白，我還附帶了當年介紹這個框架演講時的PPT。(補充說明一下，評論區好多人問PPT找不著在哪兒，PPT也在上面提到的repo裡面，是個key字尾名的檔案，用keynote開啟)
然後就是，當年也有很多問題其實考慮得並沒有現在清楚，所以有些地方還是做得不夠好，比如攔截器和繼承。而且當時的優化手段只有本地cache，安居客沒有那麼多IP可以給我ping，當年也沒流行SPDY，而且API也還不支援HTTPS，所以當時的程式碼裡面沒有在這些地方做優化，比較原始。然而整個架構的基本思路一直沒有變化：優先服務於業務方。另外，安居客的網路層多了一個service的概念，這是我這篇文章中沒有講的。主要是因為安居客的API提供方很多，二手房，租房，新房，X專案等等API都是不同的API team提供的，以service作區分，如果你的app也是類似的情況，我也建議你設計一套service機制。現在這些service被我刪得只剩下一個google的service，因為其他service都屬於敏感內容。
另外，這裡面提供的PPT我很希望大家能夠花時間去看看，在PPT裡面有些更加細的東西我在部落格裡沒有寫，主要是我比較懶，然後這篇文章拖的時間比較長了，花時間搬運這個沒什麼意思，不過內容還是值得各位讀者去看的。關於PPT裡面大家有什麼問題的，也可以在評論區問，我都會回答。
總結
第一部分主要講了網路層應當如何跟業務層進行資料互動，進行資料互動時採用怎樣的資料格式，以及設計時程式碼結構上的一些問題，諸如繼承的處理，回撥的處理，互動方式的選擇，reformer的設計，保持資料可讀性等等等等，主要偏重於設計（這可是藝術活，哈哈哈）。
第二部分講了網路安全上，客戶端要做的兩點。當然，從網路安全的角度上講，服務端也要做很多很多事情，客戶端要做的一些邊角細節的事情也還會有很多，比如做一些程式碼混淆，儘可能避免程式碼中明文展示key。不過大頭主要就是這兩個，而且也都是需要服務端同學去配合的。主要偏重於介紹。（主要是也沒啥好實踐的，google一下教程照著來就好了）。
第三部分講了優化，優化的所有方面都已經列出來了，如果業界再有七七八八的別的手段，也基本逃離不出本文的範圍。這裡有些優化手段是需要服務端同學配合的，有些不需要，大家看各自情況來決定。主要偏重於實踐。
最後給出了我之前在安居客做的網路層架構的主要程式碼，以及當時演講時的PPT。關於程式碼或PPT中有任何問題，都可以在評論區問我。
這一篇文章出得比較晚，因為公司的事情，中間間隔了一個禮拜，希望大家諒解。另外，隔了一個禮拜之後我再寫，發現有些地方我已經想不起來當初是應該怎麼行文下去的了，然後發之前我把文章又看了幾遍，儘可能把斷片的地方抹平了，如果大家讀起來有什麼地方感覺奇怪的，或者講到一半就沒了的，那應該就是斷片了。在評論區跟我說一下，我補上去。
然後如果有需要勘誤的地方，也請在評論區指出，幫助我把錯的地方訂正回來，如果有沒講到的地方，但你又特別想要了解的，也可以在評論區提出來，我會補上去。說不定看完之後你腦袋裡還會有很多個問號，也請在評論區問出來哈，說不定別人也有跟你一樣的問題，他就能在評論區找到答案了。
在第二篇文章的評論區裡面出現了噴子，遇到這種情況我怎麼可能刪帖呢？那根本就不是我的風格哇，哈哈哈。我肯定是會噴回去的，並且還會把連結傳播給周圍人，發動周圍朋友來看:”快看，這兒有2B，哈哈哈”。
嗯，所以評論的時候你一定要想清楚哈，我寫程式碼的實力不差，打嘴仗的實力那可比寫程式碼強多了。評論區同樣歡迎切磋。