Cocoapods系列教程(三)——私有库管理和模块化管理

私有库

我们先开始说说如何创建

私有库

吧。其实创建

私有库

的核心过程还是跟

公有库

是差不多的。不管是

私有库

还是

公有库

，关注点都在于

Podspec

文件的书写。但是在上篇文章中讲过了大体

Podspec

文件以及创建公有库的流程了，这里我就对那些部分不进行详细讲解了。这里针对一些不同的地方以及需要注意的地方进行讲解一下。

首先在创建

私有库

之前，我们是不是该先创建一个

私有库

该往哪个仓库提交的仓库(

Spec

)。
所以当然当务之急是先创建一个

私有仓库

啦。而这个仓库对于公司来说的话，最好是搭建在内网里面，用Gitlab之类的git仓库管理工具即可。

这里再带一句，其实我们上章所讲到

pod
trunk push 项目名.podspec

这条命令，其实是默认我们的

Podspec

文件提交到Cocoapod的仓库(Specs),然后我们之后的

pod
install

或者

pod
update

都是从这个仓库中提取

Podspec

文件，然后根据文件里面的信息去取对应的源代码。大家可以上去找找自己的开源的

Podespec

文件转换成json的文件。

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

pod repo add '仓库名' '仓库地址'

这里的仓库地址最好是私有地址，让所有可以使用这个仓库的成员都可以访问的地址。当然通过上面这句话，就能非常简单的创建好私有库的地址了。当然，小伙伴们可以通过

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了。

pod 'iOS-Echarts', :path => '../iOS-Echarts'

上图就是iOS-Echarts开发模式下的一个简单的演示-

Podfile

里面的代码。

使用私有库

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

Podfile

开头列举说所有私有库的位置以及

Cocoapods

位置即可。

# Podfile文件
# 公有仓库
source 'https://github.com/CocoaPods/Specs.git'
# 私有仓库
source 'https://192.168.0.100/TestPrivate/Specs.git'

第二种，在私有库中引用私有库，即在

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

本人没用过，不敢多说什么。不过竟然学了这么多的内容，希望小伙伴们还是可以学以致用，即使不能用在公司的项目，也可以考虑用在为开源的事业尽一份力的程度上，至少让中国的开发者能在开源的方面不落后其他国家的小伙伴。