一.组件化是什么？

组件化就是将APP拆分成各个组件，同时解除这些模块之间的耦合，然后通过主工程将项目所需要的组件组合起来。这样组件化过后的项目就变成了很多小模块，如果新项目中有类似的需求，直接将模块引入稍作修改就能使用了。这种设计类似引入三方库，其实制作组件的过程就相当于做三方库。因此常见的组件化方案大多都是使用cocoapods做依赖管理。

二.为什么要组件化？

在一个项目越来越大，开发人员越来越多的情况下，项目会遇到很多问题。业务模块间划分不清晰，模块之间耦合度很大，非常难维护。所有模块代码都编写在一个项目中，测试某个模块或功能，需要编译运行整个项目。

而进行组件化开发后，可以把每个组件当做一个独立的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来完成组件化的实践。