（笔记）CocoaPods 统一管理以来库

一、CocoaPods流行的原因

001 非常成熟 稳定 简单易用 学习成本低 效果明显

002 会自动整合Xcode项目，使得其他项目成员在使用第三方库时无需任何额外的手工操作

003 已成为IOS业界标准，支持几乎所有的开源和商业库，即便是OC的依赖库以及二进制依赖库它也提供支持。

二、怎样使用

001 语义化管理：

MAJOR主版本号，重大更新才会使用主版本号。

MINOR副版本号 用于小功能的改善。

PATCH补丁版本号。一般用于bug修复以及安全性问题等。

BUILD构建版本号。一般在内部测试时使用。

002 Pod版本管理

Podfile文件 一个配置问及看，主要用来描述Xcode项目里的各个target的依赖库

source配置 source PodSpec文件的Repo，从而使得CocoaPods能够查询到PodSpec文件，这个仓库存放所有公共依赖库的PodSpec文件。

source 'https://cdn.cocoapods.org/'

执行pod install命令的机器必须能访问到source所指向的 Repo。

project 用于指定我们的主项目文档。该项目文档会使用到CocoaPods管理三房依赖库

workspace 用于指定生成和更新Workspace文档。

platform 指定操作系统以及所支持系统的最低版本号

use_frameworks 让CocoaPods 把所有第三方依赖库打包生成一个动态加载库，能有效加快编译和链接速度

target配置：把构建目标所使用的所有依赖库放进target代码块中间。

为了统一管理第三方依赖库的版本，我建议统一使用 = 来锁定该依赖库的版本，这样就能保证每次执行pod install的时候都可以为同一个库下载同一个版本。

除了 = 操作符以外，CocoaPods 还支持其他操作符来指定版本：

• > 0.1表示大于 0.1 的任何版本，这样可以包含 0.2 或者 1.0；

• >= 0.1表示大于或等于 0.1 的任何版本；

• < 0.1表示少于 0.1 的任何版本；

• <= 0.1表示少于或等于 0.1 的任何版本；

• ~> 0.1.2表示大于 0.1.2 而且最高支持 0.1.* 的版本，但不包含 0.2 版本。

• Podfile.lock 文件是由 CocoaPods 自动生成和更新的，该文件会详细列举所有依赖库具体的版本号。

• Podfile 和 Podfile.lock 文件一同 commit 并 push 到 Git 代码管理服务器里面。特别是在团队开发的环境下，这样能帮助我们保证各个依赖库版本号的一致性。

• Workspace 文档是 Xcode 管理子项目的方式。通过 Workspace，我们可以把相关联的多个 Xcode 子项目组合起来方便开发。

  前面说过，当我们执行pod install的时候，CocoaPods 会自动创建或者更新一个叫作 Pods 的项目文档（Pods.xcodeproj ）以及一个 Workspace 文档

  其中，Pods 项目文档负责统一管理各个依赖库，当我们在 Podfile 里面指定构建成动态库的时候，该项目会自动生成一个名叫Pods_<项目名称>.framework的动态库供我们项目使用。

  而 Workspace 文档则统一管理了我们原有的主项目 （Moments.xcodeproj）以及那个 Pods 项目。

三、Pod 版本更新

第一步，CocoaPods 已经为我们提供了pod outdated命令，我们可以用它一次查看所有 Pod 的最新版本，而无须到 GitHub 上逐一寻找。下面是执行pod outdated命令的其中一条结果：

第二步，在更新依赖库版本之前，为了避免在新版本中不小心引入 Bug，我们需要了解新的版本到底提供了哪些新功能，修改了哪些 Bug，与老版本是否兼容等事项。具体我们可以到 CocoaPods 官网上查找需要更新的第三方依赖库，然后在 GitHub 等平台上找到，并仔细阅读该库的版本说明（release note）。

请注意，我们要阅读当前使用版本到要更新的版本之间的所有版本说明。

第三步，在 Podfile 文件里把要更新的 Pod 的版本号进行修改。此时特别注意的是，我们要使用pod install而不是pod update。因为执行pod update会自动更新所有 Pod 的版本，这可能会更新了一些我们目前还不想更新的 Pod，从而会引入一些难以觉察的问题。

第四步，如果所更新的版本包含了不可兼容的更新，我们需要修改代码来保证代码能顺利完成编译。

第五步，很多第三方依赖库都是一些通用的基础组件，一旦发生问题会影响到整个 App 的功能，因此我们需要根据所更新的库进行回归测试。例如当更新了 Alamofire 库的时候，我们需要把每个网络请求都执行一遍，避免所更新的版本引入新的 Bug。

第六步，为了把更新的版本共享给所有开发者和 CI 服务器，我们需要把 Podfile 和 Podfile.lock 文件一同 commit 并 push 到 Git 代码管理服务器，并通过 Pull Request 流程并入主分支。

第七步，一旦更新的代码并入主分支后，要通过 Slack 等内部通信软件告诉所有开发者 pull 或者 rebase 主分支的代码，并执行pod install来更新他们开发环境的所有依赖库。

特别注意，千万不要使用pod update，因为pod update会自动把开发者机器上所有 Pod 的版本自动更新了。这种更新往往不是我们想要的结果，我们希望统一更新各个 Pod 的版本，并通过 Git 进行集中管理。

为了保证依赖库版本都能保持一致，尽量不要执行pod update，而是使用通过修改 Podfile 文件里的版本号并执行pod install来更新 Pod 的版本，然后把 Podfile 和 Podfile.lock 文件一同并入 Git 主分支中进行统一管理。

参考文献