iOS组件化实践(一)：简介
前言
iOS的组件化这块在去年3月起就有很多大神们讨论过，不过由于之前我们的项目结构比较简单，再加上用的swift做的开发，也没有去尝试做这块。直到前段时间公司准备用OC重构项目以符合新需求，于是于组内的小伙伴们研究了一下新项目的架构选型，经过一番讨论，决定使用组件化的架构。大约2周过后，组件化基本完成，决定写篇博客记录下我们组件化的过程，给想对项目做组件化的同学们做一个参考。
一、什么是组件化
想要做组件化的前提当然得知道什么是组件化。顾名思义，组件化就是将APP拆分成各个组件（或者说模块也行），同时解除这些模块之间的耦合，然后通过主工程将项目所需要的组件组合起来。这样组件化过后的项目就变成了很多小模块，如果新项目中有类似的需求，直接将模块引入稍作修改就能使用了。
这种设计是不是很像引入三方库做快速开发？其实制作组件的过程就相当于做二方库。因此常见的组件化方案大多都是使用cocoapods做依赖管理。
二、组件化的优缺点
组件化的优点：
- 组件可独立运行，提高的代码的复用性，组件化的颗粒度越细，可复用度就越高。
- 当组件库的数量足够庞大时，项目只需要组合组件即可完成大部分的开发工作。
- 组件化后项目的代码结构更加清晰，追踪问题、修复bug、增加需求更方便
- 不同业务组件相互独立，明确团队开发的业务边界，增加团队协作效率
组件化的缺点：
- 增加开发人员的学习成本
- 增加了代码的冗余，组件化颗粒度越细，中间代码越多
- 增加了项目的复杂度，复杂度越高越容易出问题
总体上组件化对于项目的开发来说是利大于弊的，当然如果你的项目非常简单的话就没必要做这些了。
三、常见的组件化中间件方案的选择
项目在做组件化时必然要对各个组件之间做解耦。因为如果组件之间的耦合没有被剔除，想要使用某个组件的话就有可能会引用与所需业务无关的其他组件，这也就是casatwy大神常说的拔萝卜带出泥。但是耦合这东西本身就是天然存在的，没有耦合、没有依赖本来就无法形成一个项目，我们能做到的只有尽量避免不必要的耦合带来的麻烦。
想要达到每个组件之间相对低耦合，比较常用的方案就是断掉横向依赖，使用中间人模式将依赖下沉至中间件。想想cocoapods是不是也类似这种模式？通过pod统一管理所有的三方库，然后项目持有Pod这个Target就可以使用所有的三方库了。
组件化之前的项目依赖关系
组件化之后的项目依赖关系
当然这种模式也有缺点，太过于集中、随着组件的增加，这个中间件会越来越臃肿，最后变成中间件自身难以维护的情况。不过iOS项目中很少出现非常庞大的架构，一般来说不会造成瓶颈。另外，在这种组件化的中间件中，有一个非常重要的特性，那就是必须实现组件对中间件的单向依赖。原因引用casatwy大神的一句话:
中间件对组件产生了依赖的话，其他模块也需要耦合中间层才能发起调用。这样还是存在之前的相互耦合的问题，而且本质上比之前更麻烦了。
只有单向依赖的组件化之后的项目依赖关系
对于中间件的设计方案，目前国内讨论比较火热的就两种。一是蘑菇街limboy大神的URLRoute+Procotol，另一种则是casatwy大神的Target-Action。我对这两种方案的归纳如下：
相同点：
- 这两种中间件方案都实现了组件对中间件单向依赖
- 结构基本一致，都将业务分成了
调用方、中间件和服务方
不同点:
服务方响应调用方的实现方式不同
URLRoute+Procotol：
- 需要注册组件，通过注册组件使得服务方可以被中间件发现
- 调用方通过
URL调用服务方页面，URL和服务方页面的关系通过路由表映射，路由表需要人工维护(硬编码)，使用持续集成环境简化操作 - 调用方通过
Procotol调用非页面类服务组件，可以传递复杂对象
Target-Action：
- 不需要注册组件，通过runtime+约定命名规范(硬编码)的方式查找服务方
- 区分本地调用和远程调用，本地调用通过
Target-Action获取服务，同时为远程调用提供服务，远程调用的规则需约定好 - 参数传递统一用Dictionary实现，获取Dictionary内所需要的内容需要通过文档或者其他说明
- 通过category的形式拆分中间件的代码，使其分属不同组件
这两种方式谁优谁劣不好直接做判断，综合来看URLRoute+Procotol更适用于页面跳转这种业务较多的场景，同时配合持续集成环境，动态性更好(通过文本信息配置代替代码)，缺点是调用关系复杂，中间层比较庞大，需要配合持续集成环境才能有比较好的使用体验；Target-Action则更适合业务较杂的情况，核心代码很少，调用关系相对简单，缺点是硬编码场景较多，不过硬编码基本都在中间件里。
由于URLRoute+Procotol更适合有完整系统支持的场景，因此我们采用了Target-Action。该模式的特点也被充分验证：中间层代码量少、对项目的侵入性低，因此很快我们就完整组件化的工作了。
下一篇将介绍我们组件化的具体过程，以及需要做的准备工作。
