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