为什么选择CocoaPods进行iOS代码的管理

我算是一个相对比较固执的人，很长一段时间里，我都非常怀疑CocoaPods这种第三方代码的管理方式。

而相信大家对于iOS的开发中，很多人都会推荐使用CocoaPods来管理第三方的代码；但是从来没有人说过，为什么要这样做；这也是我一直以来抱有怀疑态度的原因之一。

而最近一段时间公司的项目模块化的原因，终于找到了CocoaPods的优秀之处；怕遗忘，喜分享，特记录以供众人探讨。

我们知道，在iOS的项目中，我们一般可以对一个项目做成多个模块，形成高内聚、低耦合的格局。而对于模块化的管理，一般可以有以下几种方式：

1、子项目

即，另外做一个XCode项目，加入到workspace当中去；

2、.a 或者Framework

即，在另一个单独的项目里，做成一个单独的Framework；Framework打包好了之后，拖到主项目中进行使用

3、直接拖代码

即，将开源的，或者别人写好的代码，直接拖到主项目之中

4、CocoaPods

即，我们讨论的主角。

我们都知道，公司级的多人配合中，代码的管理很多时候是多仓库的管理；比如我这里，每个相对独立的模块，都是由不同的Git仓库进行管理的。

这样的好处在于，不同人负责不同的独立模块；不同的独立模块还可以供不同的项目进行使用；真正达到代码复用的目的和效果。

而这个时候，主项目也当然使用一个Git仓库进行管理。

那么在这种情况下，我们来看看以上四种模块化管理方式所面临的问题：

1、子项目

子项目可以单独编译；同时也可以直接拖入主项目参与编译。编译的成果一般是.a或者Framework，以供主项目使用。

子项目一般由单独的Git仓库管理，其版本控制、版本发布不受主项目控制。

子项目的Git与主项目的Git 会分开。因此，在Clone的时候，需要分别Clone主项目以及主项目中所使用到的所有子项目。

这里就会造成一个问题：需要人工地维护一份Git仓库列表；对于每一个新进的程序员，都要告知其项目的组成以便每次Clone时，确保代码不被遗漏。

2、.a 或者Framework

这种方式，其实就是上面第1种方式中，不将项目拖入主项目，而是单独在外面编译形成.a或者Framework后，将成品拖入主项目中。

这种方式，属于现在绝大多数闭源第三方的方式。它拥有非常明显的优点：不开源。

然后，这里也会造成一个问题。倘若Framework并没有稳定，很多时候会需要频繁地调试和更改。每次更改都需要在子项目中打包，然后拖入主项目中进行更新。这其中带来的时间消耗是非常巨大的。

我就经历过一天打包20多次Framework的经历；也许你要说为何不做单元测试；而事实上单元测试能解决80%以上的bug，集成测试中的20%bug还是需要更改；而且最要命的是，很多问题不是软件的bug，是产品设计上的bug。

3、直接拖代码

其实直接拖代码和第一种形式比较像。

这种方式好处在于，最简单，谁都会。

坏处在于，其他人的模块中的代码，你从他人的项目里拖进来；每当别人的代码有了改进，你又需要在其他的项目中更新一次，然后把代码拖到主项目中进行更新；

这样的结果和2种最后的结果非常类似，会造成大量的程序员无谓的时间浪费。

4、CocoaPods

CocoaPods的好处在于，将以上3种方式的缺点进行的摒弃。

CocoaPods的解决方案中，使用PodFile记录子项目的地址。

而PodFile作为主项目中的一项写入主项目的Git仓库中。

主项目根据PodFile中的子项目地址，拷贝子项目的源代码放入主项目中参与编译。

而主项目中的子项目，无法修改，在编译过程中，编译成.a以供主项目使用。

这样的好处在于：

首先是不同模块不同Git仓库的问题。

通过PodFile, 只需要主项目Clone下来，CocoaPods可以自动去寻找子项目地址，并且进行下载和更新；

之前1）中的问题就解决了。

其次是子项目频繁变更的问题。

PodFile中，可以指定子项目的版本号来进行子模块的版本依赖管理。因此主项目可以根据自己的需求来获取子项目的源代码。

而主项目需要升级子项目的代码，只需要在PodFile中，更新子项目的版本号，再Update即可。

从而解决了之前2）、3）中，频繁打包或者频繁拖动子项目更新的代码到主项目中的时间消耗。

最后就是子模块的管理问题。

虽然子模块的代码，是纯代码拷贝到主项目中，但是在CocoaPods对这部分代码的管理是编译成.a 二进制来参与编译的。因此在很多时候，可以提高编译效率。

同时，CocoaPods一般不允许在工程中去修改CocoaPods中的第三方代码，有效的保持一致性。

以上都是项目中遇见的坑，而最终归位我CocoaPods怀抱的艰苦历程。

希望能帮到你！