摘要：iOS客戶端應(yīng)用架構(gòu)看似簡單，但實(shí)際上要考慮的事情不少。本文作者將以系列文章的形式來回答iOS應(yīng)用架構(gòu)中的種種問題懊烤，本文是其中的第一篇，主要講架構(gòu)設(shè)計(jì)的通識和方法論等宽堆，同時還討論了大家關(guān)心的架構(gòu)分層腌紧、是否要有common文件夾等問題。
緣由
之前安居客iOS app的第二版架構(gòu)大部分內(nèi)容是我做的畜隶，期間有總結(jié)了一些經(jīng)驗(yàn)壁肋。在將近一年之后，前同事zzz在微信朋友圈上發(fā)了一個問題：假如問你一個iOS or Android app的架構(gòu)籽慢，你會從哪些方面來說呢浸遗？
當(dāng)時看到這個問題正好在乘公車回家的路上，閑來無聊就答了一把箱亿。在zzz在微信朋友圈上追問了幾個問題之后跛锌，我覺得有必要以文章形式專門來講一些個人見解。
其實(shí)對于iOS客戶端應(yīng)用的架構(gòu)來說届惋，復(fù)雜度不亞于服務(wù)端髓帽，但側(cè)重點(diǎn)和入手點(diǎn)卻跟服務(wù)端不太一樣。比如客戶端應(yīng)用就不需要考慮類似C10K的問題盼樟，正常的app就根本不需要考慮氢卡。
這系列文章我會主要專注在iOS應(yīng)用架構(gòu)方面，很多方案也是基于iOS技術(shù)棧的特點(diǎn)而建立的晨缴。因?yàn)槲覀€人不是很喜歡寫Java译秦，所以Android這邊的我就不太了解了。如果你是Android開發(fā)者击碗，你可以側(cè)重看我提出的一些架構(gòu)思想筑悴，畢竟不管做什么，思路是相通的稍途，實(shí)現(xiàn)手段不同罷了阁吝。
當(dāng)我們討論客戶端應(yīng)用架構(gòu)的時候，我們在討論什么械拍？
其實(shí)市面上大部分應(yīng)用不外乎就是顛過來倒過去地做以下這些事情：
簡單來說就是調(diào)API突勇，展示頁面，然后跳轉(zhuǎn)到別的地方再調(diào)API坷虑，再展示頁面甲馋。
那這有什么好架構(gòu)的？
非也迄损，非也定躏。 ---- 包不同 《天龍八部》
App確實(shí)就是主要做這些事情，但是支撐這些事情的基礎(chǔ)，就是做架構(gòu)要考慮的事情：
調(diào)用網(wǎng)絡(luò)API痊远。如何讓業(yè)務(wù)開發(fā)工程師方便安全地調(diào)用網(wǎng)絡(luò)API垮抗？然后盡可能保證用戶在各種網(wǎng)絡(luò)環(huán)境下都能有良好的體驗(yàn)？
頁面展示碧聪。頁面如何組織冒版，才能盡可能降低業(yè)務(wù)方代碼的耦合度？盡可能降低業(yè)務(wù)方開發(fā)界面的復(fù)雜度矾削，提高他們的效率壤玫？
數(shù)據(jù)的本地持久化。當(dāng)數(shù)據(jù)有在本地存取的需求的時候哼凯，如何能夠保證數(shù)據(jù)在本地的合理安排？如何盡可能地減小性能消耗楚里？
動態(tài)部署方案断部。iOS應(yīng)用有審核周期，如何能夠通過不發(fā)版本的方式展示新的內(nèi)容給用戶班缎？如何修復(fù)緊急bug蝴光？
上面幾點(diǎn)是針對App說的，下面還有一些是針對團(tuán)隊(duì)說的：
收集用戶數(shù)據(jù)达址，給產(chǎn)品和運(yùn)營提供參考
合理地組織各業(yè)務(wù)方開發(fā)的業(yè)務(wù)模塊蔑祟，以及相關(guān)基礎(chǔ)模塊
每日app的自動打包，提供給QA工程師的測試工具
一時半會兒我還是只能想到上面這三點(diǎn)沉唠，事實(shí)上應(yīng)該還會有很多疆虚，這里就不一一列舉了。
所以當(dāng)我們討論客戶端應(yīng)用架構(gòu)的時候满葛，我們討論的差不多就是這些問題径簿。
這系列文章要回答哪些問題？
這系列文章主要是回答以下這些問題：
網(wǎng)絡(luò)層設(shè)計(jì)方案嘀韧？設(shè)計(jì)網(wǎng)絡(luò)層時要考慮哪些問題篇亭？對網(wǎng)絡(luò)層做優(yōu)化的時候，可以從哪些地方入手锄贷？
頁面的展示译蒂、調(diào)用和組織都有哪些設(shè)計(jì)方案？我們做這些方案的時候都要考慮哪些問題谊却？
本地持久化層的設(shè)計(jì)方案都有哪些柔昼？優(yōu)劣勢都是什么？不同方案間要注意的問題分別都是什么因惭？
要實(shí)現(xiàn)動態(tài)部署岳锁，都有哪些方案？不同方案之間的優(yōu)劣點(diǎn)蹦魔，他們的側(cè)重點(diǎn)激率？
本文要回答那些問題咳燕？
上面細(xì)分出來的四個問題，我會分別在四篇文章里面寫乒躺。那么這篇文章就是來講一些通識啥的招盲，也是開個坑給大家討論通識問題的。
架構(gòu)設(shè)計(jì)的方法
所有事情最難的時候都是開始做的時候嘉冒，當(dāng)你開始著手設(shè)計(jì)并實(shí)現(xiàn)某一層的架構(gòu)乃至整個app的架構(gòu)的時候曹货，很有可能會出現(xiàn)暫時的無從下手的情況。以下方法論是我這些年總結(jié)出來的經(jīng)驗(yàn)讳推，每個架構(gòu)師也一定都有一套自己的方法論顶籽，但一樣的是，不管你采用什么方法银觅，全局觀礼饱、高度的代碼審美能力、靈活使用各種設(shè)計(jì)模式一定都是貫穿其中的究驴。歡迎各位在評論區(qū)討論镊绪。
第一步：搞清楚要解決哪些問題，并找到解決這些問題的充要條件
你必須得清楚你要做什么洒忧，業(yè)務(wù)方希望要什么蝴韭。而不是為了架構(gòu)而架構(gòu)，也不是為了體驗(yàn)新技術(shù)而改架構(gòu)方案熙侍。以前是MVC榄鉴，最近流行MVVM，如果過去的MVC是個好架構(gòu)核行，沒什么特別大的缺陷牢硅，就不要推倒然后搞成MVVM。
關(guān)于充要條件我也要說明一下芝雪，有的時候系統(tǒng)提供的函數(shù)是需要額外參數(shù)的减余，比如read函數(shù)。還有翻頁的時候惩系，當(dāng)前頁碼也是充要條件位岔。但對于業(yè)務(wù)方來說，這些充要條件還能夠再縮減堡牡。
比如read抒抬，需要給出file descriptor，需要給出buf晤柄，需要給出size擦剑。但是對于業(yè)務(wù)方來說，充要條件就只要file descriptor就夠了。再比如翻頁惠勒，其實(shí)業(yè)務(wù)方并不需要記錄當(dāng)前頁號赚抡，你給他暴露一個loadNextPage這樣的方法就夠了。
搞清楚對于業(yè)務(wù)方而言的真正充要條件很重要纠屋！這決定了你的架構(gòu)是否足夠易用涂臣。另外，傳的參數(shù)越少售担，耦合度相對而言就越小赁遗，你替換模塊或者升級模塊所花的的代價就越小。
第二步：問題分類族铆，分模塊
這個不用多說了吧岩四。
第三步：搞清楚各問題之間的依賴關(guān)系，建立好模塊交流規(guī)范并設(shè)計(jì)模塊
關(guān)鍵在于建立一套統(tǒng)一的交流規(guī)范骑素。這一步很能夠體現(xiàn)架構(gòu)師在軟件方面的價值觀炫乓，雖然存在一定程度上的好壞優(yōu)劣（比如胖Model和瘦Model），但既然都是架構(gòu)師了献丑，基本上是不會設(shè)計(jì)出明顯很爛的方案的，除非這架構(gòu)師還不夠格侠姑。所以這里是架構(gòu)師價值觀輸出的一個窗口创橄，從這一點(diǎn)我們是能夠看出架構(gòu)師的素質(zhì)的。
另外要注意的是莽红，一定是建立一套統(tǒng)一的交流規(guī)范妥畏，不是兩套，不是多套安吁。你要堅(jiān)持你的價值觀醉蚁，不要搖擺不定。要是搞出各種五花八門的規(guī)范出來鬼店，一方面有不切實(shí)際的炫技嫌疑网棍，另一方面也會帶來后續(xù)維護(hù)的災(zāi)難。
第四步：推演預(yù)測一下未來可能的走向妇智，必要時添加新的模塊滥玷，記錄更多的基礎(chǔ)數(shù)據(jù)以備未來之需
很多稱職的架構(gòu)師都會在這時候考慮架構(gòu)未來的走向，以及考慮做完這一輪架構(gòu)之后巍棱，接下來要做的事情惑畴。一個好的架構(gòu)雖然是功在當(dāng)代利在千秋的工程，但絕對不是一個一勞永逸的工程航徙。軟件是有生命的如贷，你做出來的架構(gòu)決定了這個軟件它這一生是坎坷還是幸福。
第五步：先解決依賴關(guān)系中最基礎(chǔ)的問題，實(shí)現(xiàn)基礎(chǔ)模塊杠袱，然后再用基礎(chǔ)模塊堆疊出整個架構(gòu)
這一步也是驗(yàn)證你之前的設(shè)計(jì)是否合理的一步尚猿，隨著這一步的推進(jìn)，你很有可能會遇到需要對架構(gòu)進(jìn)行調(diào)整的情況霞掺。這個階段一定要吹毛求疵高度負(fù)責(zé)地去開發(fā)谊路，不要得過且過，發(fā)現(xiàn)架構(gòu)有問題就及時調(diào)整菩彬。否則以后調(diào)整的成本就非常之大了缠劝。
第六步：打點(diǎn)，跑單元測試骗灶，跑性能測試惨恭，根據(jù)數(shù)據(jù)去優(yōu)化對應(yīng)的地方
你得用這些數(shù)據(jù)去向你的boss邀功，你也得用這些數(shù)據(jù)去不斷調(diào)整你的架構(gòu)耙旦。
總而言之就是要遵循這些原則：自頂向下設(shè)計(jì)（1脱羡，2，3免都，4步）锉罐，自底向下實(shí)現(xiàn)（5），先測量绕娘，后優(yōu)化（6）脓规。
什么樣的架構(gòu)師是好架構(gòu)師？
每天都在學(xué)習(xí)险领，新技術(shù)新思想上手速度快侨舆，理解速度快
做不到這點(diǎn)，你就是碼農(nóng)
業(yè)務(wù)出身绢陌，或者至少非常熟悉公司所處行業(yè)或者本公司的業(yè)務(wù)
做不到這點(diǎn)挨下，你就是運(yùn)維
熟悉軟件工程的各種規(guī)范，踩過無數(shù)坑脐湾。不會為了完成需求不擇手段臭笆，不推崇quick & dirty
做不到這點(diǎn)，你比較適合去競爭對手那兒當(dāng)工程師
及時承認(rèn)錯誤沥割，不要覺得承認(rèn)錯誤會有損你架構(gòu)師的身份
做不到這點(diǎn)耗啦，公關(guān)行業(yè)比較適合你
不為了炫技而炫技
做不到這點(diǎn)，你就是高中編程愛好者
精益求精
做不到這點(diǎn)机杜，（我想了好久帜讲，但我還是不知道你適合去干什么。）
什么樣的架構(gòu)叫好架構(gòu)椒拗？
代碼整齊似将，分類明確获黔，沒有common，沒有core
不用文檔在验，或很少文檔玷氏，就能讓業(yè)務(wù)方上手
思路和方法要統(tǒng)一，盡量不要多元
沒有橫向依賴腋舌，萬不得已不出現(xiàn)跨層訪問
對業(yè)務(wù)方該限制的地方有限制盏触，該靈活的地方要給業(yè)務(wù)方創(chuàng)造靈活實(shí)現(xiàn)的條件
易測試，易拓展
保持一定量的超前性
接口少块饺，接口參數(shù)少
高性能
以上是我判斷一個架構(gòu)是不是好架構(gòu)的標(biāo)準(zhǔn)赞辩，這是根據(jù)重要性來排列的∈诩瑁客戶端架構(gòu)跟服務(wù)端架構(gòu)要考慮的問題和側(cè)重點(diǎn)是有一些區(qū)別的辨嗽。下面我會針對每一點(diǎn)詳細(xì)講解一下：
代碼整齊，分類明確淮腾，沒有common糟需，沒有core
代碼整齊是每一個工程師的基本素質(zhì)，先不說你搞定這個問題的方案有多好谷朝，解決速度有多快洲押，如果代碼不整齊，一切都白搭圆凰。因?yàn)槟愕拇a是要給別人看的诅诱，你自己也要看。如果哪一天架構(gòu)有修改送朱，正好改到這個地方，你很容易自己都看不懂干旁。另外驶沼，破窗理論提醒我們，如果代碼不整齊分類不明確争群，整個架構(gòu)會隨著一次一次的拓展而越來越混亂回怜。
分類明確的字面意思大家一定都了解，但還有一個另外的意思换薄，那就是：不要讓一個類或者一個模塊做兩種不同的事情玉雾。如果有類或某模塊做了兩種不同的事情，一方面不適合未來拓展轻要，另一方面也會造成分類困難复旬。
不要搞Common，Core這些東西冲泥。每家公司的架構(gòu)代碼庫里面驹碍，最惡心的一定是這兩個名字命名的文件夾壁涎，我這么說一定不會錯。不要開Common志秃，Core這樣的文件夾怔球，開了之后后來者一定會把這個地方搞得一團(tuán)糟，最終變成Common也不Common浮还，Core也不Core竟坛。要記住，架構(gòu)是不斷成長的钧舌，是會不斷變化的担汤。不是每次成長每次變化，都是由你去實(shí)現(xiàn)的延刘。如果真有什么東西特別小漫试，那就索性為了他單獨(dú)開辟一個模塊就好了，小就小點(diǎn)碘赖，關(guān)鍵是要有序驾荣。
關(guān)于這一條，后面還會詳細(xì)論述普泡。
不用文檔播掷，或很少文檔，就能讓業(yè)務(wù)方上手
誰特么會去看文檔啊撼班，業(yè)務(wù)方他們已經(jīng)被產(chǎn)品經(jīng)理逼得很忙了歧匈。所以你要盡可能讓你的API名字可讀性強(qiáng)，對于iOS來說砰嘁，objc這門語言的特性把這個做到了極致件炉，函數(shù)名長就長一點(diǎn)，不要緊矮湘。
好的函數(shù)名：
(NSDictionary *)exifDataOfImage:(UIImage *)image atIndexPath:(NSIndexPath *)indexPath;
壞的函數(shù)名：(id)exifData:(UIImage *)image position:(id)indexPath callback:(id<ErrorDelegate>)delegate;
為什么壞斟冕？
不要直接返回id或者傳入id，實(shí)在不行缅阳，用id也比id好磕蛇。如果連這個都做不到，你要好好考慮你的架構(gòu)是不是有問題十办。
要告知業(yè)務(wù)方要傳的東西是什么秀撇，比如要傳Image，那就寫上ofImage向族。如果要傳位置呵燕，那就要寫上IndexPath，而不是用position這么籠統(tǒng)的東西
沒有任何理由要把delegate作為參數(shù)傳進(jìn)去炸枣，一定不會有任何情況不得不這么做的虏等。而且delegate這個參數(shù)根本不是這個函數(shù)要解決的問題的充要條件弄唧，如果你發(fā)現(xiàn)你不得不這么做，那一定是架構(gòu)有問題霍衫！
思路和方法要統(tǒng)一候引，盡量不要多元
解決一個問題會有很多種方案，但是一旦確定了一種方案敦跌，就不要在另一個地方采用別的方案了澄干。也就是做架構(gòu)的時候，你得時刻記住當(dāng)初你決定要處理這樣類型的問題的方案是什么柠傍，以及你的初衷是什么麸俘，不要搖擺不定。
另外惧笛，你當(dāng)初設(shè)立這個模塊一定是有想法有原因的从媚，要記錄下你的解決思路，不要到時候換個地方你又靈光一現(xiàn)啥的患整，引入了其他方案拜效，從而導(dǎo)致異構(gòu)。
要是一個框架里面解決同一種類似的問題有各種五花八門的方法或者類各谚，我覺得做這個架構(gòu)的架構(gòu)師一定是自己都沒想清楚就開始搞了紧憾。
沒有橫向依賴，萬不得已不出現(xiàn)跨層訪問
沒有橫向依賴是很重要的昌渤，這決定了你將來要對這個架構(gòu)做修補(bǔ)所需要的成本有多大赴穗。要做到?jīng)]有橫向依賴，這是很考驗(yàn)架構(gòu)師的模塊分類能力和是否熟悉業(yè)務(wù)的膀息。
跨層訪問是指數(shù)據(jù)流向了跟自己沒有對接關(guān)系的模塊般眉。有的時候跨層訪問是不可避免的，比如網(wǎng)絡(luò)底層里面信號從2G變成了3G變成了4G潜支，這是有可能需要跨層通知到View的煤篙。但這種情況不多，一旦出現(xiàn)就要想盡一切辦法在本層搞定或者交給上層或者下層搞定毁腿，盡量不要出現(xiàn)跨層的情況】撩跨層訪問同樣也會增加耦合度已烤，當(dāng)某一層需要整體替換的時候，牽涉面就會很大妓羊。
對業(yè)務(wù)方該限制的地方有限制胯究，該靈活的地方要給業(yè)務(wù)方創(chuàng)造靈活實(shí)現(xiàn)的條件
把這點(diǎn)做好，很依賴于架構(gòu)師的經(jīng)驗(yàn)躁绸。架構(gòu)師必須要有能力區(qū)分哪些情況需要限制靈活性裕循，哪些情況需要創(chuàng)造靈活性臣嚣。比如對于Core Data技術(shù)棧來說，ManagedObject理論上是可以出現(xiàn)在任何地方的剥哑，那就意味著任何地方都可以修改ManagedObject硅则，這就導(dǎo)致ManagedObjectContext在同步修改的時候把各種不同來源的修改同步進(jìn)去。這時候就需要限制靈活性株婴，只對外公開一個修改接口怎虫，不暴露任何ManagedObject在外面。
如果是設(shè)計(jì)一個ABTest相關(guān)的API的時候困介，我們又希望增加它的靈活性大审。使得業(yè)務(wù)方不光可以通過Target-Action的模式實(shí)現(xiàn)ABtest，也要可以通過Block的方式實(shí)現(xiàn)ABTest座哩，要盡可能滿足靈活性徒扶，減少業(yè)務(wù)方的使用成本。
易測試易拓展
老生常談根穷，要實(shí)現(xiàn)易測試易拓展姜骡，那就要提高模塊化程度，盡可能減少依賴關(guān)系缠诅，便于mock溶浴。另外，如果是高度模塊化的架構(gòu)管引，拓展起來將會是一件非常容易的事情士败。
保持一定量的超前性
這一點(diǎn)能看出架構(gòu)師是否關(guān)注行業(yè)動態(tài)，是否能準(zhǔn)確把握技術(shù)走向褥伴。保持適度的技術(shù)上的超前性谅将，能夠使得你的架構(gòu)更新變得相對輕松。
另外重慢，這里的超前性也不光是技術(shù)上的饥臂，還有產(chǎn)品上的。誰說架構(gòu)師就不需要跟產(chǎn)品經(jīng)理打交道了似踱，沒事多跟產(chǎn)品經(jīng)理聊聊天隅熙，聽聽他對產(chǎn)品未來走向的暢想，你就可以在合理的地方為他的暢想留一條路子核芽。同時囚戚，在創(chuàng)業(yè)公司的環(huán)境下，很多產(chǎn)品需求其實(shí)只是為了趕產(chǎn)品進(jìn)度而產(chǎn)生的妥協(xié)方案轧简，最后還是會轉(zhuǎn)到正軌的驰坊。這時候業(yè)務(wù)方可以不實(shí)現(xiàn)轉(zhuǎn)到正規(guī)的方案，但是架構(gòu)這邊哮独，是一定要為這種可預(yù)知的改變做準(zhǔn)備的拳芙。
接口少察藐，接口參數(shù)少
越少的接口越少的參數(shù)，就能越降低業(yè)務(wù)方的使用成本舟扎。當(dāng)然分飞，充要條件還是要滿足的，如何在滿足充要條件的情況下盡可能地減少接口和參數(shù)數(shù)量浆竭，這就能看出架構(gòu)師的功力有多深厚了浸须。
高性能
為什么高性能排在最后一位？
高性能非常重要邦泄，但是在客戶端架構(gòu)中删窒，它不是第一考慮因素。原因有下：
客戶端業(yè)務(wù)變化非常之快顺囊，做架構(gòu)時首要考慮因素應(yīng)當(dāng)是便于業(yè)務(wù)方快速滿足產(chǎn)品需求肌索，因此需要盡可能提供簡單易用效果好的接口給業(yè)務(wù)方，而不是提供高性能的接口給業(yè)務(wù)方特碳。
蘋果平臺的性能非常之棒诚亚，正常情況下很少會出現(xiàn)由于性能不夠?qū)е碌挠脩趔w驗(yàn)問題。
蘋果平臺的優(yōu)化手段相對有限午乓，甚至于有些時候即便動用了無所不用其極的手段乃至不擇手段犧牲了穩(wěn)定性站宗，性能提高很有可能也只不過是100ms到90ms的差距。10%的性能提升對于服務(wù)端來說很不錯了益愈，因?yàn)榉?wù)端動不動就是幾十萬上百萬的訪問量梢灭，幾十萬上百萬個10ms是很可觀的。但是對于客戶端的用戶來說蒸其，他無法感知這10ms的差別敏释，如果從10s優(yōu)化成9s用戶還是有一定感知的，但是100ms變90ms摸袁，我覺得吧钥顽，還是別折騰了。
但是靠汁！不重要不代表用不著去做蜂大，關(guān)于性能優(yōu)化的東西，我會對應(yīng)放到各系列文章里面去蝶怔。比如網(wǎng)絡(luò)層優(yōu)化县爬，那就會在網(wǎng)絡(luò)層方案的那篇文章里面去寫，對應(yīng)每層架構(gòu)都有每層架構(gòu)的不同優(yōu)化方案添谊，我都會在各自文章里面一一細(xì)說。
關(guān)于架構(gòu)分層察迟？
昨晚上朋友看了這篇文章之后說斩狱，看到你這個題目本來我是期望看到關(guān)于架構(gòu)分層相關(guān)的東西的耳高，但是你沒寫。
嗯所踊，確實(shí)沒寫泌枪，當(dāng)時沒寫的原因是感覺這個沒什么好寫的。前面談?wù)摰郊軜?gòu)的方法的時候秕岛，關(guān)于問題分類分模塊這一步時碌燕，架構(gòu)分層也屬于這一部分，給我一筆帶過了继薛。
既然朋友提出來了這個問題修壕，我想可能大家關(guān)于這個也會有一些想法和問題，那么我就在這兒講講吧遏考。
其實(shí)分層這種東西慈鸠，真沒啥技術(shù)含量，全憑架構(gòu)師的經(jīng)驗(yàn)和素質(zhì)灌具。
我們常見的分層架構(gòu)青团，有三層架構(gòu)的：展現(xiàn)層、業(yè)務(wù)層咖楣、數(shù)據(jù)層督笆。也有四層架構(gòu)的：展現(xiàn)層、業(yè)務(wù)層诱贿、網(wǎng)絡(luò)層娃肿、本地?cái)?shù)據(jù)層。這里說三層瘪松、四層咸作，跟TCP/IP所謂的五層或者七層不是同一種概念。再具體說就是：你這個架構(gòu)在邏輯上是幾層那就幾層宵睦，具體每一層叫什么记罚，做什么，沒有特定的規(guī)范壳嚎。這主要是針對模塊分類而言的桐智。
也有說MVC架構(gòu)，MVVM架構(gòu)的烟馅，這種層次劃分说庭，主要是針對數(shù)據(jù)流動的方向而言的。
在實(shí)際情況中郑趁，針對數(shù)據(jù)流動方向做的設(shè)計(jì)和針對模塊分類做的設(shè)計(jì)是會放在一起的刊驴，也就是說，一個MVC架構(gòu)可以是四層：展現(xiàn)層、業(yè)務(wù)層捆憎、網(wǎng)絡(luò)層舅柜、本地?cái)?shù)據(jù)層。
那么躲惰，為什么我要說這個致份？
大概在五六年前，業(yè)界很流行三層架構(gòu)這個術(shù)語础拨。然后各種文檔資料漫天的三層架構(gòu)氮块，并且喜歡把它與MVC放在一起說，MVC三層架構(gòu)/三層架構(gòu)MVC诡宗，以至于很多人就會認(rèn)為三層架構(gòu)就是MVC滔蝉，MVC就是三層架構(gòu)。其實(shí)不是的僚焦。三層架構(gòu)里面其實(shí)沒有Controller的概念锰提，而且三層架構(gòu)描述的側(cè)重點(diǎn)是模塊之間的邏輯關(guān)系。MVC有Controller的概念芳悲，它描述的側(cè)重點(diǎn)在于數(shù)據(jù)流動方向立肘。
好，為什么流行起來的是三層架構(gòu)名扛，而不是四層架構(gòu)或五層架構(gòu)谅年？
因?yàn)樗械哪K角色只會有三種：數(shù)據(jù)管理者、數(shù)據(jù)加工者肮韧、數(shù)據(jù)展示者融蹂，意思也就是，籠統(tǒng)說來弄企，軟件只會有三層超燃，每一層扮演一個角色。其他的第四層第五層拘领，一般都是這三層里面的其中之一分出來的意乓，最后都能歸納進(jìn)這三層的某一層中去，所以用三層架構(gòu)來描述就比較普遍约素。
那么我們怎么做分層届良？
應(yīng)該如何做分層，不是在做架構(gòu)的時候一開始就考慮的問題圣猎。雖然我們要按照自頂向下的設(shè)計(jì)方式來設(shè)計(jì)架構(gòu)士葫，但是一般情況下不適合直接從三層開始。一般都是先確定所有要解決的問題送悔，先確定都有哪些模塊慢显，然后再基于這些模塊再往下細(xì)化設(shè)計(jì)爪模。然后再把這些列出來的問題和模塊做好分類。分類之后不出意外大多數(shù)都是三層荚藻。如果發(fā)現(xiàn)某一層特別龐大呻右，那就可以再拆開來變成四層，變成五層鞋喇。
舉個例子：你要設(shè)計(jì)一個即時通訊的服務(wù)端架構(gòu)，怎么分層眉撵？
記住侦香，不要一上來就把三層架構(gòu)的規(guī)范套上去，這樣做是做不出好架構(gòu)的纽疟。
你要先確定都需要解決哪些問題罐韩。這里只是舉例子，我隨意列出一點(diǎn)意思意思就好了：
要解決用戶登錄污朽、退出的問題
解決不同用戶間數(shù)據(jù)交流的問題
解決用戶數(shù)據(jù)存儲的問題
如果是多臺服務(wù)器的集群散吵，就要解決用戶連接的尋址問題
解決第一個問題需要一個鏈接管理模塊，鏈接管理模塊一般是通過鏈接池來實(shí)現(xiàn)蟆肆。 解決第二個問題需要有一個數(shù)據(jù)交換模塊矾睦，從A接收來的數(shù)據(jù)要給到B，這個事情由這個模塊來做炎功。 解決第三個問題需要有個數(shù)據(jù)庫枚冗，如果是服務(wù)于大量用戶，那么就需要一個緩沖區(qū)蛇损，只有當(dāng)需要存儲的數(shù)據(jù)達(dá)到一定量時才執(zhí)行寫操作赁温。 解決第四個問題可以有幾種解決方案，一個是集群中有那么幾臺服務(wù)器作為尋路服務(wù)器淤齐，所有尋路的服務(wù)交給那幾臺去做股囊，那么你需要開發(fā)一個尋路服務(wù)的Daemon「模或者用廣播方式尋路稚疹，但如果尋路頻次非常高誉简，會造成集群內(nèi)部網(wǎng)絡(luò)負(fù)載特別大歹茶。這是你要權(quán)衡的地方，目前流行的思路是去中心化死陆，那么要解決網(wǎng)絡(luò)負(fù)載的問題待牵，你就可以考慮配置一個緩存其屏。
于是我們有了這些模塊：
鏈接管理、數(shù)據(jù)交換缨该、數(shù)據(jù)庫及其配套模塊偎行、尋路模塊
做到這里還遠(yuǎn)遠(yuǎn)沒有結(jié)束，你要繼續(xù)針對這四個模塊繼續(xù)往下細(xì)分，直到足夠小為止蛤袒。但是這里只是舉例子熄云，所以就不往下深究了。
另外妙真，我要提醒你的是缴允，直到這時，還是跟幾層架構(gòu)毫無關(guān)系的珍德。當(dāng)你把所有模塊都找出來之后练般，就要開始整理你的這些模塊，很有可能架構(gòu)圖就是這樣：
然后這些模塊分完之后你看一下圖锈候，嗯薄料，1、2泵琳、3摄职，一共三層，所以那就是三層架構(gòu)啦获列。在這里最消耗腦力最考驗(yàn)架構(gòu)師功力的地方就在于：找到所有需要的模塊, 把模塊放在該放的地方
這個例子側(cè)重點(diǎn)在于如何分層谷市，性能優(yōu)化、數(shù)據(jù)交互規(guī)范和包協(xié)議蛛倦、數(shù)據(jù)采集等其他一系列必要的東西都沒有放進(jìn)去歌懒，但看到這里，相信你應(yīng)該了解架構(gòu)師是怎么對待分層問題的了吧溯壶？
對的及皂，答案就是沒有分層。所謂的分層都是出架構(gòu)圖之后的事情了且改。所以你看別的架構(gòu)師在演講的時候验烧，上來第一句話差不多都是："這個架構(gòu)分為以下幾層..."。但考慮分層的問題的時機(jī)絕對不是一開始就考慮的又跛。另外碍拆，模塊一定要把它設(shè)計(jì)得獨(dú)立性強(qiáng)，這其實(shí)是門藝術(shù)活慨蓝。
另外感混，這雖然是服務(wù)端架構(gòu)，但是思路跟客戶端架構(gòu)是一樣的礼烈，側(cè)重點(diǎn)不同罷了弧满。之所以不拿客戶端架構(gòu)舉例子，是因?yàn)檫@方面的客戶端架構(gòu)蘋果已經(jīng)幫你做好了絕大部分事情此熬，沒剩下什么值得說的了庭呜。
關(guān)于Common文件夾滑进？
在原文的評論區(qū)MatrixHero提到一點(diǎn)：
關(guān)于common文件夾的問題，僅僅是文件夾而已募谎，別無他意扶关。如果后期維護(hù)出了代碼混亂可能是因?yàn)椋头?wù)器溝通協(xié)議不統(tǒng)一数冬，或代碼review不及時节槐。應(yīng)該有專人維護(hù)公共類。
這是針對我前面提出的不要Common拐纱，不要Core而言的疯淫，為什么我建議大家不要開Common文件夾？我打算分幾種情況給大家解釋一下戳玫。
一般情況下，我們都會有一些屬于這個項(xiàng)目的公共類未斑，比如取定位坐標(biāo)咕宿，比如圖像處理。這些模塊可能非常小蜡秽，就h和m兩個文件府阀。單獨(dú)拎出來成為一個模塊感覺不夠格，但是又不屬于其他任何一個模塊芽突。于是大家很有可能就會把它們放入Common里面试浙，我目前見到的大多數(shù)工程和大多數(shù)文檔里面的代碼都喜歡這么做。在當(dāng)時來看寞蚌，這么做看不出什么問題田巴，但關(guān)鍵在于：軟件是有生命，會成長的挟秤。當(dāng)時分出來的小模塊壹哺，很有可能會隨著業(yè)務(wù)的成長，逐漸發(fā)展成大模塊艘刚，發(fā)展成大模塊后管宵，可以再把它從Common移出來單獨(dú)成立一個模塊。這個在理論上是沒有任何問題的攀甚，然而在實(shí)際操作過程中箩朴，工程師在拓張這個小模塊的時候，不太容易會去考慮橫向依賴的問題秋度，因?yàn)楫?dāng)時這些模塊都在Common里面炸庞，直接進(jìn)行互相依賴是非常符合直覺的，而且也不算是不遵守規(guī)范静陈。然而要注意的是燕雁，這才是Commom代碼混亂的罪魁禍?zhǔn)椎觯珻ommon文件夾縱容了不精心管理依賴的做法。當(dāng)Common里面的模塊依賴關(guān)系變得復(fù)雜拐格，再想要移出來單獨(dú)成立一個模塊僧免，就不是當(dāng)初設(shè)置Common時想的等規(guī)模大了再移除也不遲那么簡單了。
另外捏浊，Common有的時候也不僅僅是一個文件夾懂衩。
在使用Cocoapods來管理項(xiàng)目庫的時候，Common往往就是一個pod金踪。這個pod里面會有A/B/C/D/E這些函數(shù)集或小模塊浊洞。如果要新開一個app或者Demo，勢必會使用到Common這個pod胡岔，這么做法希，往往會把不需要包含的代碼也包含進(jìn)去，我對項(xiàng)目有高度潔癖靶瘸，這種情況會讓我覺得非常不舒服苫亦。
舉個例子：早年安居客的app還不是集齊所有新房、二手房怨咪、租房業(yè)務(wù)的屋剑。當(dāng)你剛開始寫新房這個app的時候，創(chuàng)建了一個Common這個pod诗眨，這里面包含了一些對于新房來說比較Common的代碼唉匾，也包含了對于這個app來說比較Common的代碼。過了半年或者一年匠楚，你要開始二手房這個app巍膘，我覺得大多數(shù)人都會選擇讓二手房也包含這個Common，于是這個Common很有可能自己走上另一條發(fā)展的道路芋簿。等到了租房這個業(yè)務(wù)要開app的時候典徘，Common已經(jīng)非常之龐大，相信這時候的你也不會去想整理Common的事情了益咬，先把租房搞定逮诲，于是Common最終就變成了一坨屎。
就對于上面的例子來說幽告，還有一個要考慮的是梅鹦，分出來的三個業(yè)務(wù)很有可能會有三個Common，假設(shè)三個Common里面都有公共的功能冗锁，交給了三個團(tuán)隊(duì)去打理齐唆，如果遇到某個子模塊需要升級，那么三個Common里面的這個子模塊都要去同步升級冻河，這是個很不效率的事情箍邮。另外茉帅，很有可能三個Common到最后發(fā)展成彼此不兼容，但是代碼相似度非常之高锭弊，這個在架構(gòu)上堪澎，是屬于分類條理不清。
就在去年年中的時候味滞，安居客決定將三個業(yè)務(wù)歸并到同一個App樱蛤。好了，如果你是架構(gòu)師剑鞍，面對這三個Common昨凡，你打算怎么辦？要想最快出成果蚁署，那就只好忍受代碼冗余便脊，趕緊先把架子搭起來再說，否則你面對的就是剪不斷理還亂的Common光戈。此時Common就已經(jīng)很無奈地變成一坨屎了就轧。這樣的Common，你自己說不定也搞不清楚它里面到底都有些什么了田度，交給任何一個人去打理，他都不敢做徹底的整理的解愤。
還有就是镇饺，Common本身就是一個粒度非常大的模塊。在阿里這樣大規(guī)模的團(tuán)隊(duì)中送讲，即便新開一個業(yè)務(wù)奸笤，都需要在整個app的環(huán)境下開發(fā)，為什么哼鬓？因?yàn)槟K拆分粒度不夠监右，要想開一個新業(yè)務(wù)，必須把其他業(yè)務(wù)的代碼以及依賴全部拉下來异希，然后再開新入口健盒，你的新業(yè)務(wù)才能進(jìn)行正常的代碼編寫和調(diào)試。然而你的新業(yè)務(wù)其實(shí)只依賴首頁入口称簿、網(wǎng)絡(luò)庫等這幾個小模塊扣癣，不需要依賴其他那么多的跟你沒關(guān)系的業(yè)務(wù)。現(xiàn)在每次打開天貓的項(xiàng)目憨降，我都要等個兩三分鐘父虑，這非常之蛋疼。
但是大家真的不知道這個原因嗎授药？知道了這個原因士嚎，為什么沒人去把這些粒度不夠細(xì)的模塊整理好呜魄？在我看來，這件事沒人敢做莱衩。原因有以下幾點(diǎn)：
原來大家用的好好的爵嗅，手段爛就爛一點(diǎn)，你改了你能保證不出錯膳殷？
這么復(fù)雜的東西操骡，短期之內(nèi)你肯定搞不好，任務(wù)量和工時都不好估赚窃，你leader會覺得你在騙工時玩自己的事情册招。
就算你搞定了，QA這邊肯定再需要做一次全面的回歸測試勒极，任務(wù)量極大是掰，難以說服他們配合你的工作。
花這么大的成本只是為了減少開啟項(xiàng)目時候等待IDE打開時的那幾分鐘時間辱匿？我想如果我是你leader键痛，我也應(yīng)該不會批準(zhǔn)你做這樣的事情的。所以匾七，與其到了后面吃這個苦頭絮短，不如一開始做架構(gòu)的時候就不要設(shè)置Common，到后面就能省力很多昨忆。架構(gòu)師的工作為什么是功在當(dāng)代利在千秋丁频，架構(gòu)師的素質(zhì)為什么對團(tuán)隊(duì)這么重要？我覺得這里就是一個最好的體現(xiàn)邑贴。
簡而言之席里，不建議開Common的原因如下：
Common不僅僅是一個文件夾，它也會是一個Pod拢驾。不管是什么奖磁，在Common里面很容易形成錯綜復(fù)雜的小模塊依賴，在模塊成長過程中繁疤，會縱容工程師不注意依賴的管理咖为，乃至于將來如果要將模塊拆分出去，會非常的困難稠腊。
Common本身與細(xì)粒度模塊設(shè)計(jì)的思想背道而馳案疲，屬于一種不合適的偷懶手段，在將來業(yè)務(wù)拓張會成為阻礙麻养。
一旦設(shè)置了Common褐啡，就等于給地獄之門打開了一個小縫，每次業(yè)務(wù)迭代都會有一些不太好分類的東西放入Common鳖昌，這就給維護(hù)Common的人帶來了非常大的工作量备畦，而且這些工作量全都是體力活低飒，非常容易出錯。
那么懂盐，不設(shè)Common會帶來哪些好處褥赊？
強(qiáng)迫工程師在業(yè)務(wù)拓張的時候?qū)⒁蕾嚬芾淼氖虑榭紤]進(jìn)去，讓模塊在一開始發(fā)展的時候就有自己的土壤莉恼，成長空間和靈活度非常大拌喉。
減少各業(yè)務(wù)模塊或者Demo的體積，不需要的模塊不會由于Common的存在而包含在內(nèi)俐银。
可維護(hù)性大大提高尿背，模塊升級之后要做的同步工作非常輕松，解放了那個苦逼的Common維護(hù)者捶惜，更多的時間可以用在更實(shí)質(zhì)的開發(fā)工作上田藐。
符合細(xì)粒度模塊劃分的架構(gòu)思想。
Common的好處只有一個吱七，就是前期特別省事兒汽久。然而它的壞處比好處要多太多。不設(shè)置Common踊餐，再小的模塊再小的代碼也單獨(dú)拎出來景醇，最多就是Podfile里面要多寫幾行，多寫幾行最多只花費(fèi)幾分鐘吝岭。但若要消除Common所帶來的罪孽三痰，不是這幾分鐘就能搞定的事情。既然不用Common的好處這么多苍碟，那何樂而不為呢？
假設(shè)將來你的項(xiàng)目中有一個類是用來做Location的撮执，哪怕只有兩個文件微峰，也給他開一個模塊就叫Location。如果你的項(xiàng)目中有一個類是用來做ImageProcess的抒钱，那也開一個模塊就叫ImageProcess蜓肆。不要都放到Common里面去，將來你再開新的項(xiàng)目或者新的業(yè)務(wù)谋币，用Location就寫依賴Location仗扬，用ImageProcess就寫依賴ImageProcess，不要再依賴Common了蕾额，這樣你的項(xiàng)目也好管理早芭，管理Common的那個人日子過得也輕松（這個人其實(shí)都可以不需要了，把他的工資加到你頭上不是更好诅蝶？:D）退个，將來要升級募壕，顧慮也少。
結(jié)束
本篇的內(nèi)容就到這里语盈，希望能對大家有所幫助舱馅。干貨會在后續(xù)的系列文章里面撲面而來的！
編后語
為了更好地向讀者輸出更優(yōu)質(zhì)的內(nèi)容刀荒，InfoQ將精選來自國內(nèi)外的優(yōu)秀文章代嗤，經(jīng)過整理審校后，發(fā)布到網(wǎng)站缠借。本篇文章作者為田偉宇干毅，原文鏈接為Casa Taloyum。本文已由原作者授權(quán)InfoQ中文站轉(zhuǎn)載烈炭。
