架構(gòu)的定義

過去6年多幾乎絕大部分時間都浸淫在iOS平臺，翻閱過不少關(guān)于架構(gòu)的文章,，發(fā)現(xiàn)眾人對架構(gòu)的理解頗有些差異,，總體來說可分為四類：

第一類：精簡型應(yīng)用架構(gòu)

這類架構(gòu)的文章分析主要還是圍繞MVC展開，以蘋果自帶UIViewController優(yōu)劣為出發(fā)點(diǎn),，再結(jié)合主流的MVP,，MVVM，MVCS等變種進(jìn)行分析演變,。這類的探討重點(diǎn)在于M,，V，C三類角色的定義以及之間的數(shù)據(jù)事件流向的規(guī)范,。很多小型應(yīng)用所面臨的問題及其架構(gòu)層面的解決方案都集中在這一類,。

第二類：綜合型應(yīng)用架構(gòu)

對于用戶量級在千萬級或以上的應(yīng)用來說，MVC這一層面的思考已無法應(yīng)對業(yè)務(wù)瘋狂增長所帶來的負(fù)擔(dān),。這類應(yīng)用往往需要專業(yè)資深的架構(gòu)師出面進(jìn)行深層次的思考設(shè)計(jì),，業(yè)內(nèi)不少大廠如淘寶，天貓,，攜程等都做過一些分享,。不過到了這一層級的戰(zhàn)斗,，不光考驗(yàn)架構(gòu)師的技術(shù)積累，更重要的是架構(gòu)師對于業(yè)務(wù)的整體理解,。我姑且把這類架構(gòu)名之為：綜合型應(yīng)用架構(gòu),。綜合型應(yīng)用架構(gòu)一般不會提到MVC，更多是在探討“層”與“模塊”的劃分和耦合,。后面我會就幾個經(jīng)典樣本做下詳盡深入的分析,。

第三類：深度優(yōu)化的綜合型應(yīng)用架構(gòu)

綜合型應(yīng)用架構(gòu)是應(yīng)對大規(guī)模業(yè)務(wù)增長的必經(jīng)之路，一旦架構(gòu)成型,，后期業(yè)務(wù)膨脹會不停的打磨架構(gòu)本身,，產(chǎn)品本身對體驗(yàn)質(zhì)量的追求會要求架構(gòu)師和技術(shù)團(tuán)隊(duì)不停的優(yōu)化架構(gòu)細(xì)節(jié)。這種優(yōu)化可以分為兩塊,，第一是組件或模塊劃分的粒度越來越細(xì),，第二是組件模塊的深度優(yōu)化，比如網(wǎng)絡(luò)層的深度優(yōu)化,，sqlite優(yōu)化（多線程,，F(xiàn)TS，安全等）,，數(shù)據(jù)加密,，HotFix，Hybrid等,，一些開源的第三方庫已不能滿足要求,，需要團(tuán)隊(duì)自己重造輪子。這一層面的架構(gòu)設(shè)計(jì)涉及面廣,，對架構(gòu)師,，團(tuán)隊(duì)技術(shù)人員的技術(shù)深度和業(yè)務(wù)理解能力有較高要求，短短一篇技術(shù)文章往往只能走馬觀花的介紹個大概,，每一次優(yōu)化幾乎都可以作為一個專題來講解,。

第四類：組織型應(yīng)用架構(gòu)

這類架構(gòu)在第三類的基礎(chǔ)之上更進(jìn)了一步，除了關(guān)注系統(tǒng)層面的架構(gòu)設(shè)計(jì)之外,，更對團(tuán)隊(duì)或部門之間協(xié)作方式,，各系統(tǒng)模塊的演進(jìn)方式，產(chǎn)品發(fā)布流程等都做了規(guī)范,。除去業(yè)務(wù)膨脹帶來的壓力,，人員增長，各團(tuán)隊(duì)協(xié)作依賴增強(qiáng)等都會對app的質(zhì)量,，迭代速度產(chǎn)生影響,，這些問題也需要從架構(gòu)層面去解決。這類結(jié)合技術(shù)架構(gòu)和組織架構(gòu)的分享還比較少。

以上四種類型的架構(gòu)又可以看做一般App從簡至繁,，公司規(guī)模隨之增長的演進(jìn)過程,，技術(shù)圈絕大部分的架構(gòu)類分享文章都可以歸為上述四類。

對于什么是架構(gòu)的學(xué)術(shù)定義,，似乎大家并不太在意,，更關(guān)心的是如何解決自身項(xiàng)目當(dāng)下的問題。雖然在我看來第一類架構(gòu)更像是在討論設(shè)計(jì)模式,，但這里面確實(shí)又有非常多的知識可以深入挖掘,，這里就把所有“解決應(yīng)用整體設(shè)計(jì)問題”的討論都?xì)w類于架構(gòu)這一話題。

值得一提的是,，架構(gòu)師的視野和積累一般都受限于自己所經(jīng)歷項(xiàng)目及業(yè)務(wù)的規(guī)模,。如果有機(jī)會，工程師還是應(yīng)該盡可能去BAT這類巨頭級公司歷練一下,，知識深度和廣度的構(gòu)建絕非紙上可得,。

樣本分析

這里我以圈子里幾個經(jīng)典的架構(gòu)分享為樣本，做下解剖分析,。樣本的選取主要以搜索引擎及評論熱度為標(biāo)準(zhǔn),，排名不分先后。

第一類樣本：

如果一篇架構(gòu)的文章是以探討MVC為起點(diǎn),，很有可能作者所說的架構(gòu)就可以被歸為第一類樣本,。

Xcode自帶的UIViewController模板經(jīng)常被戲稱為“Massive View Controller”，主要是因?yàn)閁IViewController除了負(fù)責(zé)Controller生命周期回調(diào)之外,，還承擔(dān)了View和Controller的工作。不少架構(gòu)的探討以此為基礎(chǔ),，將Controller的M,，V，C三個角色重新進(jìn)行劃分,，又或者衍生出MVP,，MVVM，MVCS,，VIPER等其他組織方式,。重新定義MVC之后，網(wǎng)絡(luò)訪問,，持久化,，安全等通用功能模塊往往就由Controller或者Presenter負(fù)責(zé)了，這些負(fù)責(zé)業(yè)務(wù)邏輯的功能類直接依賴于成熟穩(wěn)定的第三方基礎(chǔ)庫,，比如AFNetworking,，F(xiàn)MDB等。

但是，應(yīng)付過復(fù)雜龐大業(yè)務(wù)模塊的工程師會會有經(jīng)驗(yàn),，無論以何種方式組織Controller,，數(shù)據(jù)流向和事件傳遞再清晰合理，單純代碼量的膨脹就足以讓Controller變得難以維護(hù),。MVC,，MVP，MVVM都可以變得Massive,。想象一下將10本書放在床頭,，你可以按翻閱頻次，閱讀習(xí)慣將書合理擺放,，但當(dāng)你面對100本書的時候,，已不是如何擺放的問題，而是需要一個新的書柜,。說到這里我挺服VIPER的,，五個角色劃分，嘗試可以在床頭放下100本書的Pattern,。我們先來看看“10本書”的樣本,。

樣本名：iOS 架構(gòu)模式–解密 MVC，MVP,，MVVM以及VIPER架構(gòu)

英文原版,，中文翻譯版iOS 架構(gòu)模式--解密 MVC，MVP,，MVVM以及VIPER架構(gòu)

作者：Bohdan Orlov

這篇文章是第一類樣本的典型,，綜合對比了MV（X）系列架構(gòu)。我們來看下主要論點(diǎn),。

論點(diǎn)摘要：

文章認(rèn)為優(yōu)秀的架構(gòu)具備以下三個特質(zhì)：

Balanced distribution of responsibilities among entities with strict roles.

能把代碼職責(zé)均衡的劃分到不同的功能類里,。

這是我們關(guān)注架構(gòu)的原動力，有個粗淺的評判標(biāo)準(zhǔn),，同一個業(yè)務(wù)單位（Controller）里面,，不能一個類1000多行代碼，另一個類卻只有10來行,。當(dāng)我們考慮網(wǎng)絡(luò)請求的代碼是該放在controller當(dāng)中還是model當(dāng)中的時候,，在“代碼量”上要做到“雨露均沾”，不能少數(shù)類“營養(yǎng)不良”,。所以不論你的MVC,，MVP或者VIPER是如何劃分職責(zé)的，各個角色所承擔(dān)的職責(zé)應(yīng)當(dāng)看起來是均勻分配的,。

Testability usually comes from the first feature.

方便測試

測試是個有趣的話題,，不同公司實(shí)踐差異很大,。我知道有些團(tuán)隊(duì)的產(chǎn)品質(zhì)量嚴(yán)重依賴于QA團(tuán)隊(duì)，有些卻干脆沒有測試團(tuán)隊(duì),，完全依賴于開發(fā)人員自己保證質(zhì)量,，這兩種風(fēng)格一般取決于CTO的技術(shù)決策，和公司大小倒沒多少關(guān)系,。對于開發(fā)人員自測的情況,，如果代碼架構(gòu)清晰，各角色職責(zé)分配合理,，易測性是隨之而來的副產(chǎn)品,。

Ease of use and a low maintenance cost

易用且方便維護(hù)

易用是針對團(tuán)隊(duì)里的開發(fā)人員而言的。其實(shí)到底是用MVP還是MVVM,，或者M(jìn)VVM里數(shù)據(jù)如何流動,，這些具體的規(guī)范到底采用何種形態(tài)不是最重要的問題，關(guān)鍵是在團(tuán)隊(duì)所有成員能有一致的認(rèn)識,，無論是寫代碼還是Debug都能快速切入,。

圍繞上面三個特質(zhì)，作者一一分析對比了傳統(tǒng)MVC,，Apple MVC,，MVP，MVVM,，VIPER在這三方面的表現(xiàn),，結(jié)論是到底選用哪個純粹是個人口味問題。相較于結(jié)論,，作者對各個Pattern的角色定義及分析才是真正有價值的部分,，我們在閱讀評斷其他類似架構(gòu)文章的時候，也應(yīng)該重在了解作者對于角色的理解,。大家可以基于這一點(diǎn),，閱讀下其他一些類似的文章。VIPER理論上并不能歸類于MV（X）系列,，而是突破了MVC的思考方式，比如定義了Router處理頁面流程,，這對架構(gòu)師是個很好的思路,，在對MV（X）重新設(shè)計(jì)的時候也應(yīng)該能有新的思考，所謂“君子不器”,。

MV（X）都是以MVC為原型進(jìn)行變化,，MV（X）到底如何使用沒有教科書式的標(biāo)準(zhǔn)答案，關(guān)鍵在于架構(gòu)師和團(tuán)隊(duì)各成員能達(dá)成一致的認(rèn)識,，在遇到問題時能不斷的做調(diào)整重構(gòu),，遇到難以跨越的瓶頸時，能跳出MV（X）尋找解決方案。

第二類樣本：

在開始分析第二類樣本之前,，有幾個概念比較重要,，是我們深入討論各個綜合型樣本的前提。組件,，模塊,，層的定義。

在我看來,，組件是比模塊更小的功能單位,，不具備業(yè)務(wù)屬性，只處理基礎(chǔ)通用的問題,，類似于工具箱,。比如我們給NSString寫的Category提供base64，給NSDate寫的Category做日期格式化等等,。

模塊較之組件粒度更大一些,，另外最重要的區(qū)別是帶有業(yè)務(wù)屬性，和業(yè)務(wù)場景相關(guān)聯(lián),。比如購物車模塊,，注冊登錄模塊，支付模塊等等,，模塊往往會對一些通用的組件產(chǎn)生依賴,。

層是另一個維度的概念了，我平常閱讀技術(shù)文章的時候,，發(fā)現(xiàn)很多人會把模塊和層的概念混淆,，可以用一張圖來區(qū)分模塊與層的概念：

對于層不允許跨層訪問，也就是說A不能直接訪問C,，下層不允許訪問上層,，B無法知道A的實(shí)現(xiàn)細(xì)節(jié)。層的概念可類比TCP/IP協(xié)議棧,。模塊就靈活多了,，A，B,，C三者之間可以任意訪問依賴,。所以一般來說層對架構(gòu)的約束更高，但使得依賴更規(guī)范好維護(hù),，模塊在復(fù)雜的場景下很容易結(jié)成一個網(wǎng)狀的依賴形態(tài),，難以維護(hù)。第二類項(xiàng)目架構(gòu)都是圍繞層與模塊的劃分所展開,，有的有嚴(yán)格的層次結(jié)構(gòu),，有的不分層次,，通過接口嚴(yán)格規(guī)范各模塊交互，有的二者結(jié)合,，在某一層內(nèi)再做模塊劃分,，下面我們分析的樣本都屬于上面三種情形。

在開始分析之前,，建議大家全篇了解下iOS開發(fā)圈關(guān)于組件化的討論,，我之前做過一個總結(jié)，里面有各篇文章鏈接：http:///blog/module/ ,。

樣本名：餓了么移動APP的架構(gòu)演進(jìn)

原文地址

作者：圣迪

這篇架構(gòu)演進(jìn)的講解是典型的從第一類到第二類的過渡,，可簡化為以下幾步：

1.使用傳統(tǒng)MVC快速迭代App。

2.業(yè)務(wù)發(fā)展,，有多個App需要開發(fā),，開始組件化，使用CocoaPods進(jìn)行組件管理,，目標(biāo)是并行開發(fā)和代碼重用,。架構(gòu)圖如下：

如果讀過上面關(guān)于組件化的文章，這張架構(gòu)圖就很好理解了,，在做好模塊劃分和管理之后,，通過Router的方式將讓各模塊產(chǎn)生耦合。這種架構(gòu)方式已初步具備一個應(yīng)付大規(guī)模業(yè)務(wù)增長的架構(gòu)模型,。

3.Hybrid,，幾乎所有運(yùn)營類主導(dǎo)的App都會最終投入Hybrid的懷抱，運(yùn)營團(tuán)隊(duì)對快速上線的要求只能在H5或者Hybrid上得以實(shí)現(xiàn),，不過這和架構(gòu)本身關(guān)系不太大，是另一個大的話題,。

4.React-Native & Hot Patch,，這和第三步類似都是由運(yùn)營驅(qū)動，幾乎是所有內(nèi)容運(yùn)營型app的必經(jīng)之路,。

這四步的演化文章介紹的還比較粗略,，更多的細(xì)節(jié)（比如Router內(nèi)部實(shí)現(xiàn)，業(yè)務(wù)組件和非業(yè)務(wù)組件的分工,，組件間耦合的方式等）沒有介紹,，或者餓了么App端也還在探索當(dāng)中。

第三類樣本：

樣本名：攜程移動APP架構(gòu)優(yōu)化之旅

原文地址

作者：陳浩然

攜程App端的架構(gòu)演化在餓了么架構(gòu)基礎(chǔ)之上,，多了很多優(yōu)化的細(xì)節(jié),。

提到了對于基礎(chǔ)SDK組件和業(yè)務(wù)組件的具體劃分：

核心功能SDK化

• 通訊,、定位,、Hybrid,、數(shù)據(jù)庫、登錄,、分享,、基礎(chǔ)庫等

• 直接提供給其他BU獨(dú)立App使用

公用業(yè)務(wù)功能組件化

• 地圖、日歷,、城市,、圖片、通訊錄等13個公共組件

• 減少各BU重復(fù)開發(fā)工作量

性能數(shù)據(jù)指標(biāo)采集：

• 網(wǎng)絡(luò)性能:網(wǎng)絡(luò)服務(wù)成功率,、平均耗時,、耗時分布

• 定位:獲取經(jīng)緯度成功率、城市定位成功率

• 啟動時間,、內(nèi)存,、流量等指標(biāo)

• 多種緯度:系統(tǒng)、App版本,、網(wǎng)絡(luò)狀況,、位置等

網(wǎng)絡(luò)優(yōu)化

• 使用TCP長連接實(shí)現(xiàn)網(wǎng)絡(luò)服務(wù)

• 根據(jù)網(wǎng)絡(luò)狀況2G/3G/4G/WIFI進(jìn)行調(diào)優(yōu)參數(shù)

• 根據(jù)連接/讀/寫不同階段使用重試機(jī)制

• 使用IP列表避免DNS解析失敗或者劫持

• 根據(jù)網(wǎng)絡(luò)延遲選擇服務(wù)端IP(使用Ping)

• 使用ProtocolBuffer+Gzip減少Payload

還有Hybrid，HotFix,，React Native等就不一一列舉了,，這些細(xì)節(jié)性強(qiáng)的分享有很高的學(xué)習(xí)價值，能對剛涉足某一塊優(yōu)化的架構(gòu)師起到方向指引的作用,。

這些看似簡單的劃分往往很考驗(yàn)架構(gòu)師的大局觀和經(jīng)驗(yàn),，涵蓋面和合理的粒度掌控才能讓技術(shù)團(tuán)隊(duì)的開發(fā)工作高效并行。

第四類樣本：

樣本名：Facebook iOS Architecture

視頻地址