iOS應用架構現狀分析

iOS從2007年誕生至今已有近10年的歷史，10年的時間對iOS技術圈來講足夠產生至關可觀的沉澱，尤爲這幾年的技術分享氛圍不管國內國外都顯得異常活躍。本文就iOS架構這一主題，結合開發圈裏討論較多的幾種主流方式，再配以博主本身的理解，作下現狀分析。給本身作下知識梳理的同時，也指望能引入新的思考。

架構的定義

過去6年多幾乎絕大部分時間都浸淫在iOS平臺，翻閱過很多關於架構的文章，發現衆人對架構的理解很有些差別，整體來講可分爲四類：

第一類：精簡型應用架構

這類架構的文章分析主要仍是圍繞MVC展開，以蘋果自帶UIViewController優劣爲出發點，再結合主流的MVP，MVVM，MVCS等變種進行分析演變。這類的探討重點在於M，V，C三類角色的定義以及之間的數據事件流向的規範。不少小型應用所面臨的問題及其架構層面的解決方案都集中在這一類。

第二類：綜合型應用架構

對於用戶量級在千萬級或以上的應用來講，MVC這一層面的思考已沒法應對業務瘋狂增加所帶來的負擔。這類應用每每須要專業資深的架構師出面進行深層次的思考設計，業內很多大廠如淘寶，天貓，攜程等都作過一些分享。不過到了這一層級的戰鬥，不光考驗架構師的技術積累，更重要的是架構師對於業務的總體理解。我姑且把這類架構名之爲：綜合型應用架構。綜合型應用架構通常不會提到MVC，更可能是在探討「層」與「模塊」的劃分和耦合。後面我會就幾個經典樣本作下詳盡深刻的分析。

第三類：深度優化的綜合型應用架構

綜合型應用架構是應對大規模業務增加的必經之路，一旦架構成型，後期業務膨脹會不停的打磨架構自己，產品自己對體驗質量的追求會要求架構師和技術團隊不停的優化架構細節。這種優化能夠分爲兩塊，第一是組件或模塊劃分的粒度愈來愈細，第二是組件模塊的深度優化，好比網絡層的深度優化，sqlite優化（多線程，FTS，安全等），數據加密，HotFix，Hybrid等，一些開源的第三方庫已不能知足要求，須要團隊本身重造輪子。這一層面的架構設計涉及面廣，對架構師，團隊技術人員的技術深度和業務理解能力有較高要求，短短一篇技術文章每每只能蜻蜓點水的介紹個大概，每一次優化幾乎均可以做爲一個專題來說解。

第四類：組織型應用架構

這類架構在第三類的基礎之上更進了一步，除了關注系統層面的架構設計以外，更對團隊或部門之間協做方式，各系統模塊的演進方式，產品發佈流程等都作了規範。除去業務膨脹帶來的壓力，人員增加，各團隊協做依賴加強等都會對app的質量，迭代速度產生影響，這些問題也須要從架構層面去解決。這類結合技術架構和組織架構的分享還比較少。

以上四種類型的架構又能夠看作通常App從簡至繁，公司規模隨之增加的演進過程，技術圈絕大部分的架構類分享文章均可以歸爲上述四類。

對於什麼是架構的學術定義，彷佛你們並不太在乎，更關心的是如何解決自身項目當下的問題。雖然在我看來第一類架構更像是在討論設計模式，但這裏面確實又有很是多的知識能夠深刻挖掘，這裏就把全部「解決應用總體設計問題」的討論都歸類於架構這一話題。

值得一提的是，架構師的視野和積累通常都受限於本身所經歷項目及業務的規模。若是有機會，工程師仍是應該儘量去BAT這類巨頭級公司歷練一下，知識深度和廣度的構建絕非紙上可得。

樣本分析

這裏我以圈子裏幾個經典的架構分享爲樣本，作下解剖分析。樣本的選取主要以搜索引擎及評論熱度爲標準，排名不分前後。

第一類樣本：

若是一篇架構的文章是以探討MVC爲起點，頗有可能做者所說的架構就能夠被歸爲第一類樣本。

Xcode自帶的UIViewController模板常常被戲稱爲「Massive View Controller」，主要是由於UIViewController除了負責Controller生命週期回調以外，還承擔了View和Controller的工做。很多架構的探討以此爲基礎，將Controller的M，V，C三個角色從新進行劃分，又或者衍生出MVP，MVVM，MVCS，VIPER等其餘組織方式。從新定義MVC以後，網絡訪問，持久化，安全等通用功能模塊每每就由Controller或者Presenter負責了，這些負責業務邏輯的功能類直接依賴於成熟穩定的第三方基礎庫，好比AFNetworking，FMDB等。

可是，應付過複雜龐大業務模塊的工程師會會有經驗，不管以何種方式組織Controller，數據流向和事件傳遞再清晰合理，單純代碼量的膨脹就足以讓Controller變得難以維護。MVC，MVP，MVVM均可以變得Massive。想象一下將10本書放在牀頭，你能夠按翻閱頻次，閱讀習慣將書合理擺放，但當你面對100本書的時候，已不是如何擺放的問題，而是須要一個新的書櫃。說到這裏我挺服VIPER的，五個角色劃分，嘗試能夠在牀頭放下100本書的Pattern。咱們先來看看「10本書」的樣本。

樣本名：iOS 架構模式–解密 MVC，MVP，MVVM以及VIPER架構

英文原版，中文翻譯版

做者：Bohdan Orlov

這篇文章是第一類樣本的典型，綜合對比了MV（X）系列架構。咱們來看下主要論點。

論點摘要：

文章認爲優秀的架構具有如下三個特質：

Balanced distribution of responsibilities among entities with strict roles.

能把代碼職責均衡的劃分到不一樣的功能類裏。

這是咱們關注架構的原動力，有個粗淺的評判標準，同一個業務單位（Controller）裏面，不能一個類1000多行代碼，另外一個類卻只有10來行。當咱們考慮網絡請求的代碼是該放在controller當中仍是model當中的時候，在「代碼量」上要作到「雨露均沾」，不能少數類「養分不良」。因此不論你的MVC，MVP或者VIPER是如何劃分職責的，各個角色所承擔的職責應當看起來是均勻分配的。

Testability usually comes from the first feature.

方便測試

測試是個有趣的話題，不一樣公司實踐差別很大。我知道有些團隊的產品質量嚴重依賴於QA團隊，有些卻乾脆沒有測試團隊，徹底依賴於開發人員本身保證質量，這兩種風格通常取決於CTO的技術決策，和公司大小倒沒多少關係。對於開發人員自測的狀況，若是代碼架構清晰，各角色職責分配合理，易測性是隨之而來的副產品。

Ease of use and a low maintenance cost

易用且方便維護

易用是針對團隊裏的開發人員而言的。其實究竟是用MVP仍是MVVM，或者MVVM裏數據如何流動，這些具體的規範到底採用何種形態不是最重要的問題，關鍵是在團隊全部成員能有一致的認識，不管是寫代碼仍是Debug都能快速切入。

圍繞上面三個特質，做者一一分析對比了傳統MVC，Apple MVC，MVP，MVVM，VIPER在這三方面的表現，結論是到底選用哪一個純粹是我的口味問題。相較於結論，做者對各個Pattern的角色定義及分析纔是真正有價值的部分，咱們在閱讀評斷其餘相似架構文章的時候，也應該重在瞭解做者對於角色的理解。你們能夠基於這一點，閱讀下其餘一些相似的文章。VIPER理論上並不能歸類於MV（X）系列，而是突破了MVC的思考方式，好比定義了Router處理頁面流程，這對架構師是個很好的思路，在對MV（X）從新設計的時候也應該能有新的思考，所謂「君子不器」。

MV（X）都是以MVC爲原型進行變化，MV（X）到底如何使用沒有教科書式的標準答案，關鍵在於架構師和團隊各成員能達成一致的認識，在遇到問題時能不斷的作調整重構，遇到難以跨越的瓶頸時，能跳出MV（X）尋找解決方案。

第二類樣本：

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

在我看來，組件是比模塊更小的功能單位，不具有業務屬性，只處理基礎通用的問題，相似於工具箱。好比咱們給NSString寫的Category提供base64，給NSDate寫的Category作日期格式化等等。

模塊較之組件粒度更大一些，另外最重要的區別是帶有業務屬性，和業務場景相關聯。好比購物車模塊，註冊登陸模塊，支付模塊等等，模塊每每會對一些通用的組件產生依賴。

層是另外一個維度的概念了，我日常閱讀技術文章的時候，發現不少人會把模塊和層的概念混淆，能夠用一張圖來區分模塊與層的概念：

對於層不容許跨層訪問，也就是說A不能直接訪問C，下層不容許訪問上層，B沒法知道A的實現細節。層的概念可類比TCP/IP協議棧。模塊就靈活多了，A，B，C三者之間能夠任意訪問依賴。因此通常來講層對架構的約束更高，但使得依賴更規範好維護，模塊在複雜的場景下很容易結成一個網狀的依賴形態，難以維護。第二類項目架構都是圍繞層與模塊的劃分所展開，有的有嚴格的層次結構，有的不分層次，經過接口嚴格規範各模塊交互，有的兩者結合，在某一層內再作模塊劃分，下面咱們分析的樣本都屬於上面三種情形。

在開始分析以前，建議你們全篇瞭解下iOS開發圈關於組件化的討論，我以前作過一個總結，裏面有各篇文章連接：http://mrpeak.cn/blog/module/ 。

樣本名：餓了麼移動APP的架構演進

原文地址

做者：聖迪

這篇架構演進的講解是典型的從第一類到第二類的過渡，可簡化爲如下幾步：

1.使用傳統MVC快速迭代App。

2.業務發展，有多個App須要開發，開始組件化，使用CocoaPods進行組件管理，目標是並行開發和代碼重用。架構圖以下：

若是讀過上面關於組件化的文章，這張架構圖就很好理解了，在作好模塊劃分和管理以後，經過Router的方式將讓各模塊產生耦合。這種架構方式已初步具有一個應付大規模業務增加的架構模型。

3.Hybrid，幾乎全部運營類主導的App都會最終投入Hybrid的懷抱，運營團隊對快速上線的要求只能在H5或者Hybrid上得以實現，不過這和架構自己關係不太大，是另外一個大的話題。

4.React-Native & Hot Patch，這和第三步相似都是由運營驅動，幾乎是全部內容運營型app的必經之路。

這四步的演化文章介紹的還比較粗略，更多的細節（好比Router內部實現，業務組件和非業務組件的分工，組件間耦合的方式等）沒有介紹，或者餓了麼App端也還在探索當中。

第三類樣本：

樣本名：攜程移動APP架構優化之旅

原文地址

做者：陳浩然

攜程App端的架構演化在餓了麼架構基礎之上，多了不少優化的細節。

提到了對於基礎SDK組件和業務組件的具體劃分：

核心功能SDK化

? 通信、定位、Hybrid、數據庫、登陸、分享、基礎庫等

? 直接提供給其餘BU獨立App使用

公用業務功能組件化

? 地圖、日曆、城市、圖片、通信錄等13個公共組件

? 減小各BU重複開發工做量

性能數據指標採集：

? 網絡性能:網絡服務成功率、平均耗時、耗時分佈

? 定位:獲取經緯度成功率、城市定位成功率

? 啓動時間、內存、流量等指標

? 多種緯度:系統、App版本、網絡情況、位置等

網絡優化

? 使用TCP長鏈接實現網絡服務

? 根據網絡情況2G/3G/4G/WIFI進行調優參數

? 根據鏈接/讀/寫不一樣階段使用重試機制

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

? 根據網絡延遲選擇服務端IP(使用Ping)

? 使用ProtocolBuffer+Gzip減小Payload

還有Hybrid，HotFix，React Native等就不一一列舉了，這些細節性強的分享有很高的學習價值，能對剛涉足某一塊優化的架構師起到方向指引的做用。

這些看似簡單的劃分每每很考驗架構師的大局觀和經驗，涵蓋面和合理的粒度掌控才能讓技術團隊的開發工做高效並行。

第四類樣本：

樣本名：Facebook iOS Architecture

視頻地址1 視頻地址2

做者：Facebook

除了和上面樣本相似的模塊化，組件優化的介紹以外，還有兩方面新的信息：

在關於Infrastructure的介紹當中有張示意圖介紹團隊分工：

視頻當中不光介紹了基礎組件，業務模塊的劃分，和說明了這些劃分對應的團隊是如何進行協做。

• 最底層的是基礎設施團隊，負責基礎SDK的開發，能夠對應以前談到的非業務組件。

• 中間層是業務團隊，按業務模塊進行劃分，一個業務對應一個團隊，團隊負責全平臺的開發，業務團在開發過程中可反過來回饋基礎SDK。

• 最上面是產品的發佈團隊，產品發佈團隊配合業務團隊對產品的發佈週期和質量作保障。

在Facebook iOS客戶端架構設計當中有關於model層介紹：

以前看過很多架構分享文章，少有對model層深刻探討的，通常提到都是一筆帶過。model層涉及app數據持久化，以及runtime的狀態維護，對app的穩定性和迭代效率起到相當重要的影響。

Facebook的model layer採用的是immutable策略，model雖然能被各層訪問，但model的修改統一由model layer提供接口。上層業務團隊一旦想修改某個model property，須要向model layer維護團隊提出申請，這一設計對狀態的維護至關謹慎。

個人思考

將架構的類型歸爲上述四類也是方便本身搭建關於架構的知識體系，看架構類文章的時候先作好分類再按類別查漏補缺汲取養分。我我的在第一類，第二類架構方面作過一些嘗試和積累，第三類優化上作過一些知識總結。

第一類好比以前的技術分享：

iOS的應用層CDD架構 http://mrpeak.cn/blog/cdd/

這種優化應用層的架構方式是在MV（X）系列基礎之上新的嘗試，已在公司項目當中有過實踐，成效尚可。

第二類好比:

用Swift搭建數據驅動型iOS架構 http://mrpeak.cn/blog/swift-dda/

搭建數據驅動型Android架構 http://mrpeak.cn/blog/dda-android/

用了Swift和Java實現相同的架構思路，這種架構方式也是從已有成熟的項目當中總結提煉而來。

第三類主要是優化和總結的文章：

App安全之網絡傳輸安全

HTTP 2.0的那些事

iOS組件化方案

iOS網絡請求優化之DNS映射

關於架構的總結就到這裏，以上全是一家之言，一則梳理，二則分享，任何想法建議，歡迎交流。

文章轉自  愚公編程的簡書