CocoaPods系列教程(三) —— 私有库管理和模块化管理
对项目进行模块化管理，保证各个模块之前可以重用和替换，并且之后根据客户需求只加载用户需求的模块可以采用CocoaPods对各个模块进行管理，采用公有库和私有库共存的状态。然后在添加配置文件以及一些 Runtime的机制 进行管理。
而对于一个公司的核心代码来说，当然不可能采用公开的形似来进行管理对已的框架。所以在CocoaPods中，还有另一种方式提供给公司内部管理进行管理代码，那就是私有库(Private Pods)。
私有库
我们先开始说说如何创建私有库吧。其实创建私有库的核心过程还是跟公有库是差不多的。不管是私有库还是公有库，关注点都在于Podspec文件的书写。但是在上篇文章中讲过了大体Podspec文件以及创建公有库的流程了，这里我就对那些部分不进行详细讲解了。这里针对一些不同的地方以及需要注意的地方进行讲解一下。
首先在创建私有库之前，我们是不是该先创建一个私有库该往哪个仓库提交的仓库(Spec)。 所以当然当务之急是先创建一个私有仓库啦。而这个仓库对于公司来说的话，最好是搭建在内网里面，用Gitlab之类的git仓库管理工具即可。
先建仓库：
|
|
这里的仓库地址最好是私有地址，让所有可以使用这个仓库的成员都可以访问的地址。当然通过上面这句话，就能非常简单的创建好私有库的地址了。当然，小伙伴们可以通过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了。
|
|
使用私有库
使用私有库的方式我在这里主要列举了两种情况，下面针对这两中情况的具体注意项我这里稍微说明一下。
第一种：正常使用私有库的情况，即在Podfile中引用私有库；这种方式最简单，就是通过在Podfile开头列举说所有私有库的位置以及CocoaPods位置即可。
|
|
第二种：在私有库中引用私有库，即在Podspec文件中依赖(dependency)私有库；这种情况就比较麻烦一点，因为毕竟Podspec文件中并没有指明私有仓库地址的地方。
那么肯定就不在Podspec文件里面指明私有仓库的地方。而是在验证和上传私有库的时候进行指明。即在下面这两条命令中进行指明：
|
|
要不然你在检验项目以及提交项目过程中就会出现Error的情况。
但是这两种情况还是有点不同的，第一种情况是可以采用开发者模式，而第二种情况不能采用开发者模式，只能通过打tag之后才能进行使用，所以在使用第二种情况下最好是测试好之后打完tag再进行引用。
模块化管理
关于模块化管理，其实对于一个人力资源特别紧缺的公司来说还是挺有必要的。其实也有小伙伴跟我提过说用framework或者.a等框架形式不就好了么？可是对于framework要进行版本管理以及多地方引用的管理情况下，很多情况下都会忘记了当前大的包对应的是仓库管理里面的哪个版本
因为有可能我们经常打tag的时候，小修改还是会用同一个版本号，所以会出现很多误差性的情况。而通过CocoaPods进行管理的话，就可以追踪到仓库管理里面的具体提交号、版本号、branches等情况。
不过在进行模块化管理的过程中需要注意一些点：
- 模块中不能出现循环依赖，即A依赖B，B依赖C，C依赖A的情况
- 如果一个子模块引用，需要填写完整的模块名，如在Core模块下面有Controller模块下面有个Setting模块，并且整个库的名字为TestProj的话,则依赖的名称需要这样写
s.dependency 'TestProj/Core/Controller/Setting'的形式 - 如果出现模块特别多的情况下，在验证过程中，竟然采用
--subspec=子模块名来进行一个模块一个模块验证，特别是对于如果只改动了一个模块的情况下，这里所说的字模块名也和上面一点异样，要填写完整的模块名 - 在写私有库的过程中，竟然不用prefix header的形式，因为在分子模块的过程中很容易出现忘记引用header而出现的Error
