ios组件化探讨

组件化的流程

随着公司业务的不断发展，应用的代码体积将会越来越大，业务代码耦合也越来越多，代码量也是急剧增加。如果仅仅完成代码拆分还不足以解决业务之间的代码耦合，而组件化是一种能够解决代码耦合、业务工程能够独立运行的技术。在实施组件化之前首先要意识到，并不是所有项目都适合组件化。首先刚起步的项目可能模块不是十分清晰，上来就实施模块化方案，很有可能对后期代码维护或功能扩展带来很多不便之处；其次，模块化更适合大型项目且是多人开发，如果项目比较小且开发者较少，使用组件化可能只会带来更大的工作量。

1. 使用 pod 管理公共库和UI组件
   封装公共库和项目中的UI组件库，然后制作成私有化仓库，通过 pod 在实际项目中使用。另外针对一些第三方库，要在第三库的基础上再做一层封装，这样后期可以更方便的替换这些第三方库。
2. 拆分业务模块
   对一些独立的模块进行拆分，如登录模块、购物车模块、清单模块、商品详情模块等。实际拆分的过程中需要注意，模块的颗粒度既不能太大，也不能太小。
3. 实施组件化方案
   抽出公共库和UI组件以及拆分完业务模块之后，接下来就是实施组件化方案。

url-block方案

url-block方案具有非常明显的几个缺点：

1. 组件本身和调用者都依赖了Mediator，耦合度较大。
2. 内存里需要保存一份url-block映射表，增加了额外的内存。
3. 非常规对象在组件间无法进行参数传递，因为实际参数传递通过URL传递，只能传递常规的字符串参数，无法传递类似UIImage、NSData等类型。
4. 没有拆分远程调用和本地间调用，本地调用和远程调用不应该公用同一个接口，不应该以远程调用的方式为本地间调用提供服务。远程App调用处理入参的过程比本地多了一个URL解析的过程，这是远程App调用特有的过程。而本地完全可以避免引入URL解析这一步骤，直接调用。

protocol-class 方案

这种方案实际上同url-block方案非常类似，同样需要中间件维护一个映射表/字典，该映射表/字典主要用来维护protocol和class的关系。该方案主要解决了url-block方案中的非常规参数不能传递的问题，但是对于组件依赖中间件、内存中维护映射表等问题依然没有给与解答

target-action方案

总的来说该方案是先封装一个中间层，其中中间件分别提供了本地调用和远程调用接口。对于组件而言，每个组件会包装一层。当需要调用组件的时候，就会通过中间层调用各个组件的包装层，比较特别的地方是中间层通过runtime调用组件的包装层，做到真正意义上的解耦，这也是该方案的核心之处.

如果想使用组件，调用者只需要依赖中间层即可，而中间层通过target-action模式无需依赖组件，所以达到解耦的目的。
中间层CTMediator将远程调用和本地组件间调用拆开处理。之所以这样做，主要因为远程App调用处理入参的过程比本地多了一个URL解析的过程，这是远程App调用特有的过程，而本地调用无需URL解析。
该方案中采用了去model化传递参数，在iOS的开发中，就是以字典的方式去传递参数。如果组件间调用不对参数做去model化的设计，就会导致业务形式上被组件化了，实质上依然没有被独立。既然是使用了字典作为参数传递，自然而然就引起了hardcode问题。为了让调用更方便知道接收方需要哪些key的参数以及哪些target可以被调用，该方案进一步就针对每一模块采用了category的方式，从而缩小了范围，方便代码定位和阅读。这也是我们app最终选择此方案进行组件化选型的真正意义。