iOS 響應式架構設計方案
1.響應式編程是一(yī)種和(hé)事件流有關的(de)編程模式，關注導緻狀态值改變的(de)行為(wèi)事件，一(yī)系列事件組成了事件流。
2.一(yī)系列事件是導緻屬性值發生變化的(de)原因。FRP非常類似于設計模式裏的(de)觀察者模式。
3.FRP與普通的(de)函數式編程相似，但是每個函數可(kě)以接收一(yī)個輸入值的(de)流，如(rú)果其中，一(yī)個新的(de)輸入值到達的(de)話，這個函數将根據最新的(de)輸入值重新計算，并且産生一(yī)個新的(de)輸出。這是一(yī)種”數據流”編程模式。

   iOS 響應式編程優勢；
1，開發過程中，狀态以及狀态之間依賴過多,RAC更加有效率地(dì)處理(lǐ)事件流，而無需顯式去(qù)管理(lǐ)狀态。在OO或者過程式編程中，狀态變化是最難跟蹤，最頭痛的(de)事。這個也是最重要的(de)一(yī)點。

2， 減少變量的(de)使用，由于它跟蹤狀态和(hé)值的(de)變化，因此不需要再申明變量不斷地(dì)觀察狀态和(hé)更新值。

3， 提供統一(yī)的(de)消息傳遞機制，将oc中的(de)通知，action，KVO以及其它所有UIControl事件的(de)變化都進行監控，當變化發生時，就會傳遞事件和(hé)值。

4， 當值随着事件變換時，可(kě)以使用map，filter，reduce等函數便利地(dì)對值進行變換操作。

設計一(yī)個簡單的(de) iOS 響應式架構。iOS 架構 DEMO
關于組件化；
組件化似乎是項目發展壯大過後必然要做(zuò)的(de)事情，它能讓各個業務線的(de)工程師不需要過多的(de)關注其他業務線的(de)代碼，有效的(de)提高(gāo)團隊整體效率。然而實施組件化的(de)時機是在需求相對穩定、産品閉環形成過後。所以本文不會應用組件化，但是這裏簡單談談業界的(de)組件化方案。
組件化的(de)核心問題就是組件間如(rú)何通訊。“軟件工程的(de)一(yī)切問題都能通過一(yī)個間接的(de)中間層解決。”中介模式很自(zì)然的(de)運用起來：
這樣雖然能統一(yī)組件間的(de)通訊請求，但是卻沒有避免 Mediator 和(hé)目标組件的(de)耦合，ModuleA 工程中仍然需要導入 ModuleB

所以重點問題落在了解耦上：

要達到 Mediator 和(hé)目标組件的(de)解耦，就需要實現它們之間的(de)間接調用（圖中虛線），既然是間接調用，必然需要一(yī)種映射機制。在 iOS 開發中，業界大概有三種方式來處理(lǐ)。
(1) 使用 URL -> Block 解耦

簡單來說就是将組件的(de)調用代碼放入 block 中，然後 URL 作為(wèi) key，block 作為(wèi) value，存入一(yī)個全局的(de) hash 容器，組件通過一(yī)個 URL （比如(rú) “native/id=10/type=1” ）向 Mediator 發起請求，Mediator 找到對應的(de)代碼塊執行。由此，解開了 Mediator 和(hé)目标組件的(de)耦合（見博客：蘑菇街 App 的(de)組件化之路）。

這種方案的(de)缺陷很多：組件越多常駐內(nèi)存越多；解析 URL 邏輯複雜；URL 無法表述具體語言相關的(de)對象類型。所以這種方式并不适合組件化解耦。
(2) 使用 Protocol 解耦

阿裏的(de) BeeHive 是該方案的(de)很好實踐，筆(bǐ)者閱讀了一(yī)下源碼，它的(de)大緻工作原理(lǐ)如(rú)下：注冊 Protocol 對應的(de)組件，這個和(hé)上面說的(de) URL->Block 方式如(rú)出一(yī)轍，隻不過這裏是 Protocol-> Module ；組件申請訪問時導入對應的(de) Protocol 通過 Mediator 獲取到對應的(de)組件對象。由于協議的(de)表述能支持所有的(de)對象類型，所以這種方式能基本解決組件間通信的(de)需求。

BeeHive 注冊組件有幾種方式，一(yī)種是監聽了動态鏈接時 image 二進制文件加載完成的(de)回調，通過修改代碼段的(de)方式判斷對應的(de)模塊進行注冊；第二種是在 +load 方法裏面注冊；第三種是異步注冊，但是這種方式存在一(yī)個問題，可(kě)能組件使用方準備使用組件的(de)時候，這個組件還未注冊成功。

BeeHive 還為(wèi)組件設置了優先級的(de)概念，它通過數組來保持優先級排序，在源碼中能看到一(yī)些數組排序的(de)邏輯，這就帶來了相當多的(de)高(gāo)時間複雜度的(de)運算。

所以，組件數量過多的(de)話，會延長(cháng)動态鏈接庫的(de)過程。

BeeHive 為(wèi)了讓每一(yī)個組件享有獨自(zì)的(de) app 生命周期、3D touch 等功能，會将這些系統級的(de)事件發送給每一(yī)個組件，且不談大量的(de)方法調用損耗，它必須讓入口文件 AppDelegate 繼承自(zì) BeeHive 的(de) BHAppDelegate，筆(bǐ)者感覺侵入性過強，并且當開發者需要複寫 AppDelegate 方法的(de)時候，還要注意讓super調用一(yī)下，可(kě)以說很不優雅了。

在基于協議的(de)組件化方案中，組件使用方能直接拿到目标組件的(de)實例，那麽使用者可(kě)能對該實例進行修改，這可(kě)能會帶來安全問題。
(3) 使用 Target-Action 解耦

Casa Taloyum 前輩的(de) iOS應用架構談 組件化方案 為(wèi)此做(zuò)出了最佳實踐。

Mediator 使用 Target-Action 來間接的(de)調用目标組件，無需專門注冊。組件維護者需要做(zuò)一(yī)個 Mediator 的(de)分類，通過硬編碼調用目标組件，然後組件使用者隻需要依賴這個分類就行了。封裝的(de) Mediator 源碼隻有簡單的(de) 200+ 行代碼，并且很易懂。這也讓開發者能對組件化的(de)實施更加有信心，不會因為(wèi)基礎設施的(de)錯誤而束手無策。
小總結

關于以上組件化的(de)簡單表述僅代表筆(bǐ)者的(de)個人見解，由于筆(bǐ)者并沒有真正的(de)實施組件化，所以理(lǐ)解可(kě)能有誤。
雖然筆(bǐ)者設計的(de) iOS 架構不會應用組件化，但是這給我們的(de)架構設計帶來了前瞻性的(de)引導，這非常重要。

模塊化思維劃分文件；

在團隊開發中，項目發展到後期總是會出現某些文件或代碼難以管理(lǐ)，出現這種情況的(de)主要原因通常是項目開發過程中對文件的(de)管理(lǐ)過于随意。
開發者應該盡量将所有代碼文件歸于模塊，而不要出現模拟兩可(kě)的(de)文件。而筆(bǐ)者這裏說的(de)模塊，是有具體意義的(de)模塊，比如(rú)圖片處理(lǐ)模塊、字體處理(lǐ)模塊，而不是諸如(rú) Public、Common 等無具體意義的(de)代碼文件。

試想，在多人開發中，當所有人都覺得有些代碼不知道(dào)怎麽歸類的(de)時候，就會往 Public 裏面扔。當你某天想要整理(lǐ)一(yī)下這個 Public，會發現已經無從下手；或者當你需要遷移項目中的(de)某個業務模塊時，會附帶遷移一(yī)些模塊，當這個模塊是有意義的(de)（比如(rú)圖片處理(lǐ)模塊），你的(de)遷移成本會非常低(dī)，但是當這個藕斷絲連的(de)模塊是 Public 時，時間成本可(kě)能高(gāo)于你的(de)想象，估計你會将它完整的(de)拷貝過去(qù)，而又對新項目造成了污染。

全局的(de)公共文件是産生垃圾代碼的(de)源頭。筆(bǐ)者認為(wèi)幾乎所有的(de)代碼都是可(kě)以歸類為(wèi)模塊的(de)。

大緻梳理(lǐ)了一(yī)個文件分類，當然這個分類是靈活的(de)，隻是要分模塊劃分：

  - GeneralModules 放項目獨有的(de)通用配置模塊（比如(rú)通用顔色模塊、通用字體模塊） 
  - ToolModules 放工具類模塊（比如(rú)系統信息模塊）
  - PackageModules 放基于業務的(de)一(yī)些封裝（比如(rú)提示框模塊、加載菊花模塊）
  - BusinessModules 放業務模塊（比如(rú)購物車、個人中心）

具體裏面放了些什麽，可(kě)以查看筆(bǐ)者的(de) DEMO。

減少全局宏的(de)使用；
很多時候，過多的(de)宏讓項目很不整潔，每一(yī)個開發者都往全局文件添加宏，而往往隻是一(yī)段簡單的(de)代碼，筆(bǐ)者認為(wèi)開發中應該盡量少使用宏，原因如(rú)下：

    宏在預編譯階段替換為(wèi)實際代碼，存在效率問題
    使用宏的(de)地(dì)方可(kě)能隻需要一(yī)塊內(nèi)存，但是宏替換過後開辟了多個（這種情況應該用常量替換宏）
    可(kě)能存在潛在的(de)宏命名沖突
    宏包裝過多的(de)代碼難以理(lǐ)解和(hé)調試
    代碼遷移時需要處理(lǐ)全局的(de)宏

實際上，非得使用宏的(de)地(dì)方并非那麽多，比如(rú)需要定義一(yī)個全局的(de)導航欄字體方便使用，可(kě)以将通用字體的(de)配置參數作為(wèi)一(yī)個模塊：

@interface HQGeneralFont : NSObject
/** 導航欄标題字體 */
+ (UIFont *)navigationBarTitleFont;
@end

或者用常量來代替宏：

.h
FOUNDATION_EXTERN NSString * const kNotify_xxx;
//xxx通知 key.m
NSString * const kNotify_xxx = @"kNotify_xxx";

這麽做(zuò)也便于轉換思維，畢竟 swift 中是沒有宏的(de)。

去(qù)基類化設計；

代碼設計中，應該盡量避免基類的(de)使用，也就是說，你不應該總是要求開發者去(qù)繼承你的(de)基類來做(zuò)功能。使用基類将造成不可(kě)避免的(de)耦合，為(wèi)業務的(de)長(cháng)期發展帶來阻礙（當然某些情況是可(kě)以使用基類的(de)）。

其實使用基類就算了，若是将大量的(de)業務邏輯放入基類中将是災難的(de)開端。試想，當項目新成員一(yī)來就看見成千上萬行的(de)基類代碼TA作何感想？
另外一(yī)種場景，當需要将項目中的(de)某個模塊遷移到其他項目，或者需要将其他項目合并入當前項目，基類的(de)合并将是一(yī)個非常頭疼的(de)問題，它藕斷絲連的(de)模塊和(hé)代碼會讓你抓狂。
那麽，類的(de)工具方法應該放哪兒？對所有類的(de)統一(yī)配置應該放哪兒？對封裝模塊的(de)個性化定制應該怎麽做(zuò)？
裝飾模式

類的(de)工具方法，按道(dào)理(lǐ)說可(kě)以提取為(wèi)模塊，但是有些場景可(kě)能顯得不夠簡潔。

其實隻要留意 iOS 官方的(de) API，你就不難發現裝飾模式的(de)大量應用，使用數個分類将大量的(de)方法按照功能分類，會清晰且優雅：

@interface UIViewController (HQGeneral)
/** 基礎配置 */
- (void)HQGeneral_baseConfig;
@end

@interface UIViewController (HQGeneralBackItem)
/** 配置通用系統導航欄返回按鈕 */
- (void)HQGeneral_configBackItem;
/** 重寫該方法以自(zì)定義系統導航欄返回按鈕點擊事件 */
- (void)HQGeneral_clickBackItem:(UIBarButtonItem *)item;
@end

不過要注意的(de)時，定義分類的(de)時候一(yī)定要加一(yī)個前綴标識以避免方法覆蓋。
AOP

面向切面編程在 iOS 領域經典的(de)應用就是利用 Runtime 去(qù) Hook 方法：

+ (void)load {
    [self HQGeneralHook_exchangeImplementationsWithOriginSel:@selector(viewDidLoad) customSel:@selector(HQGeneralHook_viewDidLoad)];
}

+ (void)HQGeneralHook_exchangeImplementationsWithOriginSel:(SEL)originSel customSel:(SEL)customSel {
    Method origin = class_getInstanceMethod(self, originSel);
    Method custom = class_getInstanceMethod(self, customSel);
    if (origin && custom) {
        method_exchangeImplementations(origin, custom);
    }
}

- (void)HQGeneralHook_viewDidLoad {
    NSLog(@"進入：%@", self);
    [self HQGeneral_baseConfig];
    if (self.navigationController && [self.navigationController.viewControllers indexOfObject:self] != 0) {
        [self HQGeneral_configBackItem];
    }
   
    [self HQGeneralHook_viewDidLoad];
}

代碼中統一(yī)配置了 UIViewController 的(de)系統導航欄返回按鈕，注意這裏調用的(de)業務配置方法都是定義在 UIViewController 的(de)分類裏面的(de)。若有某些導航欄需要格外配置返回按鈕的(de)需求，可(kě)以拓展一(yī)個屬性來控制。
面向協議設計模式

對于一(yī)些封裝的(de)組件，多考慮使用協議來個性化定制，繼承作為(wèi)最差方案，而非是首選方案。

定義一(yī)個遵守組件定制協議的(de)屬性是常用的(de)解決方法：

@property (nonatomic, strong) id<someprotocol>  strategy;</someprotocol>

不同的(de)屬性作為(wèi)不同的(de)策略，組件內(nèi)部通過調用對應的(de)協議方法實現個性化定制。而當使用者想要改變策略時，隻需要更改這個屬性就行了。面向協議設計模式結合策略模式是一(yī)個很好的(de)實踐。

MVC？MVP？MVVM？VIPER？；

業務具體的(de)架構模式是個讓很多開發者頭疼的(de)問題，因為(wèi)有時候能讓複雜業務更清晰，有時候卻因為(wèi)膠水代碼過多而臃腫。

實際上為(wèi)什麽要嚴格的(de)遵守架構模式呢(ne)？為(wèi)什麽每一(yī)個業務模塊的(de)架構模式都要一(yī)模一(yī)樣呢(ne)？

筆(bǐ)者認為(wèi)正确的(de)架構思路一(yī)定是根據業務來的(de)，不同的(de)模塊，不同的(de)業務線完全可(kě)以有不同的(de)架構，隻需要架構足夠清晰不至于晦澀。

大緻設計了一(yī)下架構的(de)主旋律：
    DataCenter 負責數據的(de)獲取、處理(lǐ)、緩存等。
    Model 設計為(wèi)“瘦” Model，便于複用和(hé)遷移；也考慮到數據源可(kě)能數量龐大，若 Model 設計得過于“胖”，會造成更多的(de)內(nèi)存占用。
    View 負責數據的(de)展示，可(kě)以根據業務情況權衡是否需要 ViewModel 處理(lǐ)界面邏輯。
    ViewController 作為(wèi) DataCenter 和(hé) View 的(de)橋梁。

筆(bǐ)者設計的(de)項目目前不會很複雜，多數情況上面的(de)架構就已經夠用，若某個頁面功能過多，完全可(kě)以提取一(yī)些額外的(de)模塊，比如(rú) DataCenter 處理(lǐ)過于複雜，那就把數據的(de)處理(lǐ)和(hé)緩存提取出來：xxxDataProcesser、xxxDataCache。這些都是靈活的(de)，隻需要按照模塊化的(de)思維提取，ViewController 的(de)代碼相信也不會太多。
關于響應式框架
Reactivecocoa 雖然強大，筆(bǐ)者以前也用過，不過它是一(yī)個重量級框架，學(xué)習成本有點高(gāo)，可(kě)能會因為(wèi)團隊成員對其了解不足導緻難以定位的(de)錯誤。
而美團的(de) EasyReact 似乎是一(yī)個福音，筆(bǐ)者大概浏覽了一(yī)下源碼，質量确實很高(gāo)，對性能方面的(de)處理(lǐ)很精緻，基于圖論算法的(de)處理(lǐ)也感覺很棒，項目侵入性也很小。不過缺點就是太新了，需要開發社區一(yī)定時間的(de)驗證，暫時筆(bǐ)者持觀望态度。

責任編輯：中山網站建設
 【網訊網絡】國(guó)家高(gāo)新技術企業》十年(nián)專注軟件開發，網站建設，網頁設計，APP開發，小程序，微信公衆号開發，定制各類企業管理(lǐ)軟件（OA、CRM、ERP、訂單管理(lǐ)系統、進銷存管理(lǐ)軟件等)！服務熱線：0760-88610046、13924923903，http://www.wansion.net