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

1、App早期架構1.0

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

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

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

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

2、App架構2.0

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

掌新架構如下：

各層的分工如下：

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

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

3、App架構2.0+

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

各層的分工如下：

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

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

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

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

4、App架構3.0

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

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

5、模塊化結合Pods

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

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

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

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

6、總結

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