什么组件化

组件化其实就是 将模块单独抽离、分层，并指定模块间的 通讯 方式，从而实现 解耦 的一种方式，主要运用与团队开发
组件化开发就是将一个臃肿的、单一的项目，根据 功能/业务/技术 等进行拆分，形成一个个独立的功能组件，然后借助 Cocoapods 管理工具将其任意组合，集成一个完整的项目。
你可以将 AFNetworking、SDWebImage、Bugly、MLeaksFinder 等三方库理解为工程的一部分，属于 基础组件模块，我们要做的就是将项目划分多个独立功能模块，再集成一个完整的项目。

为什么要组件化？

主要有以下四个原因

模块间解耦
模块重用
提高团队协作开发效率
单元测试

当项目因为各种需求，模块越来越多时，如果此时的各个模块之间是互相调用的，即 你中有我，我中有你 这种情况时，会造成 高耦合 的情况，一旦我们需要对某一模块代码进行 修改 时，就会 牵一发而动全身，导致项目难以维护

其问题主要体现在以下几个方面：

修改某个功能时，同时需要修改其他模块的代码，因为在其他模块中有该模块的引用，可以理解为 高耦合导致代码修改困难
模块对外接口不明确，甚至暴露了本不该暴露的私有接口，修改时费时费力。可以理解为 接口不固定导致的接口混乱
高耦合代码产生的后果就是会影响团队其他成员的开发，产生 代码冲突
当模块需要重用到其他项目时，难以单独抽离
模块间耦合的忌口导致接口和依赖关系混乱，无法进行单元测试

所以为了解决以上问题，我们需要采用更规范的方式来 降低模块 间的 耦合度，这就是 组件化，也可以理解为 模块化

但是，这里还需要说明一点，因为组件化也是需要一定成本的，需要花费时间设计接口、分离代码等，所以并不是所有的项目都需要组件化。如果你的项目有以下这些特征就 不需要组件化：

项目较小，模块间交互简单，耦合少
项目没有被多个外部模块引用，只是一个单独的小模块
模块不需要重用，代码也很少被修改
团队规模很小
不需要编写单元测试

如果你的有以下特性，说明你就必须要 考虑进行组件化 了：

模块逻辑复杂，多个模块之间频繁互相引用
项目规模逐渐变大，修改代码变的越来越困难（这里可以理解为：修改一处代码，需要同时修改其他多个地方）
团队人数变多，提交代码经常和其他成员冲突
项目编译耗时较大
模块的单元测试经常由于其他模块的修改而失败

组件化方案

组件化方案的8条指标：

一个项目经过组件化后如何来评判，主要有以下几个 标准：

模块之间没有耦合，模块内部的修改不会影响其他模块
模块可以单独编译
模块间数据传递明确
模块对外接口清晰且易维护
当模块接口改变时，此模块的外部代码能够被高效重构
尽量用最少的修改和代码，让现有项目实现模块化
支持OC和Swift，以及混编

前4条主要用于 衡量一个模块是否真正解耦，后4条主要用于衡量在项目中 实践中的易用程序

组件化原则

一个项目主要分为3层：业务层、通用层 以及 基础层，在进行组件化时，有以下几点说明

只能上层对下层依赖，不能下层对上层依赖，因为下层是对上层的抽象
项目公共代码资源下沉
横向的依赖尽量减少，最好下层至通用模块，或者基础模块

组件化和非组件化区别

组件化 能够帮助我们将大部分项目拆解成数个小组件，开发者只需要关注组件所依赖的其他组件，而无需关心完整项目的其他部分，每个组件可以自己采取所习惯的架构模式：MVC、MVVM 等，就行开发一款个人独立的App那样自由

非组件化：

代码高耦合度、高依赖
项目复杂、臃肿、编译时间过长（影响调试）
难以融合、集成其他产品
…

组件化：重点

代码复用性提高，可方便集成到其他项目
项目可配置，方便集成和功能回退
方便组件并行开发
可方便单元测试
…

组件化分层重点

项目组件化，最难的就是 粒度 问题，需要开发者根据自己的经验把控。这里给出个人认为的层次划分：

【基础组件】：宏定义/自定义工具类，如常用的自定义分类
【功能组件】：项目中常用的功能，如地图/消息推送/分享/登录等
【业务组件】：项目中的模块/业务，如文章详情/个人中心等
【中间组件】：负责项目中的路由/消息通知/传参/回调等
【宿主工程】：项目容器，用来集成组件，调整各个组件之间的消息传递容器

中间组件几种方案

在组件化中，中间层是各个组件的通信桥梁，中间层在组件化过程中扮演着非常重要的角色。

中间组件的三种方式：

基于 URL Scheme 的 路由
基于 Runtime 的 target-action
面向接口的 Protocol - Class

基于 URL Scheme 的三方库

iOS 中支持的 URL Scheme 让我们能够在 应用之间、应用内部传递消息。

具体怎么使用，可以自行去探索

基于 `Runtime` 的 `target-action`

相比 url scheme 的提前注册、实现服务，CTMediator 借助 OC 运行时的特性，现实组件之间服务的自动发现，无需提前注册即可实现组件间的调用，因此，这种方案的可维护性、可读性、扩展性相对较高。

CTMediator

面向接口 `Protocol - Class`

Protocol - Class

面向接口的方案通常由两部分组成，一个是用来管理接口协议的类（ProtocolManager），一个是具体的接口协议（ComponentProtocol）

组件化的核心工具重点

组件化工程，需要一个宿主工程，负责集成所有的组件。每个组件都是一个单独的工程，通过 Git 私有仓库来管理。
所有组件都上传到 Git 仓库并支持 cocoapods 集成。主工程通过配置 Podfile 文件，然后一键 pod update 即可。使用 Cocoapods 来管理组件主要因为其本身功能强大，方便的集成整个项目，解放对依赖库的管理。使用组件化的集成方式，可以很好的避免传统项目中的代码冲突问题。
组件化的核心工具就是 CocoaPods ，我们要做的就是将组件项目上传到 Gitee码云 或者 Gitlab极狐，编写项目的 podSpec 文件让组件支持 CocoaPods 集成即可。

OC组件化01：组件化介绍