一.组件化是什么？
组件化就是将APP拆分成各个组件，同时解除这些模块之间的耦合，然后通过主工程将项目所需要的组件组合起来。这样组件化过后的项目就变成了很多小模块，如果新项目中有类似的需求，直接将模块引入稍作修改就能使用了。这种设计类似引入三方库，其实制作组件的过程就相当于做三方库。因此常见的组件化方案大多都是使用cocoapods做依赖管理。
组件化本质是顺应着 App 从单一业务到多业务汇聚的演进而出现的一门技术。比如微信刚发布时业务单一，就只有聊天的功能，后来又加上了支付、朋友圈、游戏，再等到小程序功能上线后更是打车、电影票、购物等只要你能想到的需求它都有，俨然成为了一个超级平台。所以从本质上讲，组件化是将上层业务隔离开，下层提供通用能力的一种架构模式，这样上层业务团队可以分开从而减少团队沟通成本，下层能力的通用性又反过来提高了各个业务团队的开发效率。为了达到不同业务隔离的结果，解耦手段不断被引入到 iOS 开发中，比如使用协议或者中间者模式在运行时统调等方式。所以组件化的核心思想就是解耦。
二.为什么要组件化？
在一个项目越来越大，开发人员越来越多的情况下，项目会遇到很多问题。业务模块间划分不清晰，模块之间耦合度很大，非常难维护。所有模块代码都编写在一个项目中，测试某个模块或功能，需要编译运行整个项目。
而进行组件化开发后，可以把每个组件当做一个独立的app，每个组件甚至可以采取不同的架构，例如分别使用MVVM、MVC、MVCS等架构，根据自己的编程习惯做选择。
主要有4个原因：
- 模块间解耦
- 模块重用
- 提高团队协作开发效率
- 单元测试
当项目越来越大的时候，各个模块之间如果是直接互相引用，就会产生许多耦合，导致接口滥用，当某天需要进行修改时，就会牵一发而动全身，难以维护，所以要组件化。
组件化有以下优点：
1.可单独测试各组件，有问题各模块负责人解决，没问题再集成到宿主工程中，这样避免某个模块有问题导致全工程有问题
2.组件可独立运行，提高的代码的复用性，组件化的颗粒度越细，可复用度就越高。
3.当组件库的数量足够庞大时，项目只需要组合组件即可完成大部分的开发工作。
4.组件化后项目的代码结构更加清晰，追踪问题、修复bug、增加需求更方便。
5.不同业务组件相互独立，明确团队开发的业务边界，增加团队协作效率。
6.各组件可单独使用MVC或MVVM模式各自开发，不会像之前那样整个工程统一用某个模式，组件以cocoapod管理，被二进制化，大大加快编译速度。
当然组件化也有缺点：
1.增加开发人员的学习成本
2.增加了代码的冗余，组件化颗粒度越细，中间代码越多
3.增加了项目的复杂度，复杂度越高越容易出问题
三.组件化前准备分层
组件化我归纳了一下整个流程：
组件化大致可分三层：
- 基础组件： 基础配置(宏，常量)， 分类，网络(AFN, SDW二次封装)、工具类(日期时间的处理， 文件处理， 设备处理)。
- 功能组件：控件(弹幕，轮播器，选项卡)；功能(断点续传，音频处理)。
- 业务组件：登录，业务一，业务二。
分层可以最大限度的避免复杂的耦合，减少组件化时的困难，而且在分层设计时要保持上层对下层的单项依赖。
分层要求：
1.基础库应当做到互相独立，除了依赖于系统框架和一些非常主流的三方框架外，不对其他代码做任何依赖，每个库都可以独立通过单元测试。
2.业务库也就是功能组件虽然包含一定对业务逻辑，但是其中的业务逻辑应当是较大范围内都通用的业务逻辑，比如三方登陆、分享、支付库的调用业务。也就是说这一块的库应当是可以在同公司多个app中通用的。
3.业务组件则是对业务模块的封装，所谓的组件化颗粒度一般指的就是这一层的封装颗粒度，理论上颗粒度做到每个页面是最理想的情况，但实际情况总是千变万化的，某些页面的耦合度可能会非常高，拆分的代价太大，得不偿失。那么我们完全可以将颗粒度稍微放粗一些，将有紧密业务联系的页面组成一个组件，然后暴露使用这个组件的接口即可。
四.组件间通信
各组件通信利用中间件通信，中间件方案有：
1.路由器，比如MGJRouter。
2.Target-Action。
3.协调器，coordinator。
本系列文章中Demo采用XCoordinator和CTMediator来实现通信的。这样做的好处是：各组件间相互隔离解耦，而且与中间件也没有耦合关系，组件里需要跳转的部分被coordinator接管，coordinator中跳转的地方只需要调用中间件的方法，通过runtime来完成真正的调用。
五.组件化遇到的问题总结
1. XiB和storyboard的依赖问题
XiB和storyboard被抽成组件放到Pods文件夹中后，就不在mainBundle中了，需要找到当前类所在bundle来加载：
2. 图片资源依赖问题
图片资源也是一样，抽到组件中后就不在mainBundle中了，不能从mainBundle中加载出来了，也存在图片资源依赖问题，解决此问题步骤如下：
2.1 将图片资源拖到本地模版库与Classes同级的文件夹Assets中：
2.2 修改spec文件，设置资源加载路径，到测试工程中install安装。
2.3 改变加载方式：
````
func imagePath(imageName: String, imageFormat: String) -> UIImage{
let bundle = Bundle(for: SFDiscoverCycleScrollCell.self)
let fullImageName = "\(imageName)@2x.\(imageFormat)"
guard let path = bundle.path(forResource: fullImageName, ofType: nil, inDirectory: "SFCloudMusicDiscoverKit.bundle"), let image = UIImage(contentsOfFile: path) else {
return UIImage()
}
return image
}
````
要注意的是：mainBundle会识别图片的尺寸和格式，而自定义bundle不会，所以这里图片的全名要包含尺寸和后缀，而且path也要指定图片所在bundle包名。
3. 对其他组件的依赖
如果某个业务组件对其他组件有依赖，在验证本地模版库时会报以下错误：
这是因为验证podspec文件时默认只会到官方索引库 (https://github.com/CocoaPods/Specs.git）中去校验，而我们的业务组件中依赖了的其他组件，需要同时指定自己创建的远程索引库地址库中校验。解决办法如下：
```
pod lib lint --verbose --allow-warnings --sources='https://github.com/shcamaker/SFCloudMusicBaseKitSpec.git,https://github.com/CocoaPods/Specs.git'
```
4.分支
有时某个组件库中可以开多个分支，方便我们导入使用时，不用集成那些我们不需要的分支内容，开分支的写法可参考如下：
```
# s.source_files = 'SFCloudMusicBaseKit/Classes/**/*'
s.subspec 'Extensions' do |e|
e.source_files = 'SFCloudMusicBaseKit/Classes/Extensions/**/*'
end
s.subspec 'Utils' do |u|
u.source_files = 'SFCloudMusicBaseKit/Classes/Utils/**/*'
u.dependency 'SDWebImage'
end
```
以上就是我在组件化过程中遇到的问题，随后几篇文章会通过一个Demo来完成组件化的实践。