«

iOS组件化源码分析

时间:2024-7-25 09:07     作者:韩俊     分类: 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 方式为组件化提供服务。

问题在于无法表达非常规对象。
如果是传递复杂对象,如 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

热门推荐