一、iOS 組件化常用方式討論

使用openURL進(jìn)行組件的注冊(cè)和調(diào)用

App 啟動(dòng)時(shí)實(shí)例化各組件模塊，然后這些組件向 ModuleManager 注冊(cè) URL ，有些時(shí)候不需要實(shí)例化，使用 class 注冊(cè)。
當(dāng)組件A需要調(diào)用組件B時(shí)，向 ModuleManager 傳遞 URL ，參數(shù)跟隨 URL 以 GET 方式傳遞，類似openURL 。然后由 ModuleManager 負(fù)責(zé)調(diào)度組件B，最后完成任務(wù)。

方案分析

第一步的問題，在組件化的過程中，注冊(cè) URL 并不是充分必要條件，組件是不需要向組件管理器注冊(cè)Url的。而且注冊(cè)了 URL 之后，會(huì)造成不必要的內(nèi)存常駐，如果只是注冊(cè)Class，內(nèi)存常駐量就小一點(diǎn)，如果是注冊(cè)實(shí)例，內(nèi)存常駐量就大了。

第二步。在 iOS 領(lǐng)域里，一定是組件化的中間件為 openURL 提供服務(wù)，而不是 openURL 方式為組件化提供服務(wù)。

問題在于無法表達(dá)非常規(guī)對(duì)象。
如果是傳遞復(fù)雜對(duì)象，如 UIImage ，只能做如下表達(dá)

[a openUrl:@"http://baidu.com/detail" 
    params:@{
        @"id":"abc123",
        @"type":"1",
        @"image":[UIImage imageNamed:@"iOSImage"]}
]

如果不像上面這么做，復(fù)雜參數(shù)和非常規(guī)參數(shù)就無法傳遞。如果這么做了，那么事實(shí)上這就是拆分遠(yuǎn)程調(diào)用和本地調(diào)用的入口了。

URL 注冊(cè)對(duì)于實(shí)施組件化方案是不必要的，且通過 URL 注冊(cè)的方式形成的組件化方案，拓展性和可維護(hù)性都會(huì)被打折。

注冊(cè) URL 的目的其實(shí)是一個(gè)服務(wù)發(fā)現(xiàn)的過程，在 iOS 領(lǐng)域中，服務(wù)發(fā)現(xiàn)的方式是不需要通過主動(dòng)注冊(cè)的，使用 runtime 就可以了。另外，注冊(cè)部分的代碼的維護(hù)是一個(gè)相對(duì)麻煩的事情，每一次支持新調(diào)用時(shí)，都要去維護(hù)一次注冊(cè)列表。如果有調(diào)用被棄用了，是經(jīng)常會(huì)忘記刪項(xiàng)目的。runtime 由于不存在注冊(cè)過程，那就也不會(huì)產(chǎn)生維護(hù)的操作，維護(hù)成本就降低了。

二、對(duì)組件化的構(gòu)思

以上方式主要是基于 Mediator 模式和 Target-Action 模式，中間采用了 Runtime 來完成調(diào)用。這套組件化方案將遠(yuǎn)程應(yīng)用調(diào)用和本地應(yīng)用調(diào)用做了拆分，而且是由本地應(yīng)用調(diào)用為遠(yuǎn)程應(yīng)用調(diào)用提供服務(wù)，與常用方案正好相反。

調(diào)用方式

先說本地應(yīng)用調(diào)用，本地組件A在某處調(diào)用

[[Mediator sharedInstance] performTarget:targetName action:actionName params:@{…}]

向 Mediator 發(fā)起跨組件調(diào)用，Mediator 根據(jù)獲得的 target 和 action 信息，通過 Objective-C 的 runtime 轉(zhuǎn)化生成 target 實(shí)例以及對(duì)應(yīng)的 action 選擇子，然后最終調(diào)用到目標(biāo)業(yè)務(wù)提供的邏輯，完成需求。

在遠(yuǎn)程應(yīng)用調(diào)用中，遠(yuǎn)程應(yīng)用通過 openURL 的方式，由iOS系統(tǒng)根據(jù) info.plist 里的 scheme 配置找到可以響應(yīng) URL 的應(yīng)用，應(yīng)用通過 AppDelegate 接收到URL之后，調(diào)用 Mediator 的 openUrl: 方法將接收到的URL信息傳入。當(dāng)然， Mediator 也可以用 openUrl:options: 的方式順便把隨之而來的option 也接收，這取決于你本地業(yè)務(wù)執(zhí)行邏輯時(shí)的充要條件是否包含 option 數(shù)據(jù)。傳入 URL 之后，Mediator 通過解析 URL ，將請(qǐng)求路由到對(duì)應(yīng)的 target 和 action ，隨后的過程就變成了上面說過的本地應(yīng)用調(diào)用的過程了，最終完成響應(yīng)。

以上就是iOS 組件化初步構(gòu)思的詳細(xì)內(nèi)容，更多關(guān)于ios組件化常用方式的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章。也希望大家可以多多關(guān)注腳本之家，后續(xù)我們將帶來更精彩的更新！

最新評(píng)論