轉(zhuǎn)載自：iOS應(yīng)用架構(gòu)談 網(wǎng)絡(luò)層設(shè)計(jì)方案
iOS應(yīng)用架構(gòu)談 開(kāi)篇
iOS應(yīng)用架構(gòu)談 view層的組織和調(diào)用方案
iOS應(yīng)用架構(gòu)談 網(wǎng)絡(luò)層設(shè)計(jì)方案
iOS應(yīng)用架構(gòu)談 本地持久化方案及動(dòng)態(tài)部署
iOS應(yīng)用架構(gòu)談 組件化方案
前言
網(wǎng)絡(luò)層在一個(gè)App中也是一個(gè)不可缺少的部分痴晦，工程師們?cè)诰W(wǎng)絡(luò)層能夠發(fā)揮的空間也比較大庵佣。另外贯溅，蘋果對(duì)網(wǎng)絡(luò)請(qǐng)求部分已經(jīng)做了很好的封裝厨剪，業(yè)界的AFNetworking也被廣泛使用剂跟。其它的ASIHttpRequest振坚，MKNetworkKit啥的其實(shí)也都還不錯(cuò)丹禀，但前者已經(jīng)棄坑唱逢，后者也在棄坑的邊緣粤铭。在實(shí)際的App開(kāi)發(fā)中挖胃，Afnetworking已經(jīng)成為了事實(shí)上各大App的標(biāo)準(zhǔn)配置。
網(wǎng)絡(luò)層在一個(gè)App中承載了API調(diào)用梆惯，用戶操作日志記錄酱鸭，甚至是即時(shí)通訊等任務(wù)。我接觸過(guò)一些App（開(kāi)源的和不開(kāi)源的）的代碼垛吗，在看到網(wǎng)絡(luò)層這一塊時(shí)凹髓，尤其是在看到各位架構(gòu)師各顯神通展示了各種技巧，我非常為之感到興奮怯屉。但有的時(shí)候蔚舀，往往也對(duì)于其中的一些缺陷感到失望。
關(guān)于網(wǎng)絡(luò)層的設(shè)計(jì)方案會(huì)有很多锨络，需要權(quán)衡的地方也會(huì)有很多赌躺，甚至于爭(zhēng)議的地方都會(huì)有很多。但無(wú)論如何羡儿，我都不會(huì)對(duì)這些問(wèn)題做出任何逃避礼患，我會(huì)在這篇文章中給出我對(duì)它們的看法和解決方案，觀點(diǎn)絕不中立掠归，不會(huì)跟大家打太極缅叠。
這篇文章就主要會(huì)講這些方面：
- 網(wǎng)絡(luò)層跟業(yè)務(wù)對(duì)接部分的設(shè)計(jì)
- 網(wǎng)絡(luò)層的安全機(jī)制實(shí)現(xiàn)
- 網(wǎng)絡(luò)層的優(yōu)化方案
網(wǎng)絡(luò)層跟業(yè)務(wù)對(duì)接部分的設(shè)計(jì)
在安居客App的架構(gòu)更新?lián)Q代的時(shí)候，我深深地感覺(jué)到網(wǎng)絡(luò)層跟業(yè)務(wù)對(duì)接部分的設(shè)計(jì)有多么重要虏冻，因此我對(duì)它做的最大改變就是針對(duì)網(wǎng)絡(luò)層跟業(yè)務(wù)對(duì)接部分的改變肤粱。網(wǎng)絡(luò)層跟業(yè)務(wù)層對(duì)接部分設(shè)計(jì)的好壞，會(huì)直接影響到業(yè)務(wù)工程師實(shí)現(xiàn)功能時(shí)的心情兄旬。
在正式開(kāi)始講設(shè)計(jì)之前狼犯，我們要先討論幾個(gè)問(wèn)題：
- 使用哪種交互模式來(lái)跟業(yè)務(wù)層做對(duì)接余寥？
- 是否有必要將API返回的數(shù)據(jù)封裝成對(duì)象然后再交付給業(yè)務(wù)層？
- 使用集約化調(diào)用方式還是離散型調(diào)用方式去調(diào)用API悯森？
這些問(wèn)題討論完畢之后宋舷，我會(huì)給出一個(gè)完整的設(shè)計(jì)方案來(lái)給大家做參考，設(shè)計(jì)方案是魚瓢姻，討論的這些問(wèn)題是漁祝蝠，我什么都授了，大家各取所需幻碱。
使用哪種交互模式來(lái)跟業(yè)務(wù)層做對(duì)接绎狭？
這里其實(shí)有兩個(gè)問(wèn)題：
- 以什么方式將數(shù)據(jù)交付給業(yè)務(wù)層？
- 交付什么樣的數(shù)據(jù)給業(yè)務(wù)層褥傍？
以什么方式將數(shù)據(jù)交付給業(yè)務(wù)層儡嘶？
iOS開(kāi)發(fā)領(lǐng)域有很多對(duì)象間數(shù)據(jù)的傳遞方式，我看到的大多數(shù)App在網(wǎng)絡(luò)層所采用的方案主要集中于這三種：Delegate恍风，Notification蹦狂，Block。KVO和Target-Action我目前還沒(méi)有看到有使用的朋贬。
目前我知道邊鋒主要是采用的block凯楔，大智慧主要采用的是Notification，安居客早期以Block為主锦募，后面改成了以Delegate為主摆屯，阿里沒(méi)發(fā)現(xiàn)有通過(guò)Notification來(lái)做數(shù)據(jù)傳遞的地方（可能有），Delegate糠亩、Block以及target-action都有虐骑，阿里iOS App網(wǎng)絡(luò)層的作者說(shuō)這是為了方便業(yè)務(wù)層選擇自己合適的方法去使用。這里大家都是各顯神通削解，每次我看到這部分的時(shí)候富弦，我都喜歡問(wèn)作者為什么采用這種交互方案沟娱，但很少有作者能夠說(shuō)出個(gè)條條框框來(lái)氛驮。
然而在我這邊，我的意見(jiàn)是以Delegate為主济似，Notification為輔矫废。原因如下：
- 盡可能減少跨層數(shù)據(jù)交流的可能，限制耦合
- 統(tǒng)一回調(diào)方法砰蠢，便于調(diào)試和維護(hù)
- 在跟業(yè)務(wù)層對(duì)接的部分只采用一種對(duì)接手段（在我這兒就是只采用delegate這一個(gè)手段）限制靈活性蓖扑，以此來(lái)交換應(yīng)用的可維護(hù)性
盡可能減少跨層數(shù)據(jù)交流的可能，限制耦合
什么叫跨層數(shù)據(jù)交流台舱？就是某一層（或模塊）跟另外的與之沒(méi)有直接對(duì)接關(guān)系的層（或模塊）產(chǎn)生了數(shù)據(jù)交換律杠。為什么這種情況不好潭流？嚴(yán)格來(lái)說(shuō)應(yīng)該是大部分情況都不好，有的時(shí)候跨層數(shù)據(jù)交流確實(shí)也是一種需求柜去。之所以說(shuō)不好的地方在于灰嫉，它會(huì)導(dǎo)致代碼混亂，破壞模塊的封裝性嗓奢。我們?cè)谧龇謱蛹軜?gòu)的目的其中之一就在于下層對(duì)上層有一次抽象讼撒，讓上層可以不必關(guān)心下層細(xì)節(jié)而執(zhí)行自己的業(yè)務(wù)。
所以股耽，如果下層細(xì)節(jié)被跨層暴露根盒，一方面你很容易因此失去鄰層對(duì)這個(gè)暴露細(xì)節(jié)的保護(hù)；另一方面物蝙，你又不可能不去處理這個(gè)細(xì)節(jié)炎滞，所以處理細(xì)節(jié)的相關(guān)代碼就會(huì)散落各地，最終難以維護(hù)诬乞。
說(shuō)得具象一點(diǎn)就是厂榛，我們考慮這樣一種情況：A<-B<-C。當(dāng)C有什么事件丽惭，通過(guò)某種方式告知B击奶，然后B執(zhí)行相應(yīng)的邏輯。一旦告知方式不合理责掏，讓A有了跨層知道C的事件的可能柜砾，你 就很難保證A層業(yè)務(wù)工程師在將來(lái)不會(huì)對(duì)這個(gè)細(xì)節(jié)作處理。一旦業(yè)務(wù)工程師在A層產(chǎn)生處理操作换衬，有可能是補(bǔ)充邏輯痰驱，也有可能是執(zhí)行業(yè)務(wù)，那么這個(gè)細(xì)節(jié)的相關(guān)處理代碼就會(huì)有一部分散落在A層瞳浦。然而前者是不應(yīng)該散落在A層的担映，后者有可能是需求。另外叫潦，因?yàn)锽層是對(duì)A層抽象的蝇完，執(zhí)行補(bǔ)充邏輯的時(shí)候，有可能和B層針對(duì)這個(gè)事件的處理邏輯產(chǎn)生沖突矗蕊，這是我們很不希望看到的短蜕。
那么什么情況跨層數(shù)據(jù)交流會(huì)成為需求？在網(wǎng)絡(luò)層這邊傻咖，信號(hào)從2G變成3G變成4G變成Wi-Fi朋魔，這個(gè)是跨層數(shù)據(jù)交流的其中一個(gè)需求。不過(guò)其他的跨層數(shù)據(jù)交流需求我暫時(shí)也想不到了卿操，哈哈警检，應(yīng)該也就這一個(gè)吧孙援。
嚴(yán)格來(lái)說(shuō)，使用Notification來(lái)進(jìn)行網(wǎng)絡(luò)層和業(yè)務(wù)層之間數(shù)據(jù)的交換扇雕，并不代表這一定就是跨層數(shù)據(jù)交流赃磨，但是使用Notification給跨層數(shù)據(jù)交流開(kāi)了一道口子，因?yàn)镹otification的影響面不可控制洼裤，只要存在實(shí)例就存在被影響的可能邻辉。另外，這也會(huì)導(dǎo)致誰(shuí)都不能保證相關(guān)處理代碼就在唯一的那個(gè)地方腮鞍，進(jìn)而帶來(lái)維護(hù)災(zāi)難值骇。作為架構(gòu)師，在這里給業(yè)務(wù)工程師限制其操作的靈活性是必要的移国。另外吱瘩，Notification也支持一對(duì)多的情況，這也給代碼散落提供了條件迹缀。同時(shí)使碾，Notification所對(duì)應(yīng)的響應(yīng)方法很難在編譯層面作限制，不同的業(yè)務(wù)工程師會(huì)給他取不同的名字祝懂，這也會(huì)給代碼的可維護(hù)性帶來(lái)災(zāi)難票摇。
手機(jī)淘寶架構(gòu)組的俠武同學(xué)曾經(jīng)給我分享過(guò)一個(gè)問(wèn)題，在這里我也分享給大家：曾經(jīng)有一個(gè)工程師在監(jiān)聽(tīng)Notification之后砚蓬，沒(méi)有寫釋放監(jiān)聽(tīng)的代碼矢门，當(dāng)然，找到這個(gè)原因又是很漫長(zhǎng)的一段故事灰蛙，現(xiàn)在找到原因了祟剔，然而監(jiān)聽(tīng)這個(gè)Notification的對(duì)象有那么多，不知道具體是哪個(gè)Notificaiton摩梧，也不知道那個(gè)沒(méi)釋放監(jiān)聽(tīng)的對(duì)象是誰(shuí)物延。后來(lái)折騰了很久大家都沒(méi)辦法的時(shí)候，有一個(gè)經(jīng)驗(yàn)豐富的工程師提出用hook（Method Swizzling）的方式仅父，最終找到了那個(gè)沒(méi)釋放監(jiān)聽(tīng)的對(duì)象叛薯，bug修復(fù)了。
我分享這個(gè)問(wèn)題的目的并不是想強(qiáng)調(diào)Notification多么多么不好驾霜，Notification本身就是一種設(shè)計(jì)模式案训，在屬于他的問(wèn)題領(lǐng)域內(nèi)买置，Notification是非常好的一種解決方案粪糙。但我想強(qiáng)調(diào)的是，對(duì)于網(wǎng)絡(luò)層這個(gè)問(wèn)題領(lǐng)域內(nèi)來(lái)看忿项，架構(gòu)師首先一定要限制代碼的影響范圍蓉冈，在能用影響范圍小的方案的時(shí)候就盡量采用這種小的方案城舞，否則將來(lái)要是有什么奇怪需求或者出了什么小問(wèn)題，維護(hù)起來(lái)就非常麻煩寞酿。因此Notification這個(gè)方案不能作為首選方案家夺，只能作為備選。
那么Notification也不是完全不能使用伐弹，當(dāng)需求要求跨層時(shí)拉馋，我們就可以使用Notification，比如前面提到的網(wǎng)絡(luò)條件切換惨好，而且這個(gè)需求也是需要滿足一對(duì)多的煌茴。
所以，為了符合前面所說(shuō)的這些要求日川，使用Delegate能夠很好地避免跨層訪問(wèn)蔓腐，同時(shí)限制了響應(yīng)代碼的形式，相比Notification而言有更好的可維護(hù)性龄句。
然后我們順便來(lái)說(shuō)說(shuō)為什么盡量不要用block。
- block很難追蹤，難以維護(hù)
我們?cè)谡{(diào)試的時(shí)候經(jīng)常會(huì)單步追蹤到某一個(gè)地方之后侥猬，發(fā)現(xiàn)尼瑪這里有個(gè)block勒叠，如果想知道這個(gè)block里面都做了些什么事情，這時(shí)候就比較蛋疼了职抡。
- (void)someFunctionWithBlock:(SomeBlock *)block
{
... ...
-> block(); //當(dāng)你單步走到這兒的時(shí)候僚害，要想知道block里面都做了哪些事情的話，就很麻煩繁调。
... ...
}
- block會(huì)延長(zhǎng)相關(guān)對(duì)象的生命周期
block會(huì)給內(nèi)部所有的對(duì)象引用計(jì)數(shù)加一萨蚕，這一方面會(huì)帶來(lái)潛在的retain cycle，不過(guò)我們可以通過(guò)Weak Self的手段解決蹄胰。另一方面比較重要就是岳遥，它會(huì)延長(zhǎng)對(duì)象的生命周期。
在網(wǎng)絡(luò)回調(diào)中使用block裕寨，是block導(dǎo)致對(duì)象生命周期被延長(zhǎng)的其中一個(gè)場(chǎng)合浩蓉，當(dāng)ViewController從window中卸下時(shí)，如果尚有請(qǐng)求帶著block在外面飛宾袜，然后block里面引用了ViewController（這種場(chǎng)合非常常見(jiàn)）捻艳，那么ViewController是不能被及時(shí)回收的，即便你已經(jīng)取消了請(qǐng)求庆猫，那也還是必須得等到請(qǐng)求著陸之后才能被回收认轨。
然而使用delegate就不會(huì)有這樣的問(wèn)題，delegate是弱引用月培，哪怕請(qǐng)求仍然在外面飛嘁字，恩急，ViewController還是能夠及時(shí)被回收的，回收之后指針自動(dòng)被置為了nil纪蜒，無(wú)傷大雅衷恭。
- block在離散型場(chǎng)景下不符合使用的規(guī)范
block和delegate乍看上去在作用上是很相似，但是關(guān)于它們的選型有一條嚴(yán)格的規(guī)范：當(dāng)回調(diào)之后要做的任務(wù)在每次回調(diào)時(shí)都是一致的情況下纯续，選擇delegate随珠，在回調(diào)之后要做的任務(wù)在每次回調(diào)時(shí)無(wú)法保證一致，選擇block猬错。在離散型調(diào)用的場(chǎng)景下牙丽，每一次回調(diào)都是能夠保證任務(wù)一致的，因此適用delegate兔魂。這也是蘋果原生的網(wǎng)絡(luò)調(diào)用也采用delegate的原因烤芦，因?yàn)樘O果也是基于離散模型去設(shè)計(jì)網(wǎng)絡(luò)調(diào)用的，而且本文即將要介紹的網(wǎng)絡(luò)層架構(gòu)也是基于離散型調(diào)用的思路去設(shè)計(jì)的析校。
在集約型調(diào)用的場(chǎng)景下构罗，使用block是合理的，因?yàn)槊看握?qǐng)求的類型都不一樣智玻，那么自然回調(diào)要做的任務(wù)也都會(huì)不一樣遂唧，因此只能采用block。AFNetworking就是屬于集約型調(diào)用吊奢，因此它采用了block來(lái)做回調(diào)盖彭。
就我所知，目前大部分公司的App網(wǎng)絡(luò)層都是集約型調(diào)用页滚，因此廣泛采取了block回調(diào)召边。但是在App的網(wǎng)絡(luò)層架構(gòu)設(shè)計(jì)中直接采用集約型調(diào)用來(lái)為業(yè)務(wù)服務(wù)的思路是有問(wèn)題的，因此在遷移到離散型調(diào)用時(shí)裹驰，一定要注意這一點(diǎn)隧熙，記得遷回delegate回調(diào)。關(guān)于離散型和集約型調(diào)用的介紹和如何選型幻林，我在后面的集約型API調(diào)用方式和離散型API調(diào)用方式的選擇贞盯？小節(jié)中有詳細(xì)的介紹。
所以平時(shí)盡量不要濫用block沪饺，尤其是在網(wǎng)絡(luò)層這里躏敢。
統(tǒng)一回調(diào)方法，便于調(diào)試和維護(hù)
前面講的是跨層問(wèn)題整葡，區(qū)分了Delegate和Notification件余，順帶談了一下Block。然后現(xiàn)在談到的這個(gè)情況，就是另一個(gè)采用Block方案不是很合適的情況蛾扇。首先攘烛，Block本身無(wú)好壞對(duì)錯(cuò)之分魏滚，只有合適不合適镀首。在這一節(jié)要講的情況里，Block無(wú)法做到回調(diào)方法的統(tǒng)一鼠次，調(diào)試和維護(hù)的時(shí)候也很難在調(diào)用棧上顯示出來(lái)更哄，找的時(shí)候會(huì)很蛋疼。
在網(wǎng)絡(luò)請(qǐng)求和網(wǎng)絡(luò)層接受請(qǐng)求的地方時(shí)腥寇，使用Block沒(méi)問(wèn)題成翩。但是在獲得數(shù)據(jù)交給業(yè)務(wù)方時(shí)，最好還是通過(guò)Delegate去通知到業(yè)務(wù)方赦役。因?yàn)锽lock所包含的回調(diào)代碼跟調(diào)用邏輯放在同一個(gè)地方麻敌，會(huì)導(dǎo)致那部分代碼變得很長(zhǎng)，因?yàn)檫@里面包括了調(diào)用前和調(diào)用后的邏輯掂摔。從另一個(gè)角度說(shuō)术羔，這在一定程度上違背了single function，single task的原則乙漓，在需要調(diào)用API的地方级历，就只要寫API調(diào)用相關(guān)的代碼，在回調(diào)的地方叭披，寫回調(diào)的代碼寥殖。
然后我看到大部分App里，當(dāng)業(yè)務(wù)工程師寫代碼寫到這邊的時(shí)候涩蜘，也意識(shí)到了這個(gè)問(wèn)題嚼贡。因此他們會(huì)在block里面寫個(gè)一句話的方法接收參數(shù)，然后做轉(zhuǎn)發(fā)同诫，然后就可以把這個(gè)方法放在其他地方了编曼，繞過(guò)了Block的回調(diào)著陸點(diǎn)不統(tǒng)一的情況。比如這樣：
[API callApiWithParam:param successed:^(Response *response){
[self successedWithResponse:response];
} failed:^(Request *request, NSError *error){
[self failedWithRequest:request error:error];
}];
這實(shí)質(zhì)上跟使用Delegate的手段沒(méi)有什么區(qū)別剩辟，只是繞了一下掐场，不過(guò)還是沒(méi)有解決統(tǒng)一回調(diào)方法的問(wèn)題，因?yàn)閎lock里面寫的方法名字可能在不同的ViewController對(duì)象中都會(huì)不一樣贩猎，畢竟業(yè)務(wù)工程師也是很多人熊户，各人有各人的想法。所以架構(gòu)師在這邊不要貪圖方便吭服，還是使用delegate的手段吧嚷堡，業(yè)務(wù)工程師那邊就能不用那么繞了。Block是目前大部分第三方網(wǎng)絡(luò)庫(kù)都采用的方式，因?yàn)樵诎l(fā)送請(qǐng)求的那一部分蝌戒，使用Block能夠比較簡(jiǎn)潔串塑，因此在請(qǐng)求那一層是沒(méi)有問(wèn)題的，只是在交換數(shù)據(jù)之后北苟，還是轉(zhuǎn)變成delegate比較好桩匪，比如AFNetworking里面：
[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];
}
}];
這樣在業(yè)務(wù)方這邊回調(diào)函數(shù)就能夠比較統(tǒng)一，便于維護(hù)友鼻。
綜上傻昙，對(duì)于以什么方式將數(shù)據(jù)交付給業(yè)務(wù)層？這個(gè)問(wèn)題的回答是這樣：
盡可能通過(guò)Delegate的回調(diào)方式交付數(shù)據(jù)彩扔，這樣可以避免不必要的跨層訪問(wèn)妆档。當(dāng)出現(xiàn)跨層訪問(wèn)的需求時(shí)（比如信號(hào)類型切換），通過(guò)Notification的方式交付數(shù)據(jù)虫碉。正常情況下應(yīng)該是避免使用Block的贾惦。
交付什么樣的數(shù)據(jù)給業(yè)務(wù)層？
我見(jiàn)過(guò)非常多的App的網(wǎng)絡(luò)層在拿到JSON數(shù)據(jù)之后敦捧，會(huì)將數(shù)據(jù)轉(zhuǎn)變成對(duì)應(yīng)的對(duì)象原型须板。注意，我這里指的不是NSDictionary绞惦，而是類似Item這樣的對(duì)象逼纸。這種做法是能夠提高后續(xù)操作代碼的可讀性的。在比較直覺(jué)的思路里面济蝉，是需要這部分轉(zhuǎn)化過(guò)程的杰刽，但這部分轉(zhuǎn)化過(guò)程的成本是很大的，主要成本在于：
- 數(shù)組內(nèi)容的轉(zhuǎn)化成本較高：數(shù)組里面每項(xiàng)都要轉(zhuǎn)化成Item對(duì)象王滤，如果Item對(duì)象中還有類似數(shù)組贺嫂，就很頭疼。
- 轉(zhuǎn)化之后的數(shù)據(jù)在大部分情況是不能直接被展示的雁乡，為了能夠被展示第喳，還需要第二次轉(zhuǎn)化。
- 只有在API返回的數(shù)據(jù)高度標(biāo)準(zhǔn)化時(shí)踱稍，這些對(duì)象原型（Item）的可復(fù)用程度才高曲饱，否則容易出現(xiàn)類型爆炸，提高維護(hù)成本珠月。
- 調(diào)試時(shí)通過(guò)對(duì)象原型查看數(shù)據(jù)內(nèi)容不如直接通過(guò)NSDictionary/NSArray直觀扩淀。
- 同一API的數(shù)據(jù)被不同View展示時(shí)，難以控制數(shù)據(jù)轉(zhuǎn)化的代碼啤挎，它們有可能會(huì)散落在任何需要的地方驻谆。
其實(shí)我們的理想情況是希望API的數(shù)據(jù)下發(fā)之后就能夠直接被View所展示。首先要說(shuō)的是，這種情況非常少胜臊。另外勺卢，這種做法使得View和API聯(lián)系緊密，也是我們不希望發(fā)生的象对。
在設(shè)計(jì)安居客的網(wǎng)絡(luò)層數(shù)據(jù)交付這部分時(shí)黑忱，我添加了reformer（名字而已，叫什么都好）這個(gè)對(duì)象用于封裝數(shù)據(jù)轉(zhuǎn)化的邏輯织盼，這個(gè)對(duì)象是一個(gè)獨(dú)立對(duì)象杨何，事實(shí)上酱塔，它是作為Adaptor模式存在的沥邻。我們可以這么理解：想象一下我們洗澡時(shí)候使用的蓮蓬頭，水管里出來(lái)的水是API下發(fā)的原始數(shù)據(jù)羊娃。reformer就是蓮蓬頭上的不同水流擋板唐全，需要什么模式，就撥到什么模式蕊玷。
在實(shí)際使用時(shí)邮利，代碼觀感是這樣的：
先定義一個(gè)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];
}
}
要點(diǎn)1：reformer是一個(gè)符合ReformerProtocol的對(duì)象垃帅，它提供了通用的方法供Manager使用延届。
要點(diǎn)2：API的原始數(shù)據(jù)（JSON對(duì)象）由Manager實(shí)例保管，reformer方法里面取Manager的原始數(shù)據(jù)(manager.rawData)做轉(zhuǎn)換贸诚，然后交付出去方庭。蓮蓬頭的水管部分是Manager，負(fù)責(zé)提供原始水流（數(shù)據(jù)流）酱固，reformer就是不同的模式械念，換什么reformer就能出來(lái)什么水流。
要點(diǎn)3：例子中舉的場(chǎng)景是一個(gè)API數(shù)據(jù)被多個(gè)View使用的情況运悲，體現(xiàn)了reformer的一個(gè)特點(diǎn)：可以根據(jù)需要改變同一數(shù)據(jù)來(lái)源的展示方式龄减。比如API數(shù)據(jù)展示的是“附近的小區(qū)”，那么這個(gè)數(shù)據(jù)可以被列表（XXXView）和地圖（YYYView）共用班眯，不同的view使用的數(shù)據(jù)的轉(zhuǎn)化方式不一樣希停，這就通過(guò)不同的reformer解決了。
要點(diǎn)4：在一個(gè)view用來(lái)同一展示不同API數(shù)據(jù)的情況署隘，reformer是絕佳利器宠能。比如安居客的列表view的數(shù)據(jù)來(lái)源可能有三個(gè)：二手房列表API，租房列表API定踱，新房列表API棍潘。這些API返回來(lái)的數(shù)據(jù)的value可能一致，但是key都是不一致的。這時(shí)候就可以通過(guò)同一個(gè)reformer來(lái)做數(shù)據(jù)的標(biāo)準(zhǔn)化輸出亦歉，這樣就使得view代碼復(fù)用成為可能恤浪。這體現(xiàn)了reformer另外一個(gè)特點(diǎn)：同一個(gè)reformer出來(lái)的數(shù)據(jù)是高度標(biāo)準(zhǔn)化的。形象點(diǎn)說(shuō)就是：只要蓮蓬頭不換肴楷，哪怕水管的水變成海水或者污水了水由，也依舊能夠輸出符合洗澡要求的淡水水流。舉個(gè)例子：
- (void)apiManagerDidSuccess:(APIManager *)manager
{
// 這個(gè)回調(diào)方法有可能是來(lái)自二手房列表APIManager的回調(diào)赛蔫，也有可能是租房砂客，也有可能是新房。但是在Controller層面我們不需要對(duì)它做額外區(qū)分呵恢，只要是同一個(gè)reformer出來(lái)的數(shù)據(jù)鞠值，我們就能保證是一定能被self.XXXView使用的。這樣的保證由reformer的實(shí)現(xiàn)者來(lái)提供渗钉。
NSDictionary *reformedXXXData = [manager fetchDataWithReformer:self.XXXReformer];
[self.XXXView configWithData:reformedXXXData];
}
- 要點(diǎn)5：有沒(méi)有發(fā)現(xiàn)彤恶，使用reformer之后，Controller的代碼簡(jiǎn)潔了很多鳄橘？而且声离，數(shù)據(jù)原型在這種情況下就沒(méi)有必要存在了，隨之而來(lái)的成本也就被我們繞過(guò)了瘫怜。
reformer本質(zhì)上就是一個(gè)符合某個(gè)protocol的對(duì)象术徊，在controller需要從api manager中獲得數(shù)據(jù)的時(shí)候，順便把reformer傳進(jìn)去鲸湃，于是就能獲得經(jīng)過(guò)reformer重新洗過(guò)的數(shù)據(jù)赠涮，然后就可以直接使用了。
更抽象地說(shuō)唤锉，reformer其實(shí)是對(duì)數(shù)據(jù)轉(zhuǎn)化邏輯的一個(gè)封裝世囊。在controller從manager中取數(shù)據(jù)之后，并且把數(shù)據(jù)交給view之前窿祥，這期間或多或少都是要做一次數(shù)據(jù)轉(zhuǎn)化的株憾，有的時(shí)候不同的view，對(duì)應(yīng)的轉(zhuǎn)化邏輯還不一樣晒衩，但是展示的數(shù)據(jù)是一樣的嗤瞎。而且往往這一部分代碼都非常復(fù)雜，且跟業(yè)務(wù)強(qiáng)相關(guān)听系，直接上代碼贝奇，將來(lái)就會(huì)很難維護(hù)。所以我們可以考慮采用不同的reformer封裝不同的轉(zhuǎn)化邏輯靠胜，然后讓controller根據(jù)需要選擇一個(gè)合適的reformer裝上掉瞳，就像洗澡的蓮蓬頭毕源，需要什么樣的水流（數(shù)據(jù)的表現(xiàn)形式）就換什么樣的頭，然而水（數(shù)據(jù)）都是一樣的陕习。這種做法能夠大大提高代碼的可維護(hù)性霎褐，以及減少ViewController的體積。
總結(jié)一下该镣，reformer事實(shí)上是把轉(zhuǎn)化的代碼封裝之后再?gòu)闹黧w業(yè)務(wù)中拆分了出來(lái)冻璃，拆分出來(lái)之后不光降低了原有業(yè)務(wù)的復(fù)雜度，更重要的是损合，它提高了數(shù)據(jù)交付的靈活性省艳。另外，由于Controller負(fù)責(zé)調(diào)度Manager和View嫁审，因此它是知道Manager和View之間的關(guān)系的跋炕，Controller知道了這個(gè)關(guān)系之后，就有了充要條件來(lái)為不同的View選擇不同的Reformer土居，并用這個(gè)Reformer去改造Mananger的數(shù)據(jù)枣购，然后ViewController獲得了經(jīng)過(guò)reformer處理過(guò)的數(shù)據(jù)之后嬉探，就可以直接交付給view去使用擦耀。Controller因此得到瘦身，負(fù)責(zé)業(yè)務(wù)數(shù)據(jù)轉(zhuǎn)化的這部分代碼也不用寫在Controller里面涩堤，提高了可維護(hù)性眷蜓。
所以reformer機(jī)制能夠帶來(lái)以下好處：
好處1：繞開(kāi)了API數(shù)據(jù)原型的轉(zhuǎn)換，避免了相關(guān)成本胎围。
好處2：在處理單View對(duì)多API吁系，以及在單API對(duì)多View的情況時(shí)，reformer提供了非常優(yōu)雅的手段來(lái)響應(yīng)這種需求白魂，隔離了轉(zhuǎn)化邏輯和主體業(yè)務(wù)邏輯汽纤，避免了維護(hù)災(zāi)難。
好處3：轉(zhuǎn)化邏輯集中福荸，且將轉(zhuǎn)化次數(shù)轉(zhuǎn)為只有一次蕴坪。使用數(shù)據(jù)原型的轉(zhuǎn)化邏輯至少有兩次，第一次是把JSON映射成對(duì)應(yīng)的原型敬锐，第二次是把原型轉(zhuǎn)變成能被View處理的數(shù)據(jù)背传。reformer一步到位。另外台夺，轉(zhuǎn)化邏輯在reformer里面径玖，將來(lái)如果API數(shù)據(jù)有變，就只要去找到對(duì)應(yīng)reformer然后改掉就好了颤介。
好處4：Controller因此可以省去非常多的代碼梳星，降低了代碼復(fù)雜度赞赖，同時(shí)提高了靈活性，任何時(shí)候切換reformer而不必切換業(yè)務(wù)邏輯就可以應(yīng)對(duì)不同View對(duì)數(shù)據(jù)的需要冤灾。
好處5：業(yè)務(wù)數(shù)據(jù)和業(yè)務(wù)有了適當(dāng)?shù)母綦x薯定。這么做的話，將來(lái)如果業(yè)務(wù)邏輯有修改瞳购，換一個(gè)reformer就好了话侄。如果其他業(yè)務(wù)也有相同的數(shù)據(jù)轉(zhuǎn)化邏輯，其他業(yè)務(wù)直接拿這個(gè)reformer就可以用了学赛，不用重寫年堆。另外，如果controller有修改（比如UI交互方式改變）盏浇，可以放心換controller变丧，完全不用擔(dān)心業(yè)務(wù)數(shù)據(jù)的處理。
在不使用特定對(duì)象表征數(shù)據(jù)的情況下绢掰，如何保持?jǐn)?shù)據(jù)可讀性痒蓬？
不使用對(duì)象來(lái)表征數(shù)據(jù)的時(shí)候，事實(shí)上就是使用NSDictionary的時(shí)候滴劲。事實(shí)上攻晒，這個(gè)問(wèn)題就是，如何在NSDictionary表征數(shù)據(jù)的情況下保持良好的可讀性班挖？
蘋果已經(jīng)給出了非常好的做法鲁捏，用固定字符串做key，比如你在接收到KeyBoardWillShow的Notification時(shí)萧芙，帶了一個(gè)userInfo给梅，他的key就都是類似UIKeyboardAnimationCurveUserInfoKey這樣的，所以我們采用這樣的方案來(lái)維持可讀性双揪。下面我舉一個(gè)例子：
PropertyListReformerKeys.h
extern NSString * const kPropertyListDataKeyID;
extern NSString * const kPropertyListDataKeyName;
extern NSString * const kPropertyListDataKeyTitle;
extern NSString * const kPropertyListDataKeyImage;
PropertyListReformer.h
#import "PropertyListReformerKeys.h"
... ...
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;
}
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];
}
這一大段代碼看下來(lái)动羽，我如果不說(shuō)一下要點(diǎn)，那基本上就白寫了哈：
我們先看一下結(jié)構(gòu)：
---------------------------------- -----------------------------------------
| | | |
| PropertyListReformer.m | | PropertyListReformer.h |
| | | |
| #import PropertyListReformer.h | <------- | #import "PropertyListReformerKeys.h" |
| NSString * const key = @"key" | | |
| | | |
---------------------------------- -----------------------------------------
.
/|\
|
|
|
|
---------------------------------
| |
| PropertyListReformerKeys.h |
| |
| extern NSString * const key; |
| |
---------------------------------
使用Const字符串來(lái)表征Key渔期，字符串的定義跟著reformer的實(shí)現(xiàn)文件走运吓，字符串的extern聲明放在獨(dú)立的頭文件內(nèi)。
這樣reformer生成的數(shù)據(jù)的key都使用Const字符串來(lái)表示擎场，然后每次別的地方需要使用相關(guān)數(shù)據(jù)的時(shí)候羽德，把PropertyListReformerKeys.h這個(gè)頭文件import進(jìn)去就好了。
另外要注意的一點(diǎn)是迅办，如果一個(gè)OriginData可能會(huì)被多個(gè)Reformer去處理的話宅静，Key的命名規(guī)范需要能夠表征出其對(duì)應(yīng)的reformer名字。如果reformer是PropertyListReformer站欺，那么Key的名字就是PropertyListKeyXXXX姨夹。
這么做的好處就是纤垂，將來(lái)遷移的時(shí)候相當(dāng)方便，只要扔頭文件就可以了磷账，只扔頭文件是不會(huì)導(dǎo)致拔出蘿卜帶出泥的情況的峭沦。而且也避免了自定義對(duì)象帶來(lái)的額外代碼體積。
另外逃糟，關(guān)于交付的NSDictionary吼鱼，其實(shí)具體還是看view的需求，reformer的設(shè)計(jì)初衷是：通過(guò)reformer轉(zhuǎn)化出來(lái)的可以直接是View绰咽，或者是view直接可以使用的對(duì)象（包括NSDictionary）菇肃。比如地圖標(biāo)點(diǎn)列表API的數(shù)據(jù)，通過(guò)reformer轉(zhuǎn)化之后就可以直接變成MKAnnotation取募，然后MKMapView就可以直接使用了琐谤。這里說(shuō)的只是當(dāng)你的需求是交付NSDictionary時(shí)，如何保證可讀性的情況玩敏，再?gòu)?qiáng)調(diào)一下哈斗忌，reformer交付的是view直接可以使用的對(duì)象，交付出去的可以是NSDictionary旺聚，也可以是UIView织阳，跟DataSource結(jié)合之后交付的甚至可以是UITableViewCell/UICollectionViewCell。不要被NSDictionary或所謂的轉(zhuǎn)化成model再交付的思想局限翻屈。
綜上陈哑，我對(duì)交付什么樣的數(shù)據(jù)給業(yè)務(wù)層？這個(gè)問(wèn)題的回答就是這樣：
對(duì)于業(yè)務(wù)層而言伸眶，由Controller根據(jù)View和APIManager之間的關(guān)系，選擇合適的reformer將View可以直接使用的數(shù)據(jù)（甚至reformer可以用來(lái)直接生成view）轉(zhuǎn)化好之后交付給View刽宪。對(duì)于網(wǎng)絡(luò)層而言厘贼，只需要保持住原始數(shù)據(jù)即可，不需要主動(dòng)轉(zhuǎn)化成數(shù)據(jù)原型圣拄。然后數(shù)據(jù)采用NSDictionary加Const字符串key來(lái)表征嘴秸，避免了使用對(duì)象來(lái)表征帶來(lái)的遷移困難，同時(shí)不失去可讀性庇谆。
集約型API調(diào)用方式和離散型API調(diào)用方式的選擇岳掐？
集約型API調(diào)用其實(shí)就是所有API的調(diào)用只有一個(gè)類，然后這個(gè)類接收API名字饭耳，API參數(shù)串述，以及回調(diào)著陸點(diǎn)（可以是target-action，或者block寞肖，或者delegate等各種模式的著陸點(diǎn)）作為參數(shù)纲酗。然后執(zhí)行類似startRequest這樣的方法衰腌，它就會(huì)去根據(jù)這些參數(shù)起飛去調(diào)用API了，然后獲得API數(shù)據(jù)之后再根據(jù)指定的著陸點(diǎn)去著陸觅赊。比如這樣：
集約型API調(diào)用方式：
[APIRequest startRequestWithApiName:@"itemList.v1" params:params success:@selector(success:) fail:@selector(fail:) target:self];
離散型API調(diào)用是這樣的右蕊，一個(gè)API對(duì)應(yīng)于一個(gè)APIManager，然后這個(gè)APIManager只需要提供參數(shù)就能起飛吮螺，API名字饶囚、著陸方式都已經(jīng)集成入APIManager中。比如這樣：
離散型API調(diào)用方式：
@property (nonatomic, strong) ItemListAPIManager *itemListAPIManager;
// getter
- (ItemListAPIManager *)itemListAPIManager
{
if (_itemListAPIManager == nil) {
_itemListAPIManager = [[ItemListAPIManager alloc] init];
_itemListAPIManager.delegate = self;
}
return _itemListAPIManager;
}
// 使用的時(shí)候就這么寫：
[self.itemListAPIManager loadDataWithParams:params];
集約型API調(diào)用和離散型API調(diào)用這兩者實(shí)現(xiàn)方案不是互斥的鸠补，單看下層坯约，大家都是集約型。因?yàn)榘l(fā)起一個(gè)API請(qǐng)求之后莫鸭，除去業(yè)務(wù)相關(guān)的部分（比如參數(shù)和API名字等）闹丐，剩下的都是要統(tǒng)一處理的：加密，URL拼接被因，API請(qǐng)求的起飛和著陸卿拴，這些處理如果不用集約化的方式來(lái)實(shí)現(xiàn)，作者非癲即癡梨与。然而對(duì)于整個(gè)網(wǎng)絡(luò)層來(lái)說(shuō)堕花，尤其是業(yè)務(wù)方使用的那部分，我傾向于提供離散型的API調(diào)用方式粥鞋，并不建議在業(yè)務(wù)層的代碼直接使用集約型的API調(diào)用方式缘挽。原因如下：
- 原因1：當(dāng)前請(qǐng)求正在外面飛著的時(shí)候，根據(jù)不同的業(yè)務(wù)需求存在兩種不同的請(qǐng)求起飛策略：一個(gè)是取消新發(fā)起的請(qǐng)求呻粹，等待外面飛著的請(qǐng)求著陸壕曼。另一個(gè)是取消外面飛著的請(qǐng)求，讓新發(fā)起的請(qǐng)求起飛等浊。集約化的API調(diào)用方式如果要滿足這樣的需求腮郊，那么每次要調(diào)用的時(shí)候都要多寫一部分判斷和取消的代碼，手段就做不到很干凈筹燕。
前者的業(yè)務(wù)場(chǎng)景舉個(gè)例子就是刷新頁(yè)面的請(qǐng)求轧飞，刷新詳情，刷新列表等撒踪。后者的業(yè)務(wù)場(chǎng)景舉個(gè)例子是列表多維度篩選过咬，比如你先篩選了商品類型，然后篩選了價(jià)格區(qū)間制妄。當(dāng)然掸绞，后者的情況不一定每次篩選都要調(diào)用API，我們先假設(shè)這種篩選每次都必須要通過(guò)調(diào)用API才能獲得數(shù)據(jù)忍捡。
如果是離散型的API調(diào)用集漾，在編寫不同的APIManager時(shí)候就可以針對(duì)不同的API設(shè)置不同的起飛策略切黔，在實(shí)際使用的時(shí)候，就可以不必關(guān)心起飛策略了具篇，因?yàn)锳PIMananger里面已經(jīng)寫好了纬霞。
原因2：便于針對(duì)某個(gè)API請(qǐng)求來(lái)進(jìn)行AOP。在集約型的API調(diào)用方式下驱显，如果要針對(duì)某個(gè)API請(qǐng)求的起飛和著陸過(guò)程進(jìn)行AOP诗芜，這代碼得寫成什么樣。埃疫。伏恐。噢，尼瑪這畫面太美別說(shuō)看了栓霜，我都不敢想翠桦。
原因3：當(dāng)API請(qǐng)求的著陸點(diǎn)消失時(shí)，離散型的API調(diào)用方式能夠更加透明地處理這種情況胳蛮。
當(dāng)一個(gè)頁(yè)面的請(qǐng)求正在天上飛的時(shí)候销凑，用戶等了好久不耐煩了，小手點(diǎn)了個(gè)back仅炊，然后ViewController被pop被回收灸拍。此時(shí)請(qǐng)求的著陸點(diǎn)就沒(méi)了嚷那。這是很危險(xiǎn)的情況氯檐，著陸點(diǎn)要是沒(méi)了氮采，就很容易crash的。一般來(lái)說(shuō)處理這個(gè)情況都是在dealloc的時(shí)候取消當(dāng)前頁(yè)面所有的請(qǐng)求呆馁。如果是集約型的API調(diào)用桐经，這個(gè)代碼就要寫到ViewController的dealloc里面，但如果是離散型的API調(diào)用智哀，這個(gè)代碼寫到APIManager里面就可以了次询，然后隨著ViewController的回收進(jìn)程，APIManager也會(huì)被跟著回收瓷叫，這部分代碼就得到了調(diào)用的機(jī)會(huì)。這樣業(yè)務(wù)方在使用的時(shí)候就可以不必關(guān)心著陸點(diǎn)消失的情況了送巡，從而更加關(guān)注業(yè)務(wù)摹菠。
- 原因4：離散型的API調(diào)用方式能夠最大程度地給業(yè)務(wù)方提供靈活性，比如reformer機(jī)制就是基于離散型的API調(diào)用方式的骗爆。另外次氨，如果是針對(duì)提供翻頁(yè)機(jī)制的API，APIManager就能簡(jiǎn)單地提供
loadNextPage方法去加載下一頁(yè)摘投，頁(yè)碼的管理就不用業(yè)務(wù)方去管理了煮寡。還有就是虹蓄，如果要針對(duì)業(yè)務(wù)請(qǐng)求參數(shù)進(jìn)行驗(yàn)證，比如用戶填寫注冊(cè)信息幸撕，在離散型的APIManager里面實(shí)現(xiàn)就會(huì)非常輕松薇组。
綜上，關(guān)于集約型的API調(diào)用和離散型的API調(diào)用坐儿，我傾向于這樣：對(duì)外提供一個(gè)BaseAPIManager來(lái)給業(yè)務(wù)方做派生律胀，在BaseManager里面采用集約化的手段組裝請(qǐng)求，放飛請(qǐng)求貌矿，然而業(yè)務(wù)方調(diào)用API的時(shí)候炭菌，則是以離散的API調(diào)用方式來(lái)調(diào)用。如果你的App只提供了集約化的方式逛漫，而沒(méi)有離散方式的通道黑低，那么我建議你再封裝一層，便于業(yè)務(wù)方使用離散的API調(diào)用方式來(lái)放飛請(qǐng)求酌毡。
怎么做APIManager的繼承克握？
如果要做成離散型的API調(diào)用，那么使用繼承是逃不掉的阔馋。BaseAPIManager里面負(fù)責(zé)集約化的部分玛荞，外部派生的XXXAPIManager負(fù)責(zé)離散的部分，對(duì)于BaseAPIManager來(lái)說(shuō)呕寝，離散的部分有一些是必要的勋眯，比如API名字等，而我們派生的目的下梢，也是為了提供這些數(shù)據(jù)客蹋。
我在這篇文章里面列舉了種種繼承的壞處，呼吁大家盡量不要使用繼承孽江。但是現(xiàn)在到了不得不用繼承的時(shí)候讶坯，所以我得提醒一下大家別把繼承用壞了。
在APIManager的情況下岗屏，我們最直覺(jué)的思路是BaseAPIManager提供一些空方法來(lái)給子類做重載辆琅，比如apiMethodName這樣的函數(shù)，然而我的建議是这刷，不要這么做婉烟。我們可以用IOP的方式來(lái)限制派生類的重載。
大概就是長(zhǎng)這樣：
BaseAPIManager的init方法里這么寫：
// 注意是weak暇屋。
@property (nonatomic, weak) id<APIManager> child;
- (instancetype)init
{
self = [super init];
if ([self conformsToProtocol:@protocol(APIManager)]) {
self.child = (id<APIManager>)self;
} else {
// 不遵守這個(gè)protocol的就讓他crash似袁，防止派生類亂來(lái)。
NSAssert(NO, "子類必須要實(shí)現(xiàn)APIManager這個(gè)protocol。");
}
return self;
}
protocol這么寫昙衅，把原本要重載的函數(shù)都定義在這個(gè)protocol里面扬霜，就不用在父類里面寫空方法了：
@protocol APIManager <NSObject>
@required
- (NSString *)apiMethodName;
...
@end
然后在父類里面如果要使用的話，就這么寫：
[self requestWithAPIName:[self.child apiMethodName] ......];
簡(jiǎn)單說(shuō)就是在init的時(shí)候檢查自己是否符合預(yù)先設(shè)計(jì)的子類的protocol而涉，這就要求所有子類必須遵守這個(gè)protocol著瓶，所有針對(duì)父類的重載、覆蓋也都以這個(gè)protocol為準(zhǔn)婴谱，protocol以外的方法不允許重載蟹但、覆蓋。而在父類的代碼里谭羔，可以不必遵守這個(gè)protocol华糖，保持了未來(lái)維護(hù)的靈活性。
這么做的好處就是避免了父類寫空方法瘟裸，同時(shí)也給子類帶上了緊箍咒：要想當(dāng)我的孩子客叉，就要遵守這些規(guī)矩，不能亂來(lái)话告。業(yè)務(wù)方在實(shí)現(xiàn)子類的時(shí)候兼搏，就可以根據(jù)protocol中的方法去一一實(shí)現(xiàn)，然后約定就比較好做了：不允許重載父類方法沙郭，只允許選擇實(shí)現(xiàn)或不實(shí)現(xiàn)protocol中的方法佛呻。
關(guān)于這個(gè)的具體的論述在這篇文章里面有，感興趣的話可以看看病线。
網(wǎng)絡(luò)層與業(yè)務(wù)層對(duì)接部分的小總結(jié)
這一節(jié)主要是講了以下這些點(diǎn)：
- 使用delegate來(lái)做數(shù)據(jù)對(duì)接吓著，僅在必要時(shí)采用Notification來(lái)做跨層訪問(wèn)
- 交付NSDictionary給業(yè)務(wù)層，使用Const字符串作為Key來(lái)保持可讀性
- 提供reformer機(jī)制來(lái)處理網(wǎng)絡(luò)層反饋的數(shù)據(jù)送挑，這個(gè)機(jī)制很重要绑莺，好處極多
- 網(wǎng)絡(luò)層上部分使用離散型設(shè)計(jì)，下部分使用集約型設(shè)計(jì)
- 設(shè)計(jì)合理的繼承機(jī)制惕耕，讓派生出來(lái)的APIManager受到限制纺裁，避免混亂
- 應(yīng)該不止這5點(diǎn)...
網(wǎng)絡(luò)層的安全機(jī)制
判斷API的調(diào)用請(qǐng)求是來(lái)自于經(jīng)過(guò)授權(quán)的APP
使用這個(gè)機(jī)制的目的主要有兩點(diǎn)：
- 確保API的調(diào)用者是來(lái)自你自己的APP，防止競(jìng)爭(zhēng)對(duì)手爬你的API
- 如果你對(duì)外提供了需要注冊(cè)才能使用的API平臺(tái)司澎，那么你需要有這個(gè)機(jī)制來(lái)識(shí)別是否是注冊(cè)用戶調(diào)用了你的API
解決方案：設(shè)計(jì)簽名
要達(dá)到第一個(gè)目的其實(shí)很簡(jiǎn)單欺缘，服務(wù)端需要給你一個(gè)密鑰，每次調(diào)用API時(shí)挤安，你使用這個(gè)密鑰再加上API名字和API請(qǐng)求參數(shù)算一個(gè)hash出來(lái)浪南，然后請(qǐng)求的時(shí)候帶上這個(gè)hash。服務(wù)端收到請(qǐng)求之后漱受，按照同樣的密鑰同樣的算法也算一個(gè)hash出來(lái)，然后跟請(qǐng)求帶來(lái)的hash做一個(gè)比較，如果一致昂羡，那么就表示這個(gè)API的調(diào)用者確實(shí)是你的APP絮记。為了不讓別人也獲取到這個(gè)密鑰，你最好不要把這個(gè)密鑰存儲(chǔ)在本地虐先，直接寫死在代碼里面就好了怨愤。另外適當(dāng)增加一下求Hash的算法的復(fù)雜度，那就是各種Hash算法（比如MD5）加點(diǎn)鹽蛹批，再回爐跑一次Hash啥的撰洗。這樣就能解決第一個(gè)目的了：確保你的API是來(lái)自于你自己的App。
一般情況下大部分公司不會(huì)出現(xiàn)需要滿足第二種情況的需求腐芍，除非公司開(kāi)發(fā)了自己的API平臺(tái)給第三方使用差导。這個(gè)需求跟上面的需求有一點(diǎn)不同：符合授權(quán)的API請(qǐng)求者不只是一個(gè)。所以在這種情況下猪勇，需要的安全機(jī)制會(huì)更加復(fù)雜一點(diǎn)设褐。
這里有一個(gè)較容易實(shí)現(xiàn)的方案：客戶端調(diào)用API的時(shí)候，把自己的密鑰通過(guò)一個(gè)可逆的加密算法加密后連著請(qǐng)求和加密之后的Hash一起送上去泣刹。當(dāng)然助析，這個(gè)可逆的加密算法肯定是放在在調(diào)用API的SDK里面，編譯好的椅您。然后服務(wù)端拿到加密后的密鑰和加密的Hash之后外冀，解碼得到原始密鑰，然后再用它去算Hash掀泳，最后再進(jìn)行比對(duì)雪隧。
保證傳輸數(shù)據(jù)的安全
使用這個(gè)機(jī)制的主要目的有兩點(diǎn)：
- 防止中間人攻擊，比如說(shuō)運(yùn)營(yíng)商很喜歡往用戶的Http請(qǐng)求里面塞廣告...
- SPDY依賴于HTTPS开伏，而且是未來(lái)HTTP/2的基礎(chǔ)膀跌，他們能夠提高你APP在網(wǎng)絡(luò)層整體的性能。
解決方案：HTTPS
目前使用HTTPS的主要目的在于防止運(yùn)營(yíng)商往你的Response Data里面加廣告啥的（中間人攻擊）固灵，面對(duì)的威脅范圍更廣捅伤。從2011年開(kāi)始，國(guó)外業(yè)界就已經(jīng)提倡所有的請(qǐng)求（不光是API巫玻，還有網(wǎng)站）都走HTTPS丛忆，國(guó)內(nèi)差不多晚了兩年（2013年左右）才開(kāi)始提倡這事，天貓是這兩個(gè)月才開(kāi)始做HTTPS的全APP遷移仍秤。
關(guān)于速度熄诡，HTTPS肯定是比HTTP慢的，畢竟多了一次握手诗力，但掛上SPDY之后凰浮，有了鏈接復(fù)用，這方面的性能就有了較大提升。這里的性能提升并不是說(shuō)一個(gè)請(qǐng)求原來(lái)要500ms能完成袜茧，然后現(xiàn)在只要300ms菜拓，這是不對(duì)的。所謂整體性能是基于大量請(qǐng)求去討論的：同樣的請(qǐng)求量（假設(shè)100個(gè)）在短期發(fā)生時(shí)笛厦，掛上SPDY之后完成這些任務(wù)所要花的時(shí)間比不用SPDY要少纳鼎。SPDY還有Header壓縮的功能，不過(guò)因?yàn)橐粋€(gè)API請(qǐng)求本身已經(jīng)比較小了裳凸，壓縮數(shù)據(jù)量所帶來(lái)的性能提升不會(huì)特別明顯贱鄙，所以就單個(gè)請(qǐng)求來(lái)看，性能的提升是比較小的姨谷。不過(guò)這是下一節(jié)要討論的事兒了逗宁，這兒只是順帶說(shuō)一下。
安全機(jī)制小總結(jié)
這一節(jié)說(shuō)了兩種安全機(jī)制菠秒，一般來(lái)說(shuō)第一種是標(biāo)配疙剑，第二種屬于可選配置。不過(guò)隨著我國(guó)互聯(lián)網(wǎng)基礎(chǔ)設(shè)施的完善践叠，移動(dòng)設(shè)備性能的提高言缤，以及優(yōu)化技術(shù)的提高，第二種配置的缺點(diǎn)（速度慢）正在越來(lái)越微不足道禁灼，因此HTTPS也會(huì)成為不久之后的未來(lái)App的網(wǎng)絡(luò)層安全機(jī)制標(biāo)配管挟。各位架構(gòu)師們，如果你的App還沒(méi)有掛HTTPS弄捕，現(xiàn)在就已經(jīng)可以開(kāi)始著手這件事情了僻孝。
網(wǎng)絡(luò)層的優(yōu)化方案
網(wǎng)絡(luò)層的優(yōu)化手段主要從以下三方面考慮：
- 針對(duì)鏈接建立環(huán)節(jié)的優(yōu)化
- 針對(duì)鏈接傳輸數(shù)據(jù)量的優(yōu)化
- 針對(duì)鏈接復(fù)用的優(yōu)化
這三方面是所有優(yōu)化手段的內(nèi)容，各種五花八門的優(yōu)化手段基本上都不會(huì)逃脫這三方面守谓，下面我就會(huì)分別針對(duì)這三方面講一下各自對(duì)應(yīng)的優(yōu)化手段穿铆。
1. 針對(duì)鏈接建立環(huán)節(jié)的優(yōu)化
在API發(fā)起請(qǐng)求建立鏈接的環(huán)節(jié)，大致會(huì)分這些步驟：
- 發(fā)起請(qǐng)求
- DNS域名解析得到IP
- 根據(jù)IP進(jìn)行三次握手（HTTPS四次握手）斋荞，鏈接建立成功
其實(shí)第三步的優(yōu)化手段跟第二步的優(yōu)化手段是一致的荞雏，我會(huì)在講第二步的時(shí)候一起講掉。
1.1 針對(duì)發(fā)起請(qǐng)求的優(yōu)化手段
其實(shí)要解決的問(wèn)題就是網(wǎng)絡(luò)層該不該為此API調(diào)用發(fā)起請(qǐng)求平酿。
- 1.1.1 使用緩存手段減少請(qǐng)求的發(fā)起次數(shù)
對(duì)于大部分API調(diào)用請(qǐng)求來(lái)說(shuō)凤优，有些API請(qǐng)求所帶來(lái)的數(shù)據(jù)的時(shí)效性是比較長(zhǎng)的，比如商品詳情蜈彼，比如App皮膚等筑辨。那么我們就可以針對(duì)這些數(shù)據(jù)做本地緩存，這樣下次請(qǐng)求這些數(shù)據(jù)的時(shí)候就可以不必再發(fā)起新的請(qǐng)求幸逆。
一般是把API名字和參數(shù)拼成一個(gè)字符串然后取MD5作為key棍辕，存儲(chǔ)對(duì)應(yīng)返回的數(shù)據(jù)暮现。這樣下次有同樣請(qǐng)求的時(shí)候就可以直接讀取這里面的數(shù)據(jù)。關(guān)于這里有一個(gè)緩存策略的問(wèn)題需要討論：什么時(shí)候清理緩存痢毒？要么就是根據(jù)超時(shí)時(shí)間限制進(jìn)行清理送矩，要么就是根據(jù)緩存數(shù)據(jù)大小進(jìn)行清理。這個(gè)策略的選擇要根據(jù)具體App的操作日志來(lái)決定哪替。
比如安居客App，日志數(shù)據(jù)記錄顯示用戶平均使用時(shí)長(zhǎng)不到3分鐘菇怀，但是用戶查看房源詳情的次數(shù)比較多凭舶，而房源詳情數(shù)據(jù)量較大。那么這個(gè)時(shí)候爱沟，就適合根據(jù)使用時(shí)長(zhǎng)來(lái)做緩存帅霜，我當(dāng)時(shí)給安居客設(shè)置的緩存超時(shí)時(shí)間就是3分鐘，這樣能夠保證這個(gè)緩存能夠在大部分用戶使用時(shí)間產(chǎn)生作用呼伸。嗯身冀，極端情況下做什么緩存手段不考慮，只要能夠服務(wù)好80%的用戶就可以了括享，而且針對(duì)極端情況采用的優(yōu)化手段對(duì)大部分普通用戶而言是不必要的搂根，做了反而會(huì)對(duì)他們有影響。
再比如網(wǎng)絡(luò)圖片緩存铃辖，數(shù)據(jù)量基本上都特別大剩愧，這種就比較適合針對(duì)緩存大小來(lái)清理緩存的策略。
另外娇斩，之前的緩存的前提都是基于內(nèi)存的仁卷。我們也可以把需要清理的緩存存儲(chǔ)在硬盤上（APP的本地存儲(chǔ)，我就先用硬盤來(lái)表示了犬第，雖然很少有手機(jī)硬盤的說(shuō)法锦积，哈哈），比如前面提到的圖片緩存歉嗓，因?yàn)閳D片很有可能在很長(zhǎng)時(shí)間之后丰介，再被顯示的，那么原本需要被清理的圖片緩存遥椿，我們就可以考慮存到硬盤上去基矮。當(dāng)下次再有顯示網(wǎng)絡(luò)圖片的需求的時(shí)候，我們可以先從內(nèi)存中找冠场，內(nèi)存找不到那就從硬盤上找家浇，這都找不到，那就發(fā)起請(qǐng)求吧碴裙。
當(dāng)然钢悲，有些時(shí)效性非常短的API數(shù)據(jù)点额，就不能使用這個(gè)方法了，比如用戶的資金數(shù)據(jù)莺琳，那就需要每次都調(diào)用了还棱。
- 1.1.2 使用策略來(lái)減少請(qǐng)求的發(fā)起次數(shù)
這個(gè)我在前面提到過(guò)，就是針對(duì)重復(fù)請(qǐng)求的發(fā)起和取消惭等，是有對(duì)應(yīng)的請(qǐng)求策略的珍手。我們先說(shuō)取消策略。
如果是界面刷新請(qǐng)求這種辞做，而且存在重復(fù)請(qǐng)求的情況（下拉刷新時(shí)琳要，在請(qǐng)求著陸之前用戶不斷執(zhí)行下拉操作），那么這個(gè)時(shí)候秤茅，后面重復(fù)操作導(dǎo)致的API請(qǐng)求就可以不必發(fā)送了稚补。
如果是條件篩選這種，那就取消前面已經(jīng)發(fā)送的請(qǐng)求框喳。雖然很有可能這個(gè)請(qǐng)求已經(jīng)被執(zhí)行了课幕，那么取消所帶來(lái)的性能提升就基本沒(méi)有了。但如果這個(gè)請(qǐng)求還在隊(duì)列中待執(zhí)行的話五垮，那么對(duì)應(yīng)的這次鏈接就可以省掉了乍惊。
以上是一種，另外一種情況就是請(qǐng)求策略：類似用戶操作日志的請(qǐng)求策略拼余。
用戶操作會(huì)觸發(fā)操作日志上報(bào)Server污桦，這種請(qǐng)求特別頻繁，但是是暗地里進(jìn)行的匙监，不需要用戶對(duì)此有所感知凡橱。所以也沒(méi)必要操作一次就發(fā)起一次的請(qǐng)求。在這里就可以采用這樣的策略：在本地記錄用戶的操作記錄亭姥，當(dāng)記錄滿30條的時(shí)候發(fā)起一次請(qǐng)求將操作記錄上傳到服務(wù)器稼钩。然后每次App啟動(dòng)的時(shí)候，上傳一次上次遺留下來(lái)沒(méi)上傳的操作記錄达罗。這樣能夠有效降低用戶設(shè)備的耗電量坝撑，同時(shí)提升網(wǎng)絡(luò)層的性能。
小總結(jié)
針對(duì)建立連接這部分的優(yōu)化就是這樣的原則：能不發(fā)請(qǐng)求的就盡量不發(fā)請(qǐng)求粮揉，必須要發(fā)請(qǐng)求時(shí)巡李，能合并請(qǐng)求的就盡量合并請(qǐng)求。然而扶认，任何優(yōu)化手段都是有前提的侨拦，而且也不能保證對(duì)所有需求都能起作用，有些API請(qǐng)求就是不符合這些優(yōu)化手段前提的辐宾，那就老老實(shí)實(shí)發(fā)請(qǐng)求吧狱从。不過(guò)這類API請(qǐng)求所占比例一般不大膨蛮，大部分的請(qǐng)求都或多或少符合優(yōu)化條件，所以針對(duì)發(fā)送請(qǐng)求的優(yōu)化手段還是值得做的季研。
1.2 & 1.3 針對(duì)DNS域名解析做的優(yōu)化敞葛，以及建立鏈接的優(yōu)化
其實(shí)在整個(gè)DNS鏈路上也是有DNS緩存的，理論上也是能夠提高速度的与涡。這個(gè)鏈路上的DNS緩存在PC用戶上效果明顯惹谐，因?yàn)镻C用戶的DNS鏈路相對(duì)穩(wěn)定，信號(hào)源不會(huì)變來(lái)變?nèi)サ莼Α５窃谝苿?dòng)設(shè)備的用戶這邊豺鼻，鏈路上的DNS緩存所帶來(lái)的性能提升就不太明顯了。因?yàn)橐苿?dòng)設(shè)備的實(shí)際使用場(chǎng)景比較復(fù)雜款慨，網(wǎng)絡(luò)信號(hào)源會(huì)經(jīng)常變換，信號(hào)源每變換一次谬莹，對(duì)應(yīng)的DNS解析鏈路就會(huì)變換一次檩奠，那么原鏈路上的DNS緩存就不起作用了。而且信號(hào)源變換的情況特別特別頻繁附帽，所以對(duì)于移動(dòng)設(shè)備用戶來(lái)說(shuō)埠戳，鏈路的DNS緩存我們基本上可以默認(rèn)為沒(méi)有。所以大部分時(shí)間是手機(jī)系統(tǒng)自帶的本地DNS緩存在起作用蕉扮，但是一般來(lái)說(shuō)整胃，移動(dòng)設(shè)備上網(wǎng)的需求也特別頻繁，專門為我們這個(gè)App所做的DNS緩存很有可能會(huì)被別的DNS緩存給擠出去被清理掉喳钟，這種情況是特別多的屁使，用戶看一會(huì)兒知乎刷一下微博查一下地圖逛一逛點(diǎn)評(píng)再聊個(gè)Q，回來(lái)之后很有可能屬于你自己的App的本地DNS緩存就沒(méi)了奔则。這還沒(méi)完蛮寂，這里還有一個(gè)只有在中國(guó)特色社會(huì)主義的互聯(lián)網(wǎng)環(huán)境中才會(huì)有的問(wèn)題：國(guó)內(nèi)的互聯(lián)網(wǎng)環(huán)境由于GFW的存在，就使得DNS服務(wù)速度會(huì)比正常情況慢不少易茬。
基于以上三個(gè)原因所導(dǎo)致的最終結(jié)果就是酬蹋，API請(qǐng)求在DNS解析階段的耗時(shí)會(huì)很多。
那么針對(duì)這個(gè)的優(yōu)化方案就是抽莱，索性直接走IP請(qǐng)求范抓，那不就繞過(guò)DNS服務(wù)的耗時(shí)了嘛。
另外一個(gè)食铐，就是上面提到的建立鏈接時(shí)候的第三步匕垫，國(guó)內(nèi)的網(wǎng)絡(luò)環(huán)境分北網(wǎng)通南電信（當(dāng)然實(shí)際情況更復(fù)雜，這里隨便說(shuō)說(shuō)）璃岳，不同服務(wù)商之間的連接年缎，延時(shí)是很大的悔捶，我們需要想辦法讓用戶在最適合他的IP上給他提供服務(wù)，那么就針對(duì)我們繞過(guò)DNS服務(wù)的手段有一個(gè)額外要求：盡可能不要讓用戶使用對(duì)他來(lái)說(shuō)很慢的IP单芜。
所以綜上所述蜕该，方案就應(yīng)該是這樣：本地有一份IP列表，這些IP是所有提供API的服務(wù)器的IP洲鸠，每次應(yīng)用啟動(dòng)的時(shí)候堂淡，針對(duì)這個(gè)列表里的所有IP取ping延時(shí)時(shí)間，然后取延時(shí)時(shí)間最小的那個(gè)IP作為今后發(fā)起請(qǐng)求的IP地址扒腕。
針對(duì)建立連接的優(yōu)化手段其實(shí)是跟DNS域名解析的優(yōu)化手段是一樣的绢淀。不過(guò)這需要你的服務(wù)器提供服務(wù)的網(wǎng)絡(luò)情況要多，一般現(xiàn)在的服務(wù)器都是雙網(wǎng)卡瘾腰，電信和網(wǎng)通皆的。由于中國(guó)特色的互聯(lián)網(wǎng)ISP分布，南北網(wǎng)絡(luò)之間存在瓶頸蹋盆，而我們App針對(duì)鏈接的優(yōu)化手段主要就是著手于如何減輕這個(gè)瓶頸對(duì)App產(chǎn)生的影響费薄，所以需要維護(hù)一個(gè)IP列表，這樣就能就近連接了栖雾，就起到了優(yōu)化的效果楞抡。
我們一般都是在應(yīng)用啟動(dòng)的時(shí)候獲得本地列表中所有IP的ping值，然后通過(guò)NSURLProtocol的手段將URL中的HOST修改為我們找到的最快的IP析藕。另外召廷，這個(gè)本地IP列表也會(huì)需要通過(guò)一個(gè)API來(lái)維護(hù)，一般是每天第一次啟動(dòng)的時(shí)候讀一次API账胧，然后更新到本地竞慢。
如果你還不熟悉NSURLProtocol應(yīng)該怎么玩，看完官方文檔和這篇文章以及這個(gè)Demo之后找爱，你肯定就會(huì)了梗顺，其實(shí)很簡(jiǎn)單的。另外车摄，剛才提到那篇文章的作者(mattt)還寫了這個(gè)基于NSURLProtocol的工具寺谤，相當(dāng)好用，是可以直接拿來(lái)集成到項(xiàng)目中的吮播。
不用NSURLProtocol的話变屁，用其他手段也可以做到這一點(diǎn)，但那些手段未免又比較愚蠢意狠。
2. 針對(duì)鏈接傳輸數(shù)據(jù)量的優(yōu)化
這個(gè)很好理解粟关，傳輸?shù)臄?shù)據(jù)少了，那么自然速度就上去了环戈。這里沒(méi)什么花樣可以講的闷板，就是壓縮唄澎灸。各種壓縮。
3. 針對(duì)鏈接復(fù)用的優(yōu)化
建立鏈接本身是屬于比較消耗資源的操作遮晚，耗電耗時(shí)性昭。SPDY自帶鏈接復(fù)用以及數(shù)據(jù)壓縮的功能，所以服務(wù)端支持SPDY的時(shí)候县遣，App直接掛SPDY就可以了糜颠。如果服務(wù)端不支持SPDY，也可以使用PipeLine萧求，蘋果原生自帶這個(gè)功能其兴。
一般來(lái)說(shuō)業(yè)界內(nèi)普遍的認(rèn)識(shí)是SPDY優(yōu)于PipeLine，然后即便如此夸政，SPDY能夠帶來(lái)的網(wǎng)絡(luò)層效率提升其實(shí)也沒(méi)有文獻(xiàn)上的圖表那么明顯元旬，但還是有性能提升的。還有另外一種比較笨的鏈接復(fù)用的方法守问，就是維護(hù)一個(gè)隊(duì)列法绵，然后將隊(duì)列里的請(qǐng)求壓縮成一個(gè)請(qǐng)求發(fā)出去，之所以會(huì)存在滯留在隊(duì)列中的請(qǐng)求酪碘，是因?yàn)樵谏弦粋€(gè)請(qǐng)求還在外面飄的時(shí)候。這種做法最終的效果表面上看跟鏈接復(fù)用差別不大盐茎，但并不是真正的鏈接復(fù)用兴垦，只能說(shuō)是請(qǐng)求合并。
還是說(shuō)回來(lái)字柠，我建議最好是用SPDY探越，SPDY和pipeline雖然都屬于鏈接復(fù)用的范疇，但是pipeline并不是真正意義上的鏈接復(fù)用窑业，SPDY的鏈接復(fù)用相對(duì)pipeline而言更為徹底钦幔。SPDY目前也有現(xiàn)成的客戶端SDK可以使用，一個(gè)是twitter的CocoaSPDY常柄，另一個(gè)是Voxer/iSPDY鲤氢，這兩個(gè)庫(kù)都很活躍，大家可以挑合適的采用西潘。
不過(guò)目前業(yè)界趨勢(shì)是傾向于使用HTTP/2.0來(lái)代替SPDY卷玉，不過(guò)目前HTTP/2.0還沒(méi)有正式出臺(tái)，相關(guān)實(shí)現(xiàn)大部分都處在demo階段喷市，所以我們還是先SPDY搞起就好了相种。未來(lái)很有可能會(huì)放棄SPDY，轉(zhuǎn)而采用HTTP/2.0來(lái)實(shí)現(xiàn)網(wǎng)絡(luò)的優(yōu)化品姓。這是要提醒各位架構(gòu)師注意的事情寝并。嗯箫措，我也不知道HTTP/2.0什么時(shí)候能出來(lái)。
漁說(shuō)完了衬潦，魚來(lái)了
這里是我當(dāng)年設(shè)計(jì)并實(shí)現(xiàn)的安居客的網(wǎng)絡(luò)層架構(gòu)代碼斤蔓。當(dāng)然，該脫敏的地方我都已經(jīng)脫敏了别渔，所以編不過(guò)是正常的附迷，哈哈哈。但是代碼比較齊全哎媚，重要地方注釋我也寫了很多喇伯。另外，為了讓大家能夠把這些代碼看明白拨与，我還附帶了當(dāng)年介紹這個(gè)框架演講時(shí)的PPT稻据。(補(bǔ)充說(shuō)明一下，評(píng)論區(qū)好多人問(wèn)PPT找不著在哪兒买喧，PPT也在上面提到的repo里面捻悯，是個(gè)key后綴名的文件，用keynote打開(kāi))
然后就是淤毛，當(dāng)年也有很多問(wèn)題其實(shí)考慮得并沒(méi)有現(xiàn)在清楚今缚，所以有些地方還是做得不夠好，比如攔截器和繼承低淡。而且當(dāng)時(shí)的優(yōu)化手段只有本地cache姓言，安居客沒(méi)有那么多IP可以給我ping，當(dāng)年也沒(méi)流行SPDY蔗蹋，而且API也還不支持HTTPS何荚，所以當(dāng)時(shí)的代碼里面沒(méi)有在這些地方做優(yōu)化，比較原始猪杭。然而整個(gè)架構(gòu)的基本思路一直沒(méi)有變化：優(yōu)先服務(wù)于業(yè)務(wù)方餐塘。另外，安居客的網(wǎng)絡(luò)層多了一個(gè)service的概念皂吮，這是我這篇文章中沒(méi)有講的戒傻。主要是因?yàn)榘簿涌偷腁PI提供方很多，二手房涮较，租房稠鼻，新房，X項(xiàng)目等等API都是不同的API team提供的狂票，以service作區(qū)分候齿，如果你的app也是類似的情況，我也建議你設(shè)計(jì)一套service機(jī)制。現(xiàn)在這些service被我刪得只剩下一個(gè)google的service慌盯，因?yàn)槠渌鹲ervice都屬于敏感內(nèi)容周霉。
另外，這里面提供的PPT我很希望大家能夠花時(shí)間去看看亚皂，在PPT里面有些更加細(xì)的東西我在博客里沒(méi)有寫俱箱，主要是我比較懶，然后這篇文章拖的時(shí)間比較長(zhǎng)了灭必，花時(shí)間搬運(yùn)這個(gè)沒(méi)什么意思狞谱，不過(guò)內(nèi)容還是值得各位讀者去看的。關(guān)于PPT里面大家有什么問(wèn)題的禁漓，也可以在評(píng)論區(qū)問(wèn)跟衅，我都會(huì)回答。
總結(jié)
第一部分主要講了網(wǎng)絡(luò)層應(yīng)當(dāng)如何跟業(yè)務(wù)層進(jìn)行數(shù)據(jù)交互播歼，進(jìn)行數(shù)據(jù)交互時(shí)采用怎樣的數(shù)據(jù)格式伶跷，以及設(shè)計(jì)時(shí)代碼結(jié)構(gòu)上的一些問(wèn)題，諸如繼承的處理秘狞，回調(diào)的處理叭莫，交互方式的選擇，reformer的設(shè)計(jì)烁试，保持?jǐn)?shù)據(jù)可讀性等等等等雇初，主要偏重于設(shè)計(jì)（這可是藝術(shù)活，哈哈哈）减响。
第二部分講了網(wǎng)絡(luò)安全上抵皱，客戶端要做的兩點(diǎn)。當(dāng)然辩蛋，從網(wǎng)絡(luò)安全的角度上講，服務(wù)端也要做很多很多事情移盆，客戶端要做的一些邊角細(xì)節(jié)的事情也還會(huì)有很多悼院，比如做一些代碼混淆，盡可能避免代碼中明文展示key咒循。不過(guò)大頭主要就是這兩個(gè)据途，而且也都是需要服務(wù)端同學(xué)去配合的。主要偏重于介紹叙甸。（主要是也沒(méi)啥好實(shí)踐的颖医，google一下教程照著來(lái)就好了）。
第三部分講了優(yōu)化裆蒸，優(yōu)化的所有方面都已經(jīng)列出來(lái)了熔萧，如果業(yè)界再有七七八八的別的手段，也基本逃離不出本文的范圍。這里有些優(yōu)化手段是需要服務(wù)端同學(xué)配合的佛致，有些不需要贮缕，大家看各自情況來(lái)決定。主要偏重于實(shí)踐俺榆。
最后給出了我之前在安居客做的網(wǎng)絡(luò)層架構(gòu)的主要代碼感昼，以及當(dāng)時(shí)演講時(shí)的PPT。關(guān)于代碼或PPT中有任何問(wèn)題罐脊，都可以在評(píng)論區(qū)問(wèn)我定嗓。
這一篇文章出得比較晚，因?yàn)楣镜氖虑槠甲溃虚g間隔了一個(gè)禮拜宵溅，希望大家諒解。另外梗夸，隔了一個(gè)禮拜之后我再寫层玲，發(fā)現(xiàn)有些地方我已經(jīng)想不起來(lái)當(dāng)初是應(yīng)該怎么行文下去的了，然后發(fā)之前我把文章又看了幾遍反症，盡可能把斷片的地方抹平了辛块，如果大家讀起來(lái)有什么地方感覺(jué)奇怪的，或者講到一半就沒(méi)了的，那應(yīng)該就是斷片了。在評(píng)論區(qū)跟我說(shuō)一下啃憎，我補(bǔ)上去鱼响。
然后如果有需要勘誤的地方，也請(qǐng)?jiān)谠u(píng)論區(qū)指出谈飒，幫助我把錯(cuò)的地方訂正回來(lái)，如果有沒(méi)講到的地方，但你又特別想要了解的卿捎，也可以在評(píng)論區(qū)提出來(lái)，我會(huì)補(bǔ)上去径密。說(shuō)不定看完之后你腦袋里還會(huì)有很多個(gè)問(wèn)號(hào)午阵，也請(qǐng)?jiān)谠u(píng)論區(qū)問(wèn)出來(lái)哈，說(shuō)不定別人也有跟你一樣的問(wèn)題享扔，他就能在評(píng)論區(qū)找到答案了底桂。
在第二篇文章的評(píng)論區(qū)里面出現(xiàn)了噴子，遇到這種情況我怎么可能刪帖呢惧眠？那根本就不是我的風(fēng)格哇籽懦，哈哈哈。我肯定是會(huì)噴回去的氛魁，并且還會(huì)把鏈接傳播給周圍人暮顺，發(fā)動(dòng)周圍朋友來(lái)看:"快看厅篓，這兒有2B，哈哈哈"拖云。
嗯贷笛，所以評(píng)論的時(shí)候你一定要想清楚哈，我寫代碼的實(shí)力不差宙项，打嘴仗的實(shí)力那可比寫代碼強(qiáng)多了乏苦。評(píng)論區(qū)同樣歡迎切磋。
有任何問(wèn)題建議直接在評(píng)論區(qū)提問(wèn)尤筐，這樣后來(lái)的人如果有相同的問(wèn)題汇荐，就能直接找到答案了。提問(wèn)之前也可以先看看評(píng)論區(qū)有沒(méi)有人問(wèn)過(guò)類似問(wèn)題了盆繁。
所有評(píng)論和問(wèn)題我都會(huì)在第一時(shí)間回復(fù)掀淘，QQ上我是不回答問(wèn)題的哈。
評(píng)論系統(tǒng)我用的是Disqus油昂，不定期被墻革娄。所以如果你看到文章下面沒(méi)有加載出評(píng)論列表，翻個(gè)墻就有了冕碟。
本文遵守CC-BY拦惋。 請(qǐng)保持轉(zhuǎn)載后文章內(nèi)容的完整，以及文章出處安寺。本人保留所有版權(quán)相關(guān)權(quán)利厕妖。
我的博客拒絕掛任何廣告，如果您覺(jué)得文章有價(jià)值挑庶，可以通過(guò)支付寶掃描下面的二維碼捐助我言秸。
