一年前，當(dāng)Casa剛寫(xiě)出這個(gè)系列的文章的時(shí)候关贵，因?yàn)閷?duì)整個(gè)系統(tǒng)框架還出于學(xué)習(xí)狀態(tài)怒详，開(kāi)發(fā)也只是為做而做悲柱。因?yàn)橹翱偸窃谧鐾獍?xiàng)目怀薛，對(duì)一個(gè)產(chǎn)品悯许，整個(gè)架構(gòu)了解甚少。也是從前年開(kāi)始炭剪，進(jìn)入家真正的互聯(lián)網(wǎng)產(chǎn)品公司练链，加深了對(duì)架構(gòu)方面的理解。最近奴拦，因?yàn)楣疽驯緫?yīng)該寫(xiě)兩個(gè)app 的產(chǎn)品要合并成一個(gè)媒鼓，所以，對(duì)于架構(gòu)粱坤，框架的理解要更深一步的去了解隶糕。故重讀關(guān)于架構(gòu)方面的文章，并結(jié)合自己所做的app站玄，做一個(gè)讀書(shū)筆記枚驻。
原文地址：iOS應(yīng)用架構(gòu)談 網(wǎng)絡(luò)層設(shè)計(jì)方案
下面是對(duì)文章分節(jié)筆記和自己的見(jiàn)解：
前言：
網(wǎng)絡(luò)請(qǐng)求部分，確實(shí)蘋(píng)果封裝的很好株旷。在業(yè)界再登，AFNetworking確實(shí)已成為App的標(biāo)配。我在第一家公司使用的就是AFNetworking 晾剖。而現(xiàn)在的除了圖片上傳阿里云使用的是蘋(píng)果自帶的網(wǎng)絡(luò)請(qǐng)求（這部分是另外一個(gè)同事做的锉矢，我并沒(méi)有去分析其代碼，還是決定用一種請(qǐng)求即可）
正如所說(shuō)齿尽，網(wǎng)絡(luò)層在一個(gè)App中承載著API調(diào)用沽损，用戶(hù)操作日志記錄，即時(shí)通訊等任務(wù)循头。網(wǎng)絡(luò)層這一塊的設(shè)計(jì)方案是千變?nèi)f化绵估，大家也都是各顯神通展示各種技巧炎疆。文中說(shuō)道，會(huì)提出自己觀(guān)點(diǎn)国裳，不中立形入。我個(gè)人覺(jué)得甚是中肯。所以也是在摸索中缝左，去將文中的方案亿遂，盡可能的理解的最深最優(yōu)化。
這篇文章分了三個(gè)方面來(lái)講：
1.網(wǎng)絡(luò)層跟業(yè)務(wù)對(duì)接部分的設(shè)計(jì)
2.網(wǎng)絡(luò)層的安全機(jī)制實(shí)現(xiàn)
3.網(wǎng)絡(luò)層的優(yōu)化方案

網(wǎng)絡(luò)層跟業(yè)務(wù)對(duì)接部分的設(shè)計(jì)

這本文Casa就這個(gè)分了三個(gè)問(wèn)題來(lái)討論怎么去設(shè)計(jì)

1.使用哪種交互模式跟業(yè)務(wù)層做對(duì)接渺杉？

說(shuō)到交互模式蛇数，那就要討論數(shù)據(jù)流向業(yè)務(wù)層的表現(xiàn)形式，這里又有兩個(gè)問(wèn)題
1.以什么方式將數(shù)據(jù)交付給業(yè)務(wù)層
2.交付什么樣的數(shù)據(jù)給業(yè)務(wù)層
以什么方式將數(shù)據(jù)交付給業(yè)務(wù)層少办，僅限于我目前開(kāi)發(fā)所見(jiàn)到的網(wǎng)絡(luò)層采用的方式有：Delegate,Block,Notification苞慢。我更多的使用Block這種方式。當(dāng)然各種差異區(qū)別還有原因英妓，我傾向于使用簡(jiǎn)單的代碼風(fēng)格，所以會(huì)用block绍赛，但是至于到底哪個(gè)最好蔓纠，還是要看具體的實(shí)際情況來(lái)定奪吧。
文中吗蚌，給出的建議是以delegate為主腿倚，notification為輔。也羅列的原因：
1>盡可能減少跨層數(shù)據(jù)交流的可能蚯妇，限制耦合
2>統(tǒng)一回調(diào)方法敷燎，便于調(diào)試和維護(hù)
3>在跟業(yè)務(wù)層對(duì)接的部分只采用一種對(duì)接手段限制靈活性，以此來(lái)交換應(yīng)用的可維護(hù)性
事實(shí)上箩言，網(wǎng)絡(luò)層定義好以后硬贯，以上的方式，都可以對(duì)應(yīng)上面的方法陨收，只需要統(tǒng)一優(yōu)化饭豹。當(dāng)然Casa也詳細(xì)對(duì)這些原因作了解釋。也就是在網(wǎng)絡(luò)層务漩，要限制跨級(jí)使用拄衰，定制好規(guī)范。文中專(zhuān)門(mén)把block拉出來(lái)饵骨，說(shuō)了他的使用弊端翘悉。對(duì)于block，可是使代碼簡(jiǎn)潔居触。不過(guò)難追蹤妖混，難維護(hù)（加重點(diǎn)）確實(shí)不太好處理包吝，但是也可以用打印方式來(lái)去看的，所以源葫，我并不覺(jué)得這個(gè)是問(wèn)題诗越。不過(guò)指出block回延長(zhǎng)相關(guān)對(duì)象生命周期，這點(diǎn)息堂，有關(guān)效率部分嚷狞，我無(wú)法反駁，確實(shí)荣堰，對(duì)于注重內(nèi)存的床未，這個(gè)無(wú)法忍受。我是同意的振坚。之后薇搁，他提出了block在離散型場(chǎng)景下不符合使用的規(guī)范。這個(gè)地方我還沒(méi)有深入了解過(guò)渡八，所以不予評(píng)論啃洋。算是一個(gè)學(xué)習(xí)點(diǎn)。不過(guò)在這里Casa也說(shuō)出了關(guān)于為什么大多數(shù)公司使用的是block屎鳍。
之后的關(guān)于統(tǒng)一回調(diào)方法中宏娄，文中列舉了關(guān)于block的回調(diào)方法問(wèn)題，并寫(xiě)出自己的建議逮壁，覺(jué)得是可以借鑒吸收的孵坚，這樣優(yōu)雅的代碼方式，簡(jiǎn)直了窥淆。所以卖宠，接下來(lái)的如果代碼重構(gòu)，想嘗試一下忧饭。
最后的總結(jié)我想在這里強(qiáng)調(diào)下：
綜上扛伍，對(duì)于以什么方式將數(shù)據(jù)交付給業(yè)務(wù)層？這個(gè)問(wèn)題的回答是這樣：
盡可能通過(guò)Delegate的回調(diào)方式交付數(shù)據(jù)眷昆，這樣可以避免不必要的跨層訪(fǎng)問(wèn)蜒秤。當(dāng)出現(xiàn)跨層訪(fǎng)問(wèn)的需求時(shí)（比如信號(hào)類(lèi)型切換），通過(guò)Notification的方式交付數(shù)據(jù)亚斋。正常情況下應(yīng)該是避免使用Block的作媚。

交付什么樣的數(shù)據(jù)給業(yè)務(wù)層
這個(gè)Casa提出了自己的見(jiàn)解，把眾多app通用處理方式批了一頓帅刊。否定了將數(shù)據(jù)轉(zhuǎn)變成對(duì)應(yīng)的對(duì)象原型種種問(wèn)題成本纸泡。然后提出自己的解決方案，添加了reformer這個(gè)對(duì)象用于封裝數(shù)據(jù)轉(zhuǎn)化的邏輯赖瞒，這個(gè)對(duì)象是一個(gè)獨(dú)立對(duì)象女揭，事實(shí)上蚤假，它是作為Adaptor模式存在的。覺(jué)得是一個(gè)很好的處理方式吧兔。
數(shù)據(jù)采用NSDictionary加Const字符串key來(lái)表征磷仰，避免了使用對(duì)象來(lái)表征帶來(lái)的遷移困難，同時(shí)不失去可讀性境蔼，但是對(duì)于喜歡用點(diǎn)語(yǔ)法的人灶平，對(duì)此，進(jìn)行代碼編寫(xiě)感覺(jué)有些不流暢箍土，畢竟括號(hào)比點(diǎn)逢享，點(diǎn)更常用。
之后著重講解了離散型和集約型設(shè)計(jì)吴藻，給出建議網(wǎng)絡(luò)上層使用離散型設(shè)計(jì)瞒爬，下部分使用集約型設(shè)計(jì)。也提出應(yīng)該合理利用繼承機(jī)制沟堡。
其實(shí)以上應(yīng)該是Casa花費(fèi)了大量時(shí)間去思考來(lái)寫(xiě)的侧但，下面的更多的是底層的通用處理方式了，當(dāng)然一些優(yōu)化弦叶，實(shí)際上在客戶(hù)端俊犯，并不會(huì)感受那么深刻，所以總覺(jué)得有些倉(cāng)促結(jié)尾了伤哺。不過(guò)還是按照上面的來(lái)發(fā)表下自己的看法。

網(wǎng)絡(luò)層的安全機(jī)制

1.判斷API的調(diào)用請(qǐng)求是來(lái)自于經(jīng)過(guò)授權(quán)的APP
這里要考慮兩點(diǎn)
1.確保API的調(diào)用者是來(lái)自你自己的APP者祖，防止競(jìng)爭(zhēng)對(duì)手爬你的API
2.如果你對(duì)外提供了需要注冊(cè)才能使用的API平臺(tái)立莉，那么你需要有這個(gè)機(jī)制來(lái)識(shí)別是否是注冊(cè)用戶(hù)調(diào)用了你的API
解決方案：設(shè)計(jì)簽名
這個(gè)也是大家在與服務(wù)端開(kāi)發(fā)人員協(xié)商制定的。通用處理方式七问，就是密鑰加密蜓耻。這里沒(méi)什么可討論的。
2.保證傳輸數(shù)據(jù)的安全
這里目的在于：
1.防止中間人攻擊械巡，比如說(shuō)運(yùn)營(yíng)商很喜歡往用戶(hù)的Http請(qǐng)求里面塞廣告...
2.SPDY依賴(lài)于HTTPS刹淌，而且是未來(lái)HTTP/2的基礎(chǔ)，他們能夠提高你APP在網(wǎng)絡(luò)層整體的性能
解決方案：HTTPS
文中有提到使用SPDY是我未知領(lǐng)域讥耗，待研究有勾。

網(wǎng)絡(luò)層的優(yōu)化方案

這個(gè)部分，是精益求精古程，就目前來(lái)說(shuō)蔼卡，個(gè)人感覺(jué)，應(yīng)該對(duì)于網(wǎng)絡(luò)影響不是特別大挣磨。也未涉事了解過(guò)雇逞，所以荤懂，大家還是看原文了。