iOS組件化源碼分析

這篇“iOS組件化源碼分析”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“iOS組件化源碼分析”文章吧。

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

使用openURL進行組件的注冊和調用

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

方案分析

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

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

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

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

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

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

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

二、對組件化的構思

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

調用方式

先說本地應用調用，本地組件A在某處調用

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

向 Mediator 發(fā)起跨組件調用，Mediator 根據獲得的 target 和 action 信息，通過 Objective-C 的 runtime 轉化生成 target 實例以及對應的 action 選擇子，然后最終調用到目標業(yè)務提供的邏輯，完成需求。

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

以上就是關于“iOS組件化源碼分析”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業(yè)資訊頻道。