ios 组件化方案对比

ios 组件化方案对比目前iOS组件化方案主要有三种;URL SchemeProtocol ClassTarget ActionURL Scheme 方案实现方式:在

大家好,欢迎来到IT知识分享网。

目前iOS组件化方案主要有三种;

  • URL Scheme
  • Protocol Class
  • Target Action

URL Scheme 方案

实现方式:

在启动时,注册组件提供的服务(注册URL以及关联服务Block),然后在使用时,通过URL直接调用(openURL);

  • 使用URL处理本地跳转逻辑
  • 注册组件,内存中维护URL注册服务

优点:

  • 统一了不同平台的客户端在跳转上的不一致
  • 处理网页跳转上较为方便

缺点:

  • url参数受限(例如非字符串类型,UIImage,XXModel,NSData等)
  • 业务分散,耦合多
  • 组件很多的情况下,可能会影响到内存

Protocol Class方案

实现方式:

通过Protocol定义服务接口,组件通过实现该接口来提供服务,最终的实现就是将Protocol和Class映射在一起,同时在内存中保存一张映射表,使用的时候,通过Protocol去获取Class对应的服务。

  • 增加 Protocol Wrapper(包装) 层
  • 中间件返回 Protocol 对应的 Class
  • 解决硬编码的问题

优点:

  • 协议接口规范,遵循依赖反转原则

缺点:

  • 缺少统一调度层,组件方法调用分散,难于集中管理(团队规模大,架构管控越重要)
  • 架构的灵活性不够高

Target Action方案

实现方式:

Target Action这个方案是基于ObjC 的runtime、category 特性动态获取模块,例如通过NSClassFromString 获取类并创建实例,通过 performSelector + NSInvocation动态调用方法。

首先每个模块需要配置Target和Category,其中Target是每个组件对应一个或者多个Target,Category是中间层Mediator的分类,使用分类的目的是为了让Mediator的业务代码分离,从而降低Mediator中的依赖和耦合性。
那么中间层Mediator是如何找到并调用组件的呢?这里正是利用了runtime的反射机制,在Category中找到对应Target以及调用Target对应的Action。

CTMediator正是采用的Target Action方案,巧妙的使用了cocoaTouch提供的反射机制,方法签名与命令模式,简单又完美的解决了组件间的解耦问题。

  • 抽离业务层逻辑
  • 提供由中间层调用逻辑
  • 中间层实现上使用Runtime反射

优点:

  • 解耦,只存在组件依赖中间层(单向依赖)
  • 利用 Category 可以明确声明的接口,进行编译检查
  • 统一处理了所有组件间调用入口,方便管理

缺点:

  • 每个组件的Category对应一个Target,Category中的Action对应Target中的Action。(此类的代码量很多)
  • 有硬编码的问题,各种定义的string

免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/84311.html

(0)

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

关注微信