2015年入職XDF參與留留學(xué)iOS端的研發(fā)，至今，參與了好幾個項目（留留學(xué)、掌上新東方、SL、樂聽說等），最近負(fù)責(zé)樂聽說iOS App端。不同項目的經(jīng)歷，讓我接觸到了不同的項目架構(gòu)和代碼風(fēng)格，也讓我對App的項目架構(gòu)有所思考與心得。

1、App早期架構(gòu)1.0

2015年6月留留學(xué)App iOS端1.0.0版本誕生，當(dāng)時采用的架構(gòu)很簡單，就是在傳統(tǒng)的MVC架構(gòu)基礎(chǔ)上，封裝了一個網(wǎng)絡(luò)服務(wù)層構(gòu)建而成的，當(dāng)時為了快速迭代上線，所以移動端App開發(fā)采用了“短平快”的MVC架構(gòu)，架構(gòu)如下圖所示：

這種架構(gòu)以層次結(jié)構(gòu)簡單清晰，代碼容易開發(fā)而被大多數(shù)人接受，各層的分工如下：

• View層：顯示層，負(fù)責(zé)UI的渲染。
• Controller層：作為View層和Service層中間層對上提供數(shù)據(jù)給View層展示，對下負(fù)響應(yīng)用戶的交互。
• Service層：業(yè)務(wù)層，負(fù)責(zé)APP業(yè)務(wù)邏輯封裝，如預(yù)約課程等業(yè)務(wù)邏輯，對上層提供業(yè)務(wù)封裝后的接口。
• Modle層：數(shù)據(jù)層，負(fù)責(zé)數(shù)據(jù)的包裝、整理、解析等。
• mPass層：主要負(fù)責(zé)提供一些底層的功能支持，如數(shù)據(jù)庫、拍照、分享等。

但經(jīng)過幾個版本的迭代，我們發(fā)現(xiàn)App所采用的MVC架構(gòu)從Model-View-Controller走向了Massive-View-Controller的終點，其最嚴(yán)重的結(jié)果就是Control層的代碼越來越多越來越臃腫難于擴展維護，同時Control層和View層之間存在一些較高的耦合。
這種架構(gòu)在開發(fā)的后期會由于其超高耦和性，從而造就龐大Controller層，而這也是一直被人所詬病。

2、App架構(gòu)2.0

基于上述遇到的問題，我們對原有的傳統(tǒng)架構(gòu)做了優(yōu)化和調(diào)整，提出App架構(gòu)2.0，并在留留學(xué)2.3.0項目中開始逐步重構(gòu)采用MVVM分層架構(gòu)，通過MVVM架構(gòu)，可以有效實現(xiàn)Controller和View的解耦，同時使Controller輕量級，最終使越來越臃腫的Controller層逐步縮小并分解解耦，業(yè)務(wù)邏輯分模塊下沉。
我參與的三個項目都是基于MVVM架構(gòu)，包括：留留學(xué)App2.3.0，掌上新東方App等項目，現(xiàn)在以留留學(xué)、掌上新東方為例，留留學(xué)調(diào)整后的架構(gòu)如下：

掌新架構(gòu)如下：

各層的分工如下：

• View層：顯示層，負(fù)責(zé)UI的渲染。
• Controller層：作為View層和ViewModel層中間層對上提供數(shù)據(jù)給View層展示，對下負(fù)響應(yīng)用戶的交互。
• ViewModle層：把原來ViewController層的業(yè)務(wù)邏輯和頁面邏輯等剝離出來放到ViewModel層。
• Modle層：數(shù)據(jù)層。
• mPass層：主要負(fù)責(zé)提供一些底層的功能支持，如數(shù)據(jù)庫、拍照、分享等。

通過MVVM架構(gòu)，可以有效實現(xiàn)Controller和View的解耦，同時使Controller輕量級，但這種架構(gòu)也有一些弊端，會讓導(dǎo)致VM或Model中出現(xiàn)大量的基本業(yè)務(wù)處理、數(shù)據(jù)處理等，最后也會導(dǎo)致VM層變的臃腫，同時讓Model層沒那么純粹，變的雜亂無序，所以還是需要進一步優(yōu)化和剝離業(yè)務(wù)與數(shù)據(jù)的耦合。

3、App架構(gòu)2.0+

也基于上述遇到的問題，我們對App架構(gòu)2.0做了優(yōu)化和調(diào)整，便衍生了App2.0+分層架構(gòu)，采用MVVM+分層架構(gòu)模式解耦，使越來越臃腫的Controller層逐步縮小并分解解耦，業(yè)務(wù)邏輯分模塊下沉。由于留留學(xué)3.1.0之后就暫停了迭代，所以只對掌上新東方App 3.1.0之后的版本開始逐步采用MVVM+分層架構(gòu)模式進一步解耦。調(diào)整后的架構(gòu)如下：

各層的分工如下：

• View層：顯示層，負(fù)責(zé)UI的渲染。
• Controller層：作為View層和ViewModel層中間層對上提供數(shù)據(jù)給View層展示，對下負(fù)響應(yīng)用戶的交互。
• ViewModel層：負(fù)責(zé)掌新APP業(yè)務(wù)邏輯封裝，如預(yù)約課程等業(yè)務(wù)邏輯，對上層提供業(yè)務(wù)封裝后的接口。
• Service層：負(fù)責(zé)具體的業(yè)務(wù)實現(xiàn)，包括對網(wǎng)絡(luò)請求的封裝以及請求后返回的數(shù)據(jù)的包裝、整理、解析等，緩存等。
• Modle層：數(shù)據(jù)層。
• mPass層：主要負(fù)責(zé)提供一些底層的功能支持，如數(shù)據(jù)庫、拍照、分享等。

對比2.0架構(gòu)，我們是在ViewModel層和Model層之間插入了一個Service層，對于此次架構(gòu)調(diào)整優(yōu)點如下:

1. Controller層只用來做中轉(zhuǎn)層不參與業(yè)務(wù)邏輯等處理
2. Controller層對上(View層)只提供頁面展示所需數(shù)據(jù)，對下調(diào)用(ViewModel層)暴露出的業(yè)務(wù)邏輯接口
3. 方便進行功能，業(yè)務(wù)邏輯的單元測試
4. ViewModel層實現(xiàn)整個業(yè)務(wù)邏輯，實現(xiàn)對上層只提供接口因此此層靈活，易維護
5. Service負(fù)責(zé)具體業(yè)務(wù)的實現(xiàn)，并對數(shù)據(jù)進行封裝、整理等

對比1.0架構(gòu)，我們是在原有的Controller層和Service層之間插入了一個ViewModel層，架構(gòu)調(diào)整前后對比如下表:

4、App架構(gòu)3.0

都是基于當(dāng)前我參與的樂聽說基于2.0+架構(gòu)采用swift開發(fā)的口語評測App，留留學(xué)、新東方、樂聽說App等現(xiàn)有架構(gòu)可實現(xiàn)內(nèi)部豎向解耦，后續(xù)開發(fā)中我們將逐步實現(xiàn)各個層同層內(nèi)部子模塊的解耦工作（橫向解耦）；同層之間各個子模塊之間調(diào)用相互依賴，會嚴(yán)重影響各個模塊之間的解耦，如A模塊內(nèi)部（甚至外部）依賴B、C模塊，而B、C模塊又依賴A模塊，這種相互依賴、相互include的情況導(dǎo)致各個模塊相互不能獨立，嚴(yán)重影響編譯速度和擴展性、靈活性等， 在后續(xù)版本中為了完成橫向解耦我們內(nèi)部將開發(fā)實現(xiàn)一個動態(tài)路由組件（DR，Dynamic Route），以樂聽說為例進行說明，如下圖：

路由實現(xiàn)方案簡圖如下：

5、模塊化結(jié)合Pods

參與的項目基本都是采用模塊化開發(fā)，盡量實現(xiàn)高內(nèi)聚低耦合，以掌上新東方為例，App研發(fā)模塊以及對接平臺眾多，我們采用MVVM架構(gòu)（后期采用MVVM+架構(gòu)）進行模塊化開發(fā)，實現(xiàn)工程的可擴展性以及易維護性，盡量做到高內(nèi)聚低耦合。如下圖：

當(dāng)公司里面有多個項目同時進行，并且有可能是多個人分別不同項目時，就會存在相同模塊重復(fù)開發(fā)，其實每個APP中都是有很多共同的模塊，當(dāng)然有可能你會把相同功能模塊代碼復(fù)制一份在新項目中，但這其實并不是最好的方式，在后期不斷迭代過程中，不同的人會往里面增加很多帶有個人色彩的代碼；這樣就像相同的模塊項目后期對于多個項目統(tǒng)一管理也是災(zāi)難性，有可能會失控，哪怕項目轉(zhuǎn)移別人接手也會無形中浪費很多時間，增加維護成本，所以實例中更注重對于一些相同模塊進行提取，求同存異。

我們將嘗試采用模塊化結(jié)合Pods進行管理，對于常用功能的封裝，只要開放出一些簡單開關(guān)配置方式，就可以實現(xiàn)一個功能，比如日志記錄、網(wǎng)絡(luò)請求模塊、網(wǎng)絡(luò)狀態(tài)變化提示等。

將分OC和Swift語言開發(fā)兩套對應(yīng)的路由組件，會優(yōu)先著手OC版本的研發(fā)，由于之前都忙于項目開發(fā)，近期會抽時間對代碼進行完善（LLRouter），如有好的思路和見解，可以給我提issues，核心代碼如下圖：

6、總結(jié)

App架構(gòu)以及相關(guān)性能的優(yōu)化不是一蹴而就的，需要不斷的探索和鉆研！同時架構(gòu)沒有真正的好壞之分，只要適用于自己的業(yè)務(wù)，就是好的架構(gòu)！
以上只是我的一些心得和感悟，肯定有一些地方需要完善，如有不對或不恰當(dāng)，望大家留言討論！