iOS 底層 - 架構(gòu)設(shè)計(jì)

本文源自本人的學(xué)習(xí)記錄整理與理解，其中參考閱讀了部分優(yōu)秀的博客和書籍斯稳，盡量以通俗簡(jiǎn)單的語(yǔ)句轉(zhuǎn)述海铆。引用到的地方如有遺漏或未能一一列舉原文出處還望見諒與指出，另文章內(nèi)容如有不妥之處還望指教挣惰，萬(wàn)分感謝卧斟！

何為架構(gòu) ？

架構(gòu)即Architecture, 是軟件開發(fā)中的設(shè)計(jì)方案憎茂；
它可大可小珍语，小到類與類之間的關(guān)系、模塊與模塊之間的關(guān)系竖幔；
大到客戶端與服務(wù)端之間的關(guān)系; 這些都可以認(rèn)為是一種架構(gòu)設(shè)計(jì)方案

經(jīng)常聽到的架構(gòu)名詞

MVC廊酣、MVP、MVVM赏枚、VIPER亡驰、CDD
三層架構(gòu)、四層架構(gòu)等等

Apple官方的MVC設(shè)計(jì)

M：數(shù)據(jù)模型 V: 視圖View C: 控制器

控制器可以創(chuàng)建View饿幅，并顯示出來(lái)
View內(nèi)部的事件響應(yīng)可以交給控制器來(lái)處理凡辱，比如按鈕的點(diǎn)擊事件
控制器可以通過(guò)發(fā)出網(wǎng)絡(luò)請(qǐng)求或從數(shù)據(jù)庫(kù)緩存中獲取數(shù)據(jù)，數(shù)據(jù)發(fā)生了改變控制器是可以知道的栗恩；會(huì)拿到View的屬性控件把數(shù)據(jù)賦值給它顯示
控制器相當(dāng)于是數(shù)據(jù)和視圖之間的橋梁透乾；數(shù)據(jù)模型和View是互相不知道的
這種設(shè)計(jì)方案最經(jīng)典案例：UITableView 、UICollectionView

優(yōu)點(diǎn):
View和Model解耦磕秤，可重用
View不依賴數(shù)據(jù)模型乳乌，可以拿到任何地方使用；簡(jiǎn)稱萬(wàn)能View
Model不依賴View市咆，可以重復(fù)利用汉操，可以獨(dú)立拿出來(lái)使用

缺點(diǎn)：
Controller 的代碼過(guò)于臃腫，維護(hù)成本高

Apple-MVC.png

MVC變種

控制器可以創(chuàng)建View蒙兰，并顯示出來(lái)
View內(nèi)部擁有模型磷瘤，View內(nèi)部的事件響應(yīng)可以交給控制器來(lái)處理，比如按鈕的點(diǎn)擊事件
控制器可以通過(guò)發(fā)出網(wǎng)絡(luò)請(qǐng)求或從數(shù)據(jù)庫(kù)緩存中獲取數(shù)據(jù)搜变，接下來(lái)會(huì)把模型數(shù)據(jù)傳給View采缚，有View自己負(fù)責(zé)顯示模型的數(shù)據(jù)

變種MVC.png

優(yōu)點(diǎn)：
對(duì)Controller進(jìn)行瘦身，將View內(nèi)部的細(xì)節(jié)封裝起來(lái)了挠他，外界不知道View內(nèi)部的具體實(shí)現(xiàn)
缺點(diǎn)：
View依賴于Model扳抽，換Model可能會(huì)有點(diǎn)麻煩；別人要用就需要把數(shù)據(jù)變成這個(gè)Model傳遞

MVP

M：數(shù)據(jù)模型 V: View P: presenter 分擔(dān)控制器部分業(yè)務(wù)邏輯處理

控制器內(nèi)部擁有presenter，負(fù)責(zé)初始化presenter
presenter專門來(lái)處理業(yè)務(wù)邏輯贸呢，可以聲明一個(gè)弱指針指向控制器赂苗；presenter內(nèi)部操作分三步：

創(chuàng)建View 給控制器顯示
加載模型：網(wǎng)絡(luò)請(qǐng)求或本地緩存
將模型數(shù)據(jù)給View顯示

MVP.png

優(yōu)點(diǎn)：
View和Model解耦 - 相互不知道，可重用
對(duì)Controller進(jìn)行瘦身贮尉，部分業(yè)務(wù)邏輯處理由presenter實(shí)現(xiàn); 同時(shí)Controller可以擁有多個(gè)presenter切換

缺點(diǎn)：
代碼量會(huì)比普通的MVC要大

MVVM

和MVP相似拌滋，最大不同在于MVVM是通過(guò)屬性監(jiān)聽綁定的方式相互協(xié)作

M ：數(shù)據(jù)模型 V: View VM: 處理綁定和顯示

控制器內(nèi)部擁有VM，負(fù)責(zé)初始化VM
VM專門來(lái)業(yè)務(wù)邏輯猜谚，可以聲明一個(gè)弱指針指向控制器败砂；VM內(nèi)部操作分三步：

創(chuàng)建View給控制器顯示，View也聲明一個(gè)指針指向VM,即View擁有VM魏铅，并監(jiān)聽VM屬性model的改變(facebook推出的FBKVOController)

QQ20200421-123214.png

當(dāng)然還有一個(gè)RAC框架可以做到昌犹，不過(guò)該框架內(nèi)容比較多；需要花一些時(shí)間
加載模型：網(wǎng)絡(luò)請(qǐng)求或本地緩存
設(shè)置數(shù)據(jù) ：把獲取到的數(shù)據(jù)賦值給自己的屬性模型

MVVM.png

優(yōu)點(diǎn)：
View和Model解耦 - 相互不知道览芳，可重用
對(duì)Controller進(jìn)行瘦身斜姥，部分業(yè)務(wù)邏輯處理由VM實(shí)現(xiàn)，同時(shí)Controller可以擁有多個(gè)VM切換

缺點(diǎn)：
代碼量會(huì)比普通的MVC要大

分層架構(gòu)

比較成熟的有三層架構(gòu)和四層架構(gòu)

分層的基本思路：
一般來(lái)說(shuō)是把項(xiàng)目中的所有類沧竟，不管是控制器铸敏、View、model悟泵、工具類等對(duì)它們采用分層的設(shè)計(jì)杈笔，每層只需要專注自己的事情不需要關(guān)系其他層怎么做

三層架構(gòu)設(shè)計(jì)：應(yīng)用層、業(yè)務(wù)層糕非、數(shù)據(jù)層

應(yīng)用層：界面相關(guān)的如：控制器蒙具、View控件， MVC朽肥、MVP禁筏、MVVM都是屬于該范疇
業(yè)務(wù)層：處理業(yè)務(wù)邏輯，比如商城應(yīng)用的購(gòu)物車業(yè)務(wù)衡招、結(jié)算業(yè)務(wù)
數(shù)據(jù)層：網(wǎng)絡(luò)請(qǐng)求獲取數(shù)據(jù)篱昔、本地?cái)?shù)據(jù)庫(kù)

四層架構(gòu)設(shè)計(jì)：應(yīng)用層、業(yè)務(wù)層蚁吝、網(wǎng)絡(luò)層旱爆、本地?cái)?shù)據(jù)層

應(yīng)用層：界面相關(guān)的如：控制器舀射、View控件窘茁，MVC、MVP脆烟、MVVM都是屬于這個(gè)范疇
業(yè)務(wù)層：處理業(yè)務(wù)邏輯山林，比如商城應(yīng)用的購(gòu)物車業(yè)務(wù)、結(jié)算業(yè)務(wù)
網(wǎng)絡(luò)層：網(wǎng)絡(luò)請(qǐng)求獲取數(shù)據(jù)
本地?cái)?shù)據(jù)層：本地?cái)?shù)據(jù)庫(kù)

不管三層架構(gòu)還是四層架構(gòu)也好主要的還是依托項(xiàng)目的業(yè)務(wù)，做出合適的選擇驼抹，沒(méi)有最好只有只有最合適桑孩！

四層架構(gòu).png

組件化架構(gòu)

組件化要求：不能出現(xiàn)橫向依賴，不能出現(xiàn)反向依賴框冀；

當(dāng)出現(xiàn)橫向依賴時(shí)考慮把組件下沉流椒，以保證能夠?qū)崿F(xiàn)解耦合；即編程原則中的依賴倒置原則
反向依賴: 下層不能依賴上層明也，上層可以依賴下層宣虾；這是單向的依賴；即編程原則中的迪米特原則

隨著移動(dòng)互聯(lián)網(wǎng)的不斷發(fā)展温数，很多程序代碼量和業(yè)務(wù)越來(lái)越多绣硝，現(xiàn)有架構(gòu)已經(jīng)不適合公司業(yè)務(wù)的發(fā)展速度了，很多都面臨著重構(gòu)的問(wèn)題撑刺。
在公司項(xiàng)目開發(fā)中鹉胖，如果項(xiàng)目比較小，普通的單工程+MVC架構(gòu)就可以滿足大多數(shù)需求了够傍。但是像淘寶甫菠、蘑菇街、微信這樣的大型項(xiàng)目冕屯，原有的單工程架構(gòu)就不足以滿足架構(gòu)需求了淑蔚。

就拿淘寶來(lái)說(shuō)，淘寶在13年開啟的“All in 無(wú)線”戰(zhàn)略中愕撰，就將阿里系大多數(shù)業(yè)務(wù)都加入到手機(jī)淘寶中刹衫，使客戶端出現(xiàn)了業(yè)務(wù)的爆發(fā)。在這種情況下搞挣，單工程架構(gòu)則已經(jīng)遠(yuǎn)遠(yuǎn)不能滿足現(xiàn)有業(yè)務(wù)需求了带迟。所以在這種情況下，淘寶在13年開啟了插件化架構(gòu)的重構(gòu)囱桨，后來(lái)在14年迎來(lái)了手機(jī)淘寶有史以來(lái)最大規(guī)模的重構(gòu)仓犬，將其徹底重構(gòu)為組件化架構(gòu)。

將每個(gè)模塊作為一個(gè)組件并且建立一個(gè)主項(xiàng)目舍肠，這個(gè)主項(xiàng)目負(fù)責(zé)集成所有組件搀继；這樣的方式被稱為組件化！
進(jìn)行組件化開發(fā)后翠语，可以把每個(gè)組件當(dāng)做一個(gè)獨(dú)立的app叽躯，每個(gè)組件甚至可以采取不同的架構(gòu)，例如分別使用MVVM肌括、MVC点骑、MVCS等架構(gòu)。

當(dāng)下組件化大多是基于CocoaPods實(shí)現(xiàn)組件化架構(gòu)，利用中間件來(lái)完成組件之間通信黑滴，在CocoaPods中可以通過(guò)podfile很好的配置各個(gè)組件憨募，包括組件的增加和刪除，以及控制某個(gè)組件的版本袁辈。使用CocoaPods的原因菜谣，很大程度是為了解決大型項(xiàng)目中，代碼管理工具merge代碼導(dǎo)致的沖突晚缩。并且可以通過(guò)配置podfile文件葛菇，輕松配置項(xiàng)目。

注意：在組件化架構(gòu)是需要進(jìn)行分層的橡羞，這其中有分層架構(gòu)的思想在里面眯停；層這個(gè)概念是用來(lái)區(qū)分組件的職能的，在項(xiàng)目越做越大的過(guò)程中分層的思想就變得非常重要卿泽；不然大家會(huì)把一個(gè)項(xiàng)目理解成一團(tuán)麻莺债，沒(méi)有清晰的劃分對(duì)未來(lái)的擴(kuò)展和優(yōu)化非常不利；

架構(gòu)和設(shè)計(jì)模式的關(guān)系

設(shè)計(jì)模式即 Design Pattern,是一套被反復(fù)使用签夭、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)齐邦；使用設(shè)計(jì)模式的好處是：可重用代碼、讓代碼更容易被他人理解第租、保證代碼可靠性措拇；一般與編程語(yǔ)言無(wú)關(guān)，是一套比較成熟的編程思想