html6sh@vip.163.com
QQ:3272893092
分享數：2 iOS 響應式架構設計方案
1.響應式編程是一種和事件流有關的編程模式，關注導致狀態值改變的行為事件，一系列事件組成了事件流。
2.一系列事件是導致屬性值發生變化的原因。FRP非常類似于設計模式里的觀察者模式。
3.FRP與普通的函數式編程相似，但是每個函數可以接收一個輸入值的流，如果其中，一個新的輸入值到達的話，這個函數將根據最新的輸入值重新計算，并且產生一個新的輸出。這是一種”數據流”編程模式。
1，開發過程中，狀態以及狀態之間依賴過多,RAC更加有效率地處理事件流，而無需顯式去管理狀態。在OO或者過程式編程中，狀態變化是最難跟蹤，最頭痛的事。這個也是最重要的一點。
2， 減少變量的使用，由于它跟蹤狀態和值的變化，因此不需要再申明變量不斷地觀察狀態和更新值。
3， 提供統一的消息傳遞機制，將oc中的通知，action，KVO以及其它所有UIControl事件的變化都進行監控，當變化發生時，就會傳遞事件和值。
4， 當值隨著事件變換時，可以使用map，filter，reduce等函數便利地對值進行變換操作。
設計一個簡單的 iOS 響應式架構。iOS 架構 DEMO
關于組件化；
組件化似乎是項目發展壯大過后必然要做的事情，它能讓各個業務線的工程師不需要過多的關注其他業務線的代碼，有效的提高團隊整體效率。然而實施組件化的時機是在需求相對穩定、產品閉環形成過后。所以本文不會應用組件化，但是這里簡單談談業界的組件化方案。
組件化的核心問題就是組件間如何通訊。“軟件工程的一切問題都能通過一個間接的中間層解決。”中介模式很自然的運用起來：
這樣雖然能統一組件間的通訊請求，但是卻沒有避免 Mediator 和目標組件的耦合，ModuleA 工程中仍然需要導入 ModuleB
所以重點問題落在了解耦上：
要達到 Mediator 和目標組件的解耦，就需要實現它們之間的間接調用（圖中虛線），既然是間接調用，必然需要一種映射機制。在 iOS 開發中，業界大概有三種方式來處理。
(1) 使用 URL -> Block 解耦
簡單來說就是將組件的調用代碼放入 block 中，然后 URL 作為 key，block 作為 value，存入一個全局的 hash 容器，組件通過一個 URL （比如 “native/id=10/type=1” ）向 Mediator 發起請求，Mediator 找到對應的代碼塊執行。由此，解開了 Mediator 和目標組件的耦合（見博客：蘑菇街 App 的組件化之路）。
這種方案的缺陷很多：組件越多常駐內存越多；解析 URL 邏輯復雜；URL 無法表述具體語言相關的對象類型。所以這種方式并不適合組件化解耦。
(2) 使用 Protocol 解耦
阿里的 BeeHive 是該方案的很好實踐，筆者閱讀了一下源碼，它的大致工作原理如下：注冊 Protocol 對應的組件，這個和上面說的 URL->Block 方式如出一轍，只不過這里是 Protocol-> Module ；組件申請訪問時導入對應的 Protocol 通過 Mediator 獲取到對應的組件對象。由于協議的表述能支持所有的對象類型，所以這種方式能基本解決組件間通信的需求。
BeeHive 注冊組件有幾種方式，一種是監聽了動態鏈接時 image 二進制文件加載完成的回調，通過修改代碼段的方式判斷對應的模塊進行注冊；第二種是在 +load 方法里面注冊；第三種是異步注冊，但是這種方式存在一個問題，可能組件使用方準備使用組件的時候，這個組件還未注冊成功。
BeeHive 還為組件設置了優先級的概念，它通過數組來保持優先級排序，在源碼中能看到一些數組排序的邏輯，這就帶來了相當多的高時間復雜度的運算。
所以，組件數量過多的話，會延長動態鏈接庫的過程。
BeeHive 為了讓每一個組件享有獨自的 app 生命周期、3D touch 等功能，會將這些系統級的事件發送給每一個組件，且不談大量的方法調用損耗，它必須讓入口文件 AppDelegate 繼承自 BeeHive 的 BHAppDelegate，筆者感覺侵入性過強，并且當開發者需要復寫 AppDelegate 方法的時候，還要注意讓super調用一下，可以說很不優雅了。
在基于協議的組件化方案中，組件使用方能直接拿到目標組件的實例，那么使用者可能對該實例進行修改，這可能會帶來安全問題。
(3) 使用 Target-Action 解耦
Casa Taloyum 前輩的 iOS應用架構談 組件化方案 為此做出了最佳實踐。
Mediator 使用 Target-Action 來間接的調用目標組件，無需專門注冊。組件維護者需要做一個 Mediator 的分類，通過硬編碼調用目標組件，然后組件使用者只需要依賴這個分類就行了。封裝的 Mediator 源碼只有簡單的 200+ 行代碼，并且很易懂。這也讓開發者能對組件化的實施更加有信心，不會因為基礎設施的錯誤而束手無策。
小總結
關于以上組件化的簡單表述僅代表筆者的個人見解，由于筆者并沒有真正的實施組件化，所以理解可能有誤。
雖然筆者設計的 iOS 架構不會應用組件化，但是這給我們的架構設計帶來了前瞻性的引導，這非常重要。
模塊化思維劃分文件；
在團隊開發中，項目發展到后期總是會出現某些文件或代碼難以管理，出現這種情況的主要原因通常是項目開發過程中對文件的管理過于隨意。
開發者應該盡量將所有代碼文件歸于模塊，而不要出現模擬兩可的文件。而筆者這里說的模塊，是有具體意義的模塊，比如圖片處理模塊、字體處理模塊，而不是諸如 Public、Common 等無具體意義的代碼文件。
試想，在多人開發中，當所有人都覺得有些代碼不知道怎么歸類的時候，就會往 Public 里面扔。當你某天想要整理一下這個 Public，會發現已經無從下手；或者當你需要遷移項目中的某個業務模塊時，會附帶遷移一些模塊，當這個模塊是有意義的（比如圖片處理模塊），你的遷移成本會非常低，但是當這個藕斷絲連的模塊是 Public 時，時間成本可能高于你的想象，估計你會將它完整的拷貝過去，而又對新項目造成了污染。
全局的公共文件是產生垃圾代碼的源頭。筆者認為幾乎所有的代碼都是可以歸類為模塊的。
大致梳理了一個文件分類，當然這個分類是靈活的，只是要分模塊劃分：
- GeneralModules 放項目獨有的通用配置模塊（比如通用顏色模塊、通用字體模塊）
- ToolModules 放工具類模塊（比如系統信息模塊）
- PackageModules 放基于業務的一些封裝（比如提示框模塊、加載菊花模塊）
- BusinessModules 放業務模塊（比如購物車、個人中心）
具體里面放了些什么，可以查看筆者的 DEMO。
減少全局宏的使用；
很多時候，過多的宏讓項目很不整潔，每一個開發者都往全局文件添加宏，而往往只是一段簡單的代碼，筆者認為開發中應該盡量少使用宏，原因如下：
宏在預編譯階段替換為實際代碼，存在效率問題
使用宏的地方可能只需要一塊內存，但是宏替換過后開辟了多個（這種情況應該用常量替換宏）
可能存在潛在的宏命名沖突
宏包裝過多的代碼難以理解和調試
代碼遷移時需要處理全局的宏
實際上，非得使用宏的地方并非那么多，比如需要定義一個全局的導航欄字體方便使用，可以將通用字體的配置參數作為一個模塊：
@interface HQGeneralFont : NSObject
/** 導航欄標題字體 */
+ (UIFont *)navigationBarTitleFont;
@end
或者用常量來代替宏：
.h
FOUNDATION_EXTERN NSString * const kNotify_xxx;
//xxx通知 key.m
NSString * const kNotify_xxx = @"kNotify_xxx";
這么做也便于轉換思維，畢竟 swift 中是沒有宏的。
如沒特殊注明，文章均為江浙滬網絡推廣,轉載請注明來自http://www.0898bike.com/html/news/
返回列表
- 下一篇： 專業網站建設的網站靜態化處理方法
- 上一篇： 手機APP開發框架的選擇
志強網絡擁有資深設計師團隊和自主系統開發技術團隊，為客戶專業定制企業品牌網站、響應式網站、商城系統、手機微信網站、外貿網站、營銷型網站、旅游網站、微信小程序、APP等。歡迎廣大客戶咨詢！
