iOS企業級架構設計

對於單獨的小型應用能處理好各部分的功能，處理好各部分分層的業務邏輯已經實屬不易。因為模組與模組之間的耦合不易拆除，隨著業務的增長，當初嚴格的劃分已經越來越不能滿足要求，模組開始變得異常膨脹，**邏輯也異常的冗餘。乙個好的架構應該能解決這些棘手的問題，乙個好的架構的機制一旦被確定，就不應該輕易更改。

對於乙個好的架構應該分工明確，各部分各司其職，低耦合，減少各部分相互依賴，能很容易的抽離各部分內容。

總體架構：談什麼mvc或者mvvm架構都太膚淺，總之，要有分層的概念

各司其職

其實以上架構分工明確，各層級間配合好，是不錯的ios架構：

整個的資料流向，就是從service獲取服務端的資料開始，在datacenter進行處理，然後拿到view層進行展示；

整個的業務邏輯，是service用來處理多個controller之間的關係，controller用來處理各部分的業務邏輯，負責協調每個view，manager輔助處理；

**實現了分層：業務邏輯層（service或controller）、網路層（service）、資料層（datacenter）、ui層（view）、模型層（model）、公共服務層。

目前架構遇到的問題

變瘦的controller和變胖的view,應該把**均勻的分散在各處

多用繼承，但是把公共部分在父類處理，各部分子類多型，繼承層次太深，業務邏輯比較複雜，**不好修改

機制和策略分離，對於公共部分的業務，不要頻繁修改，修改變化的業務

好的架構兩部分：資料流和業務邏輯

大型應用的架構，採用元件化的方式，基礎sdk元件和業務元件分開，穩定的模組採用庫的方式，改動頻繁的模組採用工程的方式，每個模組拆分成單獨project,支援模組按需編譯。模組之間的通訊方式，可能採用scheme（url）方式進行，這樣減少了模組之間的耦合性。

原則：元件的劃分會越來越細。

model

對於model的處理，會有單獨處理model的類統一對model進行修改

本地資源的載入

可以採用指令碼的方式預先按需載入

採集效能資料

採集日誌，上傳至伺服器，日誌訊息存入hdfs，hive用於查詢

優化細節

啟動優化：優化啟動速度

列表優化：監控效能，預載入，檢視的合成的疊加，檢視的布局優化，cpu與gpu特性

網路服務優化

離線包增量更新

擴充套件性具有整體架構的思想，對未來擴充套件留有餘地。

深度鏈結