乐趣区

关于ios:iOS-组件化构思

一、iOS 组件化罕用形式探讨

应用 openURL 进行组件的注册和调用

  1. App 启动时实例化各组件模块,而后这些组件向 ModuleManager 注册 URL,有些时候不须要实例化,应用 class 注册。
  2. 当组件 A 须要调用组件 B 时,向 ModuleManager 传递 URL,参数追随 URL 以 GET 形式传递,相似 openURL。而后由 ModuleManager 负责调度组件 B,最初实现工作。

    计划剖析

    第一步的问题,在组件化的过程中,注册 URL 并不是充沛必要条件,组件是不须要向组件管理器注册 Url 的。而且注册了 URL 之后,会造成不必要的内存常驻,如果只是注册 Class,内存常驻量就小一点,如果是注册实例,内存常驻量就大了。
    第二步。在 iOS 畛域里,肯定是组件化的中间件为 openURL 提供服务,而不是 openURL 形式为组件化提供服务。
    问题在于无奈表白非常规对象。
    如果是传递简单对象,如 UIImage,只能做如下表白

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

    如果不像下面这么做,简单参数和非常规参数就无奈传递。如果这么做了,那么事实上这就是拆分近程调用和本地调用的入口了。
    URL 注册对于施行组件化计划是不必要的,且通过 URL 注册的形式造成的组件化计划,拓展性和可维护性都会被打折。
    注册 URL 的目标其实是一个服务发现的过程,在 iOS 畛域中,服务发现的形式是不须要通过被动注册的,应用 runtime 就能够了。另外,注册局部的代码的保护是一个绝对麻烦的事件,每一次反对新调用时,都要去保护一次注册列表。如果有调用被弃用了,是常常会遗记删我的项目的。runtime 因为不存在注册过程,那就也不会产生保护的操作,保护老本就升高了。

二、对组件化的构思


以上形式次要是基于 Mediator 模式和 Target-Action 模式,两头采纳了 Runtime 来实现调用。这套组件化计划将近程利用调用和本地利用调用做了拆分,而且是由本地利用调用为近程利用调用提供服务,与罕用计划正好相同。

调用形式

先说本地利用调用,本地组件 A 在某处调用
[[Mediator sharedInstance] performTarget:targetName action:actionName params:@{…}]
向 Mediator 发动跨组件调用,Mediator 依据取得的 target 和 action 信息,通过 Objective-C 的 runtime 转化生成 target 实例以及对应的 action 抉择子,而后最终调用到指标业务提供的逻辑,实现需要。

在近程利用调用中,近程利用通过 openURL 的形式,由 iOS 零碎依据 info.plist 里的 scheme 配置找到能够响应 URL 的利用,利用通过 AppDelegate 接管到 URL 之后,调用 Mediator 的 openUrl: 办法将接管到的 URL 信息传入。当然,Mediator 也能够用 openUrl:options: 的形式顺便把随之而来的 option 也接管,这取决于你本地业务执行逻辑时的充要条件是否蕴含 option 数据。传入 URL 之后,Mediator 通过解析 URL,将申请路由到对应的 target 和 action,随后的过程就变成了下面说过的本地利用调用的过程了,最终实现响应。

以上是针对 iOS 组件化的初步构思,对于更多具体内容后续会持续剖析。

退出移动版