写在前面

年前到现在大部分时间都在整理和抽象之前项目的代码，那酸爽，真是够够的。主要是公司产品是做定制版的本需求，而前期对定制的内容需求太不明确了，导致领导先说前期就用不同代码管理不同的定制版。最后我们这里中英文版就有6套代码，导致管理起来特别不方便。而之前在写代码的时候完整体的框架是写好的，可是在细节上的封装来说就差太远了。导致整个代码的耦合度太高了，这段时间抽象起来相当痛苦。所以现在就开始对项目进行模块化管理，保证各个模块之前可以重用和替换，并且之后根据客户需求只加载用户需求的模块。

最后我决定采用Cocoapods对各个模块进行管理，采用公有库和私有库共存的状态。然后在添加配置文件以及一些Runtime的机制进行管理。

而对于一个公司的核心代码来说，当然不可能采用公开的形似来进行管理对已的框架。所以在Cocoapods中，还有另一种方式提供给公司内部管理进行管理代码，那就是私有库(Private Pods)。

私有库

好了，废话不多说了，我们先开始说说如何创建私有库吧。其实创建私有库的核心过程还是跟公有库是差不多的。不管是私有库还是公有库，关注点都在于Podspec文件的书写。但是在上篇文章中讲过了大体Podspec文件以及创建公有库的流程了，这里我就对那些部分不进行详细讲解了。这里针对一些不同的地方以及需要注意的地方进行讲解一下。

首先在创建私有库之前，我们是不是该先创建一个私有库该往哪个仓库提交的仓库(Spec)。 所以当然当务之急是先创建一个私有仓库啦。而这个仓库对于公司来说的话，最好是搭建在内网里面，用Gitlab之类的git仓库管理工具即可。

这里再带一句，其实我们上章所讲到pod trunk push 项目名.podspec这条命令，其实是默认我们的Podspec文件提交到Cocoapod的仓库(Specs),然后我们之后的pod install或者pod update都是从这个仓库中提取Podspec文件，然后根据文件里面的信息去取对应的源代码。大家可以上去找找自己的开源的Podespec文件转换成json的文件。

好了，废话不多说（不过好像也说了非常多的废话了）。先建仓库吧：

这里的仓库地址最好是私有地址，让所有可以使用这个仓库的成员都可以访问的地址。当然通过上面这句话，就能非常简单的创建好私有库的地址了。当然，小伙伴们可以通过cd ~/.cocoapods/repos这个目录里面检查是否创建好具体的私有库。

当然之后就是写代码->写Podspec文件了->检查项目和Podspec文件->打tag，这里就不进行累述了。到了下一步按照原定计划来说的话，应该是要提交项目到Cocoapods上对了吧，可是我们这里讲的是私有库，当然不可能提交到Cocoapods上，而应该提交到自己的仓库里面。 将之前的pod trunk push 项目名.podspec修改为pod repo push '私有仓库名' 项目名.podspec即可。之后大家就可以前往之前创建的私有库的地址上查看是否上传版本成功。

好了，到此为止简单的创建私有库的流程就说完了。 不过还有一些小的方面跟大家顺带说一下，

• 比如如何删除私有仓库:pod repo remove [name]。
• 在普通项目中如何使用私有仓库，可以在Podfile里面的开头声明所有包含的仓库名,即利用第一章-入门说到的source参数

开发模式

当然，在使用私有库的过程中，很大一部分时间私有库都是处于开发阶段，而我们总不能一直提交tag的方式进行pod update更新吧。因此Cocoapods就提供了一个开发模式,其实操作起来也是非常简单的事情，就是将所谓的引用路径修改成本地路径即可。就是讲Podfile中的pod '库名', :path => '本地路径'即可。这样在通常的修改代码中是不需要执行pod update的，但是对于如果修改了目录结构（添加、删除或者移动文件文件）或者是修改了Podspec文件的配置的话，最好是运行一下pod update的命令。普通修改代码的情况下就不需要运行pod update命令和打tag了。

上图就是iOS-Echarts开发模式下的一个简单的演示-Podfile里面的代码。

使用私有库

使用私有库的方式我在这里主要列举了两种情况，下面针对这两中情况的具体注意项我这里稍微说明一下。 第一种,正常使用私有库的情况，即在Podfile中引用私有库 这种方式最简单，就是通过在Podfile开头列举说所有私有库的位置以及Cocoapods位置即可。

第二种，在私有库中引用私有库，即在Podspec文件中依赖(dependency)私有库 这种情况就比较麻烦一点，因为毕竟Podspec文件中并没有指明私有仓库地址的地方。那么肯定就不在Podspec文件里面指明私有仓库的地方。而是在验证和上传私有库的时候进行指明。即在下面这两条命令中进行指明：pod lib lint 项目名.podspec --sources=https://github.com/CocoaPods/Specs.git,192.168.0.100:Plutoy/Specs.git以及pod repo push --source=https://github.com/CocoaPods/Specs.git,192.168.0.100:Plutoy/Specs.git,要不然你在检验项目以及提交项目过程中就会出现Error的情况。

但是这两种情况还是有点不同的，第一种情况是可以采用开发者模式，而第二种情况不能采用开发者模式，只能通过打tag之后才能进行使用，所以在使用第二种情况下最好是测试好之后打完tag再进行引用。

Cocoapods用在模块化管理

关于模块化管理，其实对于一个人力资源特别紧缺的公司来说还是挺有必要的。特别是遇到我这种需要定制版本的管理的公司，如果对于模块管理比较妥善的情况下，其实会为公司的人力资源和时间资源节省非常多的时间。本人确实有亲身经历，在经历了6个版本，可是核心功能相同的情况下，公司之前采用的是6套代码进行管理。从而产生了很多不必要的重复工作和人力资源的浪费，因此特别有必要对项目的各个模块化进行拆分和管理。 其实也有小伙伴跟我提过说用framework或者.a等框架形式不就好了么？可是对于framework要进行版本管理以及多地方引用的管理情况下，很多情况下都会忘记了当前大的包对应的是仓库管理里面的哪个版本，因为有可能我们经常打tag的时候，小修改还是会用同一个版本号，所以会出现很多误差性的情况。而通过Cocoapods进行管理的话，就可以追踪到仓库管理里面的具体提交号、版本号、branches等情况。

对于我们公司来说，由于有定制版的存在，所以我们基本上是封了很多小的私有库，如蓝牙模块，访问服务器模块，一些视图、第三登陆分享等。当然也有对于大的核心版本封装，如果整个App的核心功能的分装，当然通过模块也有可能分为秤的模块、手环的模块、血糖计血压仪的模块等等。当然这些大的模块中也都会引用小的模块然后最后根据Cocoapods配置以及plist文件进行扫描之后产生需要对应模块的版本，最后在通过代码扫描机制进行初始化项目。当然项目中还用到一些“黑魔法”和Runtime的一些知识，有兴趣的小伙伴可以去看看资料，或者联系我。

不过在进行模块化管理的过程中需要注意一些点：

• 模块中不能出现循环依赖，即A依赖B，B依赖C，C依赖A的情况
• 如果一个子模块引用，需要填写完整的模块名，如在Core模块下面有Controller模块下面有个Setting模块，并且整个库的名字为TestProj的话,则依赖的名称需要这样写s.dependency 'TestProj/Core/Controller/Setting'的形式
• 如果出现模块特别多的情况下，在验证过程中，竟然采用--subspec=子模块名来进行一个模块一个模块验证，特别是对于如果只改动了一个模块的情况下，这里所说的字模块名也和上面一点异样，要填写完整的模块名
• 在写私有库的过程中，竟然不用prefix header的形式，因为在分子模块的过程中很容易出现忘记引用header而出现的Error
• 最后一点，多google，少百度，太多资料只能通过google查到，而在百度里面完全查不到

写在最后

到此为止，关于Cocoapods的使用，从使用者到最后的自己开发自己的库的教程就到此为止了。里面包含了很多内容，有些内容可能写的不够清楚，不过大体上这个也是说说我使用Cocoapods的教程，如果中间出现什么疑问或者错误，欢迎小伙伴留言或者联系我。 当然除了Cocoapods外，还有另外两个Carthage以及Swift Package Manager依赖管理工具，有兴趣的小伙伴可以研究一下。这两个管理工具都是针对动态库，所以一般都是在iOS8以上，对于要兼容iOS7以上的小伙伴(包括我)来说是一个不利的地方，但是Carthage的使用比Cocoapods方便。你只需要保证你的代码能编译通过即可。至于Swif Package Manage本人没用过，不敢多说什么。不过竟然学了这么多的内容，希望小伙伴们还是可以学以致用，即使不能用在公司的项目，也可以考虑用在为开源的事业尽一份力的程度上，至少让中国的开发者能在开源的方面不落后其他国家的小伙伴。