本文主要讲解组件化的两种方案
组件化
组件化其实就是将模块单独抽离、分层，并指定模块间的通讯方式，从而实现解耦的一种方式，主要运用与团队开发
为什么需要组件化？
主要有以下四个原因
- 1、模块间解耦
- 2、模块重用
- 3、提高团队协作开发效率
- 4、单元测试
当项目因为各种需求，越来越来时，如果此时的各个模块之间是互相调用，即你中有我，我中有你这种情况时，会造成高耦合的情况。一旦我们需要对某一块代码进行修改时，就会牵一发而动全身，导致项目难以维护
其问题主要体现在以下几个方面：
- 1、修改某个功能时，同时需要修改其他模块的代码，因为在其他模块中有该模块的引用。可以理解为
高耦合导致代码修改困难 - 2、模块对外接口不明确，甚至暴露了本不该暴露的私有接口，修改时费时费力。可以理解为
接口不固定导致的接口混乱 - 3、高耦合代码产生的后果就是会影响团队其他成员的开发，产生
代码冲突 - 4、当模块需要重用到其他项目时，
难以单独抽离 - 5、模块间耦合的忌口导致接口和依赖关系混乱，
无法进行单元测试
所以为了解决以上问题，我们需要采用更规范的方式来降低模块间的耦合度，这就是组件化，也可以理解为模块化
但是，这里还需要说明一点，因为组件化也是需要一定成本的，需要花费时间设计接口、分离代码等，所以并不是所有的项目都需要组件化。如果你的项目有以下这些特征就不需要组件化：
- 1、项目较小，模块间交互简单，耦合少
- 2、项目没有被多个外部模块引用，只是一个单独的小模块
- 3、模块不需要重用，代码也很少被修改
- 4、团队规模很小
- 5、不需要编写单元测试
如果你的有以下特性，说明你就必须要考虑进行组件化了：
- 1、模块逻辑复杂，多个模块之间频繁互相引用
- 2、项目规模逐渐变大，修改代码变的越来越困难（这里可以理解为：修改一处代码，需要同时修改其他多个地方）
- 3、团队人数变多，提交的代码经常和其他成员冲突
- 4、项目编译耗时较大
- 5、模块的单元测试经常由于其他模块的修改而失败
组件化方案
组件化方案的8条指标
一个项目经过组件化后如何来评判，主要有以下几个标准：
- 1、模块之间没有耦合，模块内部的修改不会应该其他模块
- 2、模块可以单独编译
- 3、模块间数据传递明确
- 4、模块可以随时被另一个提供了相同功能的模块替换
- 5、模块对外接口清晰且易维护
- 6、当模块接口改变时，此模块的外部代码能够被高效重构
- 7、尽量用最少的修改和代码，让现有的项目实现模块化
- 8、支持OC和Swift，以及混编
前4条主要用于衡量一个模块是否真正解耦，后4条主要用于衡量在项目中实践中的易用程度
组件化原则
一个项目主要分为3层：业务层、通用层以及基础层，在进行组件化时，有以下几点说明
- 只能上层对下层依赖，不能下层对上层的依赖，因为下层是对上层的抽象
- 项目公共代码资源下沉
- 横向的依赖尽量少有，最好下层至通用模块，或者基础模块
组件化方案
常用的组件化方案主要有两种：
本地组件化：主要是通过在工程中创建library，利用cocoapods的workspec进行本地管理，不需要将项目上传git，而是直接在本项目中以framework的方法进行调用cocoapods组件化：主要是利用cocoapods来进行模块的远程管理，需要将项目上传git（需要注意：这里的组件化模块分为公有库和私有库，对公司而言，一般是私有库）
本地组件化
1、创建主工程
- 首先创建一个工程
- 集成cocopods，进行本地管理：
$ cd 项目目录
$ pod init
复制代码- 编辑podfile，并执行
pod install
2、创建组件
假设有以下几个模块：
主工程：承载主要的表层业务代码Core：独立存在，应用加密、接口请求等敏感代码Base：基类封装，拓展，基本的数据处理Service：服务层，封装业务工具类，例如网络层服务、持久化服务等Pods：三方依赖
其中，各个模块间的关系如下所示
下面，我们来进行模块的创建，以Core模块为例：
- 选择
new -> project -> iOS -> Framework，新建一个模块