一、概念
将一个单一工程的项目，分解成各个独立的组件；
然后按照某种方式 任意组成一个拥有完整业务逻辑的工程
可以理解为下图所示
E9AE92823AAF075D980F8D66B6981697.png
每个组件都可以单独抽离出来独立运行
这就是组件的概念
二、组件化产生的原因
如果你的项目 业务模块比较多 而且同时有很多人开发 在开发过程中肯定会出现一些问题 比如
1、代码耦合度很高
//团队成员 方法相互引用
2、编译效率低速度慢
//因为工程模块比较多编译时每个模块都会参与
3、测试不独立
//你写的代码测出来问题 有可能不是你的问题 可能是其他开发人员的问题导致（测试环境复杂）
4、无法使用自己擅长的设计模式
//一个项目多人开发 如果所有代码都在一起 肯定会有一个统一的设计模式 不然项目会很乱
。。。。
反正就是 项目业务比较复杂时 多人开发会暴露出一系列的问题。
此时 如果每个人都负责编写一个独立的组件 就不会出现上述问题
三、组件化最终效果
1、组件独立
独立编写 ：可以使用自己擅长的方式别写代码
独立编译 ：速度快
独立运行 ：速度快
独立测试 ：定位问题快 省去重复测试
2、一次封装永久使用
如果你的其他项目中想要使用这个组件 直接引用即可
四、组件化实战考虑的问题
1、需要把哪些内容封装成一个组件
一般分为三种 基础组件、功能组件、业务组件
基础组件
1、基本配置：如常量/变量、宏定义
2、分类：系统各个类的分类
3、网络：如对AFN的封装、对SDWebImage的封装...
4、工具：如 日期处理工具、文件处理工具、设备信息获取工具...
...
功能组件
1、控件：如 轮播器、选项菜单、图文菜单、弹幕...
2、功能：如 断点续传、音频处理
...
业务组件
1、业务1
2、业务2
3、业务3
...
n、业务n
三者之间的关系
先看图
5894832B47D6ADE4C667E6221F9CD0CE.png
1、最上层肯定是业务组件 ，然后基础组件和功能组件同一级别
2、业务组件 可以依赖基础组件 也可以依赖 功能组件
3、业务组件之间最好不要相互依赖
原因是：降低业务组件之间的依赖 能够方便的抽离出 各个组件 来达到解耦的目的
4、基础组件和功能组件 最好也不要相互依赖
原因是：降低业务组件之间的依赖 能够方便的抽离出 各个组件 来达到解耦的目的
假设 功能组件 有一个小小的功能需要使用 基础组件 那么他就需要去依赖（引用） 基础组件
这样一搞 在编译的时候就会把基础组件的所有小的组件给引用到功能组件中
在编译的时候基础组件就会全部被编译
还有就是 功能组件依赖基础组件 将来再抽离功能组件的时候就无法单独把功能组件抽离出来
解决这个问题 就是把功能组件里需要的基础功能 从基础组件中拷贝一份过来，虽然这样麻烦了一些 但是能够达到解耦的效果。
2、每个组件以什么样的形式存在
1、组件内部根据个人喜好划分命名文件夹
2、每个组件都以pod库的形式存在
3、拥有单独的测试工程 每个组件可以单独测试
3、以怎样的形式集成各个组件
通过cocoapods来安转各个组件
4、组件之间如何通讯
1、披露公开API
2、利用中间件 传递
五、组件化过程中的解耦
1、如果一个组件中依赖其他公共功能 该如何处理
1、直接copy代码，虽然麻烦，但是他的好处就是快，无需产生依赖，
对于一些不重要的方法和工具也可以直接copy到内部使用
2、把组件依赖的代码 封装成一个pod库 然后依赖pod库
2、组件内部需要对接某个服务 该如何处理
如：图文菜单组件的封装 内部有图文加载
可以使用一个代理 或则block 把显示图片的代码丢出去 让外界来做处理
