组件化开发越来越成为了公司项目开发的主流，随着公司业务的不断发展，项目功能的堆叠，各个业务代码耦合会越来越严重，给后续的开发、维护以及项目稳定性、快速迭代都带来了很多问题；组件化是一种能够解决代码耦合的技术，项目经过组件化的拆分，不紧可以解决代码耦合的问题，还可以增加代码的复用等等（个人认为移动端的组件化其实和服务端spring_clould的微服务一个道理）
结合经验以及各个大牛有关组件化的文章，iOS组件化主流方案有三种：url-block, protocol-class, target-action
一：url-block
最早看到url-block这种方式是关于蘑菇街组件化方案，也是在实际项目经验中最先使用的解耦的方式；
主要通过在启动时注册组建间提供的服务，建立url和block的对应关系（调用方使用url，找到对应组件方提供服务的block，获取组件对外提供的服务）
url-block
这种方式在从已有项目中进行组件拆分效果比较好，最大的优势体现在解耦方面，使用此方案可以迅速对已有业务进行拆分。但是实际在使用过程中会比较大的弊端。比如：
1、需要维护url-block的表(如果url书写错误那么组件会不起作用)
2、参数传递方面的限制会比较大，通过url带参的方式，一些特殊类型没法传递(NSData、UIImage等等)
3、需要一个Router的配合，组件越多Router会越复杂，耦合较多
二：protocol-class
此方案是在url-block的方式上进行了优化，通过protocol和class做一个映射；
protocol-class
不同点主要体现在两个方面
1、使用protocol取代url，通过protocol定义服务接口(可以理解为对外提供服务的API)，然后组件围绕protocol进行设计开发，从而对外提供服务
2、解决了url-block中无法传递非常规参数的问题
弊端：
1、未根本解决依赖问题，还是需要维护映射关系
2、组件多之后，中间件会越来越复杂，导致一些不需要的服务也会因为protocol的原因需要引入到中间件
三：target-action
这种方案是目前使用最多且耦合性最小的方案，通过给组件封装一层来对外提供服务，调用者通过依赖中间件来使用服务；其中中间件是利用runtime机制来调用组件的服务，实现了真正意义上的解耦(基于CTMediator 可参考：CTMediator)
具体实施过程是给组件封装一层target来对外提供服务，不会对原来组件造成入侵；通过实现中间件的Category来提供服务给宿主，宿主只需要依赖中间件，而组件则不需要依赖中间件。（具体步骤可参考我之前写的关于CTMediator实施步骤 CTMediator使用），宿主APP方法的调用则分为本地调用和远程调用，通过远程调用来实现对组件服务的调用
target-action
弊端：
1、代码量会比较大，在对外提供服务的基础上需要增加一个category与之对应
2、对于一些model的使用，基于通用性以及高内聚的原则，最好使用NSDictionary的方式去model化，所以这块的维护是一个比较大的工作量，随着业务的修改，改变不可避免
网友评论