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

使用openURL進行組件的注冊和調(diào)用

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

方案分析

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

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

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

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

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

URL 注冊對于實施組件化方案是不必要的，且通過 URL 注冊的方式形成的組件化方案，拓展性和可維護性都會被打折。

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

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

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

調(diào)用方式

先說本地應用調(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 實例以及對應的 action 選擇子，然后最終調(diào)用到目標業(yè)務提供的邏輯，完成需求。

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

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

最新評論