大家好,欢迎来到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