iOS 響應式架構設計方案
2021-10-14 分類： 網站建設
iOS 響應式架構設計方案
1.響應式編程是一種和事件流有關的編程模式，關注導致狀態(tài)值改變的行為事件，一系列事件組成了事件流。
2.一系列事件是導致屬性值發(fā)生變化的原因。FRP非常類似于設計模式里的觀察者模式。
1，開發(fā)過程中，狀態(tài)以及狀態(tài)之間依賴過多,RAC更加有效率地處理事件流，而無需顯式去管理狀態(tài)。在OO或者過程式編程中，狀態(tài)變化是最難跟蹤，最頭痛的事。這個也是最重要的一點。
2， 減少變量的使用，由于它跟蹤狀態(tài)和值的變化，因此不需要再申明變量不斷地觀察狀態(tài)和更新值。
3， 提供統(tǒng)一的消息傳遞機制，將oc中的通知，action，KVO以及其它所有UIControl事件的變化都進行監(jiān)控，當變化發(fā)生時，就會傳遞事件和值。
4， 當值隨著事件變換時，可以使用map，filter，reduce等函數便利地對值進行變換操作。
設計一個簡單的 iOS 響應式架構。iOS 架構 DEMO
關于組件化；
組件化似乎是項目發(fā)展壯大過后必然要做的事情，它能讓各個業(yè)務線的工程師不需要過多的關注其他業(yè)務線的代碼，有效的提高團隊整體效率。然而實施組件化的時機是在需求相對穩(wěn)定、產品閉環(huán)形成過后。所以本文不會應用組件化，但是這里簡單談談業(yè)界的組件化方案。
組件化的核心問題就是組件間如何通訊?！败浖こ痰囊磺袉栴}都能通過一個間接的中間層解決?！敝薪槟Ｊ胶茏匀坏倪\用起來：
這樣雖然能統(tǒng)一組件間的通訊請求，但是卻沒有避免 Mediator 和目標組件的耦合，ModuleA 工程中仍然需要導入 ModuleB
所以重點問題落在了解耦上：
要達到 Mediator 和目標組件的解耦，就需要實現它們之間的間接調用（圖中虛線），既然是間接調用，必然需要一種映射機制。在 iOS 開發(fā)中，業(yè)界大概有三種方式來處理。
(1) 使用 URL -> Block 解耦
簡單來說就是將組件的調用代碼放入 block 中，然后 URL 作為 key，block 作為 value，存入一個全局的 hash 容器，組件通過一個 URL （比如 “native/id=10/type=1” ）向 Mediator 發(fā)起請求，Mediator 找到對應的代碼塊執(zhí)行。由此，解開了 Mediator 和目標組件的耦合（見博客：蘑菇街 App 的組件化之路）。
這種方案的缺陷很多：組件越多常駐內存越多；解析 URL 邏輯復雜；URL 無法表述具體語言相關的對象類型。所以這種方式并不適合組件化解耦。
(2) 使用 Protocol 解耦
阿里的 BeeHive 是該方案的很好實踐，筆者閱讀了一下源碼，它的大致工作原理如下：注冊 Protocol 對應的組件，這個和上面說的 URL->Block 方式如出一轍，只不過這里是 Protocol-> Module ；組件申請訪問時導入對應的 Protocol 通過 Mediator 獲取到對應的組件對象。由于協議的表述能支持所有的對象類型，所以這種方式能基本解決組件間通信的需求。
BeeHive 注冊組件有幾種方式，一種是監(jiān)聽了動態(tài)鏈接時 image 二進制文件加載完成的回調，通過修改代碼段的方式判斷對應的模塊進行注冊；第二種是在 +load 方法里面注冊；第三種是異步注冊，但是這種方式存在一個問題，可能組件使用方準備使用組件的時候，這個組件還未注冊成功。
BeeHive 還為組件設置了優(yōu)先級的概念，它通過數組來保持優(yōu)先級排序，在源碼中能看到一些數組排序的邏輯，這就帶來了相當多的高時間復雜度的運算。
所以，組件數量過多的話，會延長動態(tài)鏈接庫的過程。
BeeHive 為了讓每一個組件享有獨自的 app 生命周期、3D touch 等功能，會將這些系統(tǒng)級的事件發(fā)送給每一個組件，且不談大量的方法調用損耗，它必須讓入口文件 AppDelegate 繼承自 BeeHive 的 BHAppDelegate，筆者感覺侵入性過強，并且當開發(fā)者需要復寫 AppDelegate 方法的時候，還要注意讓super調用一下，可以說很不優(yōu)雅了。
在基于協議的組件化方案中，組件使用方能直接拿到目標組件的實例，那么使用者可能對該實例進行修改，這可能會帶來安全問題。
(3) 使用 Target-Action 解耦
Casa Taloyum 前輩的 iOS應用架構談 組件化方案 為此做出了好實踐。
Mediator 使用 Target-Action 來間接的調用目標組件，無需專門注冊。組件維護者需要做一個 Mediator 的分類，通過硬編碼調用目標組件，然后組件使用者只需要依賴這個分類就行了。封裝的 Mediator 源碼只有簡單的 200+ 行代碼，并且很易懂。這也讓開發(fā)者能對組件化的實施更加有信心，不會因為基礎設施的錯誤而束手無策。
小總結
關于以上組件化的簡單表述僅代表筆者的個人見解，由于筆者并沒有真正的實施組件化，所以理解可能有誤。
雖然筆者設計的 iOS 架構不會應用組件化，但是這給我們的架構設計帶來了前瞻性的引導，這非常重要。
模塊化思維劃分文件；
在團隊開發(fā)中，項目發(fā)展到后期總是會出現某些文件或代碼難以管理，出現這種情況的主要原因通常是項目開發(fā)過程中對文件的管理過于隨意。
開發(fā)者應該盡量將所有代碼文件歸于模塊，而不要出現模擬兩可的文件。而筆者這里說的模塊，是有具體意義的模塊，比如圖片處理模塊、字體處理模塊，而不是諸如 Public、Common 等無具體意義的代碼文件。
試想，在多人開發(fā)中，當所有人都覺得有些代碼不知道怎么歸類的時候，就會往 Public 里面扔。當你某天想要整理一下這個 Public，會發(fā)現已經無從下手；或者當你需要遷移項目中的某個業(yè)務模塊時，會附帶遷移一些模塊，當這個模塊是有意義的（比如圖片處理模塊），你的遷移成本會非常低，但是當這個藕斷絲連的模塊是 Public 時，時間成本可能高于你的想象，估計你會將它完整的拷貝過去，而又對新項目造成了污染。
全局的公共文件是產生垃圾代碼的源頭。筆者認為幾乎所有的代碼都是可以歸類為模塊的。
大致梳理了一個文件分類，當然這個分類是靈活的，只是要分模塊劃分：
- GeneralModules 放項目獨有的通用配置模塊（比如通用顏色模塊、通用字體模塊）
- ToolModules 放工具類模塊（比如系統(tǒng)信息模塊）
- PackageModules 放基于業(yè)務的一些封裝（比如提示框模塊、加載菊花模塊）
- BusinessModules 放業(yè)務模塊（比如購物車、個人中心）
具體里面放了些什么，可以查看筆者的 DEMO。
減少全局宏的使用；
很多時候，過多的宏讓項目很不整潔，每一個開發(fā)者都往全局文件添加宏，而往往只是一段簡單的代碼，筆者認為開發(fā)中應該盡量少使用宏，原因如下：
宏在預編譯階段替換為實際代碼，存在效率問題
使用宏的地方可能只需要一塊內存，但是宏替換過后開辟了多個（這種情況應該用常量替換宏）
可能存在潛在的宏命名沖突
宏包裝過多的代碼難以理解和調試
代碼遷移時需要處理全局的宏
實際上，非得使用宏的地方并非那么多，比如需要定義一個全局的導航欄字體方便使用，可以將通用字體的配置參數作為一個模塊：
@interface HQGeneralFont : NSObject
/** 導航欄標題字體 */
+ (UIFont *)navigationBarTitleFont;
@end
或者用常量來代替宏：
.h
FOUNDATION_EXTERN NSString * const kNotify_xxx;
//xxx通知 key.m
NSString * const kNotify_xxx = @"kNotify_xxx";
這么做也便于轉換思維，畢竟 swift 中是沒有宏的。
去基類化設計；
代碼設計中，應該盡量避免基類的使用，也就是說，你不應該總是要求開發(fā)者去繼承你的基類來做功能。使用基類將造成不可避免的耦合，為業(yè)務的長期發(fā)展帶來阻礙（當然某些情況是可以使用基類的）。
其實使用基類就算了，若是將大量的業(yè)務邏輯放入基類中將是災難的開端。試想，當項目新成員一來就看見成千上萬行的基類代碼TA作何感想？
另外一種場景，當需要將項目中的某個模塊遷移到其他項目，或者需要將其他項目合并入當前項目，基類的合并將是一個非常頭疼的問題，它藕斷絲連的模塊和代碼會讓你抓狂。
那么，類的工具方法應該放哪兒？對所有類的統(tǒng)一配置應該放哪兒？對封裝模塊的個性化定制應該怎么做？
裝飾模式
類的工具方法，按道理說可以提取為模塊，但是有些場景可能顯得不夠簡潔。
其實只要留意 iOS 官方的 API，你就不難發(fā)現裝飾模式的大量應用，使用數個分類將大量的方法按照功能分類，會清晰且優(yōu)雅：
@interface UIViewController (HQGeneral)
/** 基礎配置 */
- (void)HQGeneral_baseConfig;
@end
@interface UIViewController (HQGeneralBackItem)
/** 配置通用系統(tǒng)導航欄返回按鈕 */
- (void)HQGeneral_configBackItem;
/** 重寫該方法以自定義系統(tǒng)導航欄返回按鈕點擊事件 */
- (void)HQGeneral_clickBackItem:(UIBarButtonItem *)item;
@end
不過要注意的時，定義分類的時候一定要加一個前綴標識以避免方法覆蓋。
AOP
面向切面編程在 iOS 領域經典的應用就是利用 Runtime 去 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];
}
代碼中統(tǒng)一配置了 UIViewController 的系統(tǒng)導航欄返回按鈕，注意這里調用的業(yè)務配置方法都是定義在 UIViewController 的分類里面的。若有某些導航欄需要格外配置返回按鈕的需求，可以拓展一個屬性來控制。
面向協議設計模式
對于一些封裝的組件，多考慮使用協議來個性化定制，繼承作為最差方案，而非是選方案。
定義一個遵守組件定制協議的屬性是常用的解決方法：
@property (nonatomic, strong) id<someprotocol> strategy;</someprotocol>
不同的屬性作為不同的策略，組件內部通過調用對應的協議方法實現個性化定制。而當使用者想要改變策略時，只需要更改這個屬性就行了。面向協議設計模式結合策略模式是一個很好的實踐。
MVC？MVP？MVVM？VIPER？；
業(yè)務具體的架構模式是個讓很多開發(fā)者頭疼的問題，因為有時候能讓復雜業(yè)務更清晰，有時候卻因為膠水代碼過多而臃腫。
實際上為什么要嚴格的遵守架構模式呢？為什么每一個業(yè)務模塊的架構模式都要一模一樣呢？
筆者認為正確的架構思路一定是根據業(yè)務來的，不同的模塊，不同的業(yè)務線完全可以有不同的架構，只需要架構足夠清晰不至于晦澀。
大致設計了一下架構的主旋律：
DataCenter 負責數據的獲取、處理、緩存等。
Model 設計為“瘦” Model，便于復用和遷移；也考慮到數據源可能數量龐大，若 Model 設計得過于“胖”，會造成更多的內存占用。
View 負責數據的展示，可以根據業(yè)務情況權衡是否需要 ViewModel 處理界面邏輯。
ViewController 作為 DataCenter 和 View 的橋梁。
筆者設計的項目目前不會很復雜，多數情況上面的架構就已經夠用，若某個頁面功能過多，完全可以提取一些額外的模塊，比如 DataCenter 處理過于復雜，那就把數據的處理和緩存提取出來：xxxDataProcesser、xxxDataCache。這些都是靈活的，只需要按照模塊化的思維提取，ViewController 的代碼相信也不會太多。
關于響應式框架
Reactivecocoa 雖然強大，筆者以前也用過，不過它是一個重量級框架，學習成本有點高，可能會因為團隊成員對其了解不足導致難以定位的錯誤。
而美團的 EasyReact 似乎是一個福音，筆者大概瀏覽了一下源碼，質量確實很高，對性能方面的處理很精致，基于圖論算法的處理也感覺很棒，項目侵入性也很小。不過缺點就是太新了，需要開發(fā)社區(qū)一定時間的驗證，暫時筆者持觀望態(tài)度。
1.響應式編程是一種和事件流有關的編程模式，關注導致狀態(tài)值改變的行為事件，一系列事件組成了事件流。
2.一系列事件是導致屬性值發(fā)生變化的原因。FRP非常類似于設計模式里的觀察者模式。
3.FRP與普通的函數式編程相似，但是每個函數可以接收一個輸入值的流，如果其中，一個新的輸入值到達的話，這個函數將根據最新的輸入值重新計算，并且產生一個新的輸出。這是一種”數據流”編程模式。
1，開發(fā)過程中，狀態(tài)以及狀態(tài)之間依賴過多,RAC更加有效率地處理事件流，而無需顯式去管理狀態(tài)。在OO或者過程式編程中，狀態(tài)變化是最難跟蹤，最頭痛的事。這個也是最重要的一點。
2， 減少變量的使用，由于它跟蹤狀態(tài)和值的變化，因此不需要再申明變量不斷地觀察狀態(tài)和更新值。
3， 提供統(tǒng)一的消息傳遞機制，將oc中的通知，action，KVO以及其它所有UIControl事件的變化都進行監(jiān)控，當變化發(fā)生時，就會傳遞事件和值。
4， 當值隨著事件變換時，可以使用map，filter，reduce等函數便利地對值進行變換操作。
設計一個簡單的 iOS 響應式架構。iOS 架構 DEMO
關于組件化；
組件化似乎是項目發(fā)展壯大過后必然要做的事情，它能讓各個業(yè)務線的工程師不需要過多的關注其他業(yè)務線的代碼，有效的提高團隊整體效率。然而實施組件化的時機是在需求相對穩(wěn)定、產品閉環(huán)形成過后。所以本文不會應用組件化，但是這里簡單談談業(yè)界的組件化方案。
組件化的核心問題就是組件間如何通訊?！败浖こ痰囊磺袉栴}都能通過一個間接的中間層解決?！敝薪槟Ｊ胶茏匀坏倪\用起來：
這樣雖然能統(tǒng)一組件間的通訊請求，但是卻沒有避免 Mediator 和目標組件的耦合，ModuleA 工程中仍然需要導入 ModuleB
所以重點問題落在了解耦上：
要達到 Mediator 和目標組件的解耦，就需要實現它們之間的間接調用（圖中虛線），既然是間接調用，必然需要一種映射機制。在 iOS 開發(fā)中，業(yè)界大概有三種方式來處理。
(1) 使用 URL -> Block 解耦
簡單來說就是將組件的調用代碼放入 block 中，然后 URL 作為 key，block 作為 value，存入一個全局的 hash 容器，組件通過一個 URL （比如 “native/id=10/type=1” ）向 Mediator 發(fā)起請求，Mediator 找到對應的代碼塊執(zhí)行。由此，解開了 Mediator 和目標組件的耦合（見博客：蘑菇街 App 的組件化之路）。
這種方案的缺陷很多：組件越多常駐內存越多；解析 URL 邏輯復雜；URL 無法表述具體語言相關的對象類型。所以這種方式并不適合組件化解耦。
(2) 使用 Protocol 解耦
阿里的 BeeHive 是該方案的很好實踐，筆者閱讀了一下源碼，它的大致工作原理如下：注冊 Protocol 對應的組件，這個和上面說的 URL->Block 方式如出一轍，只不過這里是 Protocol-> Module ；組件申請訪問時導入對應的 Protocol 通過 Mediator 獲取到對應的組件對象。由于協議的表述能支持所有的對象類型，所以這種方式能基本解決組件間通信的需求。
BeeHive 注冊組件有幾種方式，一種是監(jiān)聽了動態(tài)鏈接時 image 二進制文件加載完成的回調，通過修改代碼段的方式判斷對應的模塊進行注冊；第二種是在 +load 方法里面注冊；第三種是異步注冊，但是這種方式存在一個問題，可能組件使用方準備使用組件的時候，這個組件還未注冊成功。
BeeHive 還為組件設置了優(yōu)先級的概念，它通過數組來保持優(yōu)先級排序，在源碼中能看到一些數組排序的邏輯，這就帶來了相當多的高時間復雜度的運算。
所以，組件數量過多的話，會延長動態(tài)鏈接庫的過程。
BeeHive 為了讓每一個組件享有獨自的 app 生命周期、3D touch 等功能，會將這些系統(tǒng)級的事件發(fā)送給每一個組件，且不談大量的方法調用損耗，它必須讓入口文件 AppDelegate 繼承自 BeeHive 的 BHAppDelegate，筆者感覺侵入性過強，并且當開發(fā)者需要復寫 AppDelegate 方法的時候，還要注意讓super調用一下，可以說很不優(yōu)雅了。
在基于協議的組件化方案中，組件使用方能直接拿到目標組件的實例，那么使用者可能對該實例進行修改，這可能會帶來安全問題。
(3) 使用 Target-Action 解耦
Casa Taloyum 前輩的 iOS應用架構談 組件化方案 為此做出了好實踐。
Mediator 使用 Target-Action 來間接的調用目標組件，無需專門注冊。組件維護者需要做一個 Mediator 的分類，通過硬編碼調用目標組件，然后組件使用者只需要依賴這個分類就行了。封裝的 Mediator 源碼只有簡單的 200+ 行代碼，并且很易懂。這也讓開發(fā)者能對組件化的實施更加有信心，不會因為基礎設施的錯誤而束手無策。
小總結
關于以上組件化的簡單表述僅代表筆者的個人見解，由于筆者并沒有真正的實施組件化，所以理解可能有誤。
雖然筆者設計的 iOS 架構不會應用組件化，但是這給我們的架構設計帶來了前瞻性的引導，這非常重要。
模塊化思維劃分文件；
在團隊開發(fā)中，項目發(fā)展到后期總是會出現某些文件或代碼難以管理，出現這種情況的主要原因通常是項目開發(fā)過程中對文件的管理過于隨意。
開發(fā)者應該盡量將所有代碼文件歸于模塊，而不要出現模擬兩可的文件。而筆者這里說的模塊，是有具體意義的模塊，比如圖片處理模塊、字體處理模塊，而不是諸如 Public、Common 等無具體意義的代碼文件。
試想，在多人開發(fā)中，當所有人都覺得有些代碼不知道怎么歸類的時候，就會往 Public 里面扔。當你某天想要整理一下這個 Public，會發(fā)現已經無從下手；或者當你需要遷移項目中的某個業(yè)務模塊時，會附帶遷移一些模塊，當這個模塊是有意義的（比如圖片處理模塊），你的遷移成本會非常低，但是當這個藕斷絲連的模塊是 Public 時，時間成本可能高于你的想象，估計你會將它完整的拷貝過去，而又對新項目造成了污染。
全局的公共文件是產生垃圾代碼的源頭。筆者認為幾乎所有的代碼都是可以歸類為模塊的。
大致梳理了一個文件分類，當然這個分類是靈活的，只是要分模塊劃分：
- GeneralModules 放項目獨有的通用配置模塊（比如通用顏色模塊、通用字體模塊）
- ToolModules 放工具類模塊（比如系統(tǒng)信息模塊）
- PackageModules 放基于業(yè)務的一些封裝（比如提示框模塊、加載菊花模塊）
- BusinessModules 放業(yè)務模塊（比如購物車、個人中心）
具體里面放了些什么，可以查看筆者的 DEMO。
減少全局宏的使用；
很多時候，過多的宏讓項目很不整潔，每一個開發(fā)者都往全局文件添加宏，而往往只是一段簡單的代碼，筆者認為開發(fā)中應該盡量少使用宏，原因如下：
宏在預編譯階段替換為實際代碼，存在效率問題
使用宏的地方可能只需要一塊內存，但是宏替換過后開辟了多個（這種情況應該用常量替換宏）
可能存在潛在的宏命名沖突
宏包裝過多的代碼難以理解和調試
代碼遷移時需要處理全局的宏
實際上，非得使用宏的地方并非那么多，比如需要定義一個全局的導航欄字體方便使用，可以將通用字體的配置參數作為一個模塊：
@interface HQGeneralFont : NSObject
/** 導航欄標題字體 */
+ (UIFont *)navigationBarTitleFont;
@end
或者用常量來代替宏：
.h
FOUNDATION_EXTERN NSString * const kNotify_xxx;
//xxx通知 key.m
NSString * const kNotify_xxx = @"kNotify_xxx";
這么做也便于轉換思維，畢竟 swift 中是沒有宏的。
去基類化設計；
代碼設計中，應該盡量避免基類的使用，也就是說，你不應該總是要求開發(fā)者去繼承你的基類來做功能。使用基類將造成不可避免的耦合，為業(yè)務的長期發(fā)展帶來阻礙（當然某些情況是可以使用基類的）。
其實使用基類就算了，若是將大量的業(yè)務邏輯放入基類中將是災難的開端。試想，當項目新成員一來就看見成千上萬行的基類代碼TA作何感想？
另外一種場景，當需要將項目中的某個模塊遷移到其他項目，或者需要將其他項目合并入當前項目，基類的合并將是一個非常頭疼的問題，它藕斷絲連的模塊和代碼會讓你抓狂。
那么，類的工具方法應該放哪兒？對所有類的統(tǒng)一配置應該放哪兒？對封裝模塊的個性化定制應該怎么做？
裝飾模式
類的工具方法，按道理說可以提取為模塊，但是有些場景可能顯得不夠簡潔。
其實只要留意 iOS 官方的 API，你就不難發(fā)現裝飾模式的大量應用，使用數個分類將大量的方法按照功能分類，會清晰且優(yōu)雅：
@interface UIViewController (HQGeneral)
/** 基礎配置 */
- (void)HQGeneral_baseConfig;
@end
@interface UIViewController (HQGeneralBackItem)
/** 配置通用系統(tǒng)導航欄返回按鈕 */
- (void)HQGeneral_configBackItem;
/** 重寫該方法以自定義系統(tǒng)導航欄返回按鈕點擊事件 */
- (void)HQGeneral_clickBackItem:(UIBarButtonItem *)item;
@end
不過要注意的時，定義分類的時候一定要加一個前綴標識以避免方法覆蓋。
AOP
面向切面編程在 iOS 領域經典的應用就是利用 Runtime 去 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];
}
代碼中統(tǒng)一配置了 UIViewController 的系統(tǒng)導航欄返回按鈕，注意這里調用的業(yè)務配置方法都是定義在 UIViewController 的分類里面的。若有某些導航欄需要格外配置返回按鈕的需求，可以拓展一個屬性來控制。
面向協議設計模式
對于一些封裝的組件，多考慮使用協議來個性化定制，繼承作為最差方案，而非是選方案。
定義一個遵守組件定制協議的屬性是常用的解決方法：
@property (nonatomic, strong) id<someprotocol> strategy;</someprotocol>
不同的屬性作為不同的策略，組件內部通過調用對應的協議方法實現個性化定制。而當使用者想要改變策略時，只需要更改這個屬性就行了。面向協議設計模式結合策略模式是一個很好的實踐。
MVC？MVP？MVVM？VIPER？；
業(yè)務具體的架構模式是個讓很多開發(fā)者頭疼的問題，因為有時候能讓復雜業(yè)務更清晰，有時候卻因為膠水代碼過多而臃腫。
實際上為什么要嚴格的遵守架構模式呢？為什么每一個業(yè)務模塊的架構模式都要一模一樣呢？
筆者認為正確的架構思路一定是根據業(yè)務來的，不同的模塊，不同的業(yè)務線完全可以有不同的架構，只需要架構足夠清晰不至于晦澀。
大致設計了一下架構的主旋律：
DataCenter 負責數據的獲取、處理、緩存等。
Model 設計為“瘦” Model，便于復用和遷移；也考慮到數據源可能數量龐大，若 Model 設計得過于“胖”，會造成更多的內存占用。
View 負責數據的展示，可以根據業(yè)務情況權衡是否需要 ViewModel 處理界面邏輯。
ViewController 作為 DataCenter 和 View 的橋梁。
筆者設計的項目目前不會很復雜，多數情況上面的架構就已經夠用，若某個頁面功能過多，完全可以提取一些額外的模塊，比如 DataCenter 處理過于復雜，那就把數據的處理和緩存提取出來：xxxDataProcesser、xxxDataCache。這些都是靈活的，只需要按照模塊化的思維提取，ViewController 的代碼相信也不會太多。
關于響應式框架
Reactivecocoa 雖然強大，筆者以前也用過，不過它是一個重量級框架，學習成本有點高，可能會因為團隊成員對其了解不足導致難以定位的錯誤。
而美團的 EasyReact 似乎是一個福音，筆者大概瀏覽了一下源碼，質量確實很高，對性能方面的處理很精致，基于圖論算法的處理也感覺很棒，項目侵入性也很小。不過缺點就是太新了，需要開發(fā)社區(qū)一定時間的驗證，暫時筆者持觀望態(tài)度。
當前名稱：iOS 響應式架構設計方案
轉載來源：http://www.bm7419.com/news39/131239.html
成都網站建設公司_創(chuàng)新互聯，為您提供標簽優(yōu)化、靜態(tài)網站、品牌網站設計、網站建設、商城網站、定制網站
聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯
猜你還喜歡下面的內容
- 網站空間影響網站成敗! 2021-10-14
- 搜到網為企業(yè)重新定義營銷模式 2021-10-14
- 如何阻止網站外鏈消失的技巧 2021-10-14
- 每個網站都該有個監(jiān)測服務 2021-10-14
- 關鍵詞排名提升的2個技巧 2021-10-14
- 建設網站讓客戶搜索到的秘訣主要在于內容 2021-10-14
- 如何理解綠蘿2.0軟文要注重原創(chuàng)和質量 2021-10-14
- 營銷網站有流量的沒有訂單的原因 2021-10-14
- 大型網站優(yōu)化策略 2021-10-14
- 建設企業(yè)網站一定要注意細節(jié)才能使網站起作用 2021-10-14
- 百度搜索引擎基礎知識 2021-10-14
- 網頁設計制作流程是什么樣的 2021-10-14
- 從用戶體驗向SEO思考 2021-10-14
- 網站制作常用的數據庫有哪些 2021-10-14
- 怎么刪除網絡營銷負面信息 2021-10-14
- 蜘蛛爬行不順暢清理網站陷阱是關鍵 2021-10-14
- 專業(yè)企業(yè)網站是怎樣開發(fā)的？ 2021-10-14
- 網站流量的三個途徑 2021-10-14
- Web項目安全性審核以及管理安全隱患 2021-10-14