一、 什么是Cocoapods

Cocoapods 是专门为xcode设计,用来管理第三方代码库的工具；所需的第三方依赖库，需要在Podfile文件里面进行配置。

许多人刚开始使用cocopods的时候，可能认为pod install 只是在首次配置自己项目的时候使用，pod update在以后使用，那么这样认为就大错特错了

二、 pod install vs. pod update 、pod outdated

• pod install 是用来安装一个新的pods依赖库，或者说pod install 当你想把一个pods 依赖移除或者添加到工程的时候使用；
• pod update 仅仅是望你想要更新pods到较新版本的时候使用
• 当运行pod install 命令的时候，它的操作步骤是：下载和安装新的pods--- 在Podfile.lock文件写入每一个已经安装pods的版本号；这个文件用来追踪和锁定所安装的pods的版本号。
• pod install 仅仅处理那些没有在podfile.lock列出的依赖库pods。对于已经在Podfile.lock文件里的pods,它仅仅下载在Podfile.lock里面锁定的版本，并不去检查是否有可用的最新版本；对于没有在Podfile.lock的pods，它会搜索和匹配在Podfile文件里面所描述的对应的版本（e.g pod 'AFNetworking', '~>3.0')。
• pod outdated命令 Cocoapods会列出项目中Podfile.lock文件里面锁定的版本具有新版本可以更新的pods。
  这个是我的工程里面对应的Podfile， 列出了工程需要的依赖库：
  屏幕快照 2017-01-12 下午5.00.42.png
  下面这个截图是 pod outdated命令后，找出了有新版本可以更新的第三方库
  屏幕快照 2017-01-12 下午5.01.16.png
  下面的截图是Podfile.lock文件中锁定的第三方库的版本，以及对应的版本号
  屏幕快照 2017-01-12 下午5.04.12.png

对比截图二和截图三，我们可以看出，在Podfile.lock文件中，Masonry、SDWebImage、Realm这三个库锁定的版本号是比较老的版本，运行命令pod outdated后，就列出了可以更新的版本号。

• pod update 当你运行 pod update podName, Cocoapods会找出podName 可以更新的的版本（除了在Podfile.lock里面已经列出锁定的版本）， 它会根据Podfile.lock文件里面的限制条件，尽可能对升级podName到比较新的可用的版本。如果pod update 后面不添加podName的话，Cocoapods 会根据Podfile文件里面列出的pods,把每一个pod更新到相应比较新的可用的版本。

三、 那么到底在那些场景下使用呢用呢？

• 对于pod update PODNAME 这个命令，仅仅是更新一个特定的pod(这个操作会根据Podfile文件的配置检测特定的pod是否存在可更新版本，如果就相应的进行更新）。与之相反的是命令pod install这个命令并不会尝试检测更新已经安装pod。
• 当你在Podfile里面添加了新的pod，那么最好选择使用pod install，而不是选择pod update , 因为pod install 可以避免安装和 更新操作在一个线程里面进行，从而提高效率，节省安装时间，但这并不是说 pod update 不行，而是相对来说这种场景下用pod install更好一些。
• pod update 命令，当你想要更新某一个特定的pod 或者所有的pod的时候是最好的选择。

四、Commit 提交 Podfile.lock

作为一个提醒：即使你的代码管理策略中，提交代码的时候并不提交Pods文件夹到共享的代码仓库中，但是提交和上床Podfile.lock文件是很有必要的，否则的话，上面对于命令 pod install的功能解释（pod install可以安装锁定的相应版本）将不再适用。

五、适用场景举例

• 阶段一：用户user1创建了一个工程
  user1 创建了一个工程，想使用pods A 、B 、C, 那么然后创建一个Podfile， 将对应的版本添加到Podfile里面，运行 pod install , 将会安装 A、B、C，我们假设此时指定使用的版本都为1.0.0;
  Podfile.lock 将会持续追踪限制安装A、B、C的版本都为1.0.0；

此外：因为这是第一次运行pod install命令， 此时Pods.xcodeproj并不存在， 那么运行 pod install命令后，除了安装pods外，还会创建Pods.xcodeproj和.xcworkspace。

• 阶段2: 用户user1 添加了一个新的pod
  不久后，user1想添加一个 pod D到Podfile文件。
  这时运行pod install之后，即使这个时候对于pod B有一个 用于维护的 Released 1.1.0版本，那么工程任然会保持pod B是版本1.0.0，因为用户user1 想要的是 pod D， 而不是其他版本的pod B。
• 阶段3： 用户user2加入工程
  对于user2 加入这个团队之前从没用在这个工程工作过，他将会clone仓库并且pod install；
  Podfile.lock文件的内容（这个内容应该是被提交到git 仓库的）将会保证user2获得的pod 和user1正在使用的pod是一样版本的pod；
  即使现在对于pod C有一个1.2.0可用的版本，user2 也只会安装使用 C 1.0.0版本，这就要归功于Podfile.lock了， 因为 pod C在Podfile.lock中注册的版本是1.0.0，所以Podfile.lock就会锁定pod C只能安装使用1.0.0版本；
• 阶段4： 检测新的可用pod
  之后，user1 想知道那些pods更新了，那么可以运行pod outdated, Cocoapods将会列出有更新可用的pods, 比如 pod B 有一个1.1.0可用的新版本，pod C 有一个 1.2.0可用的新版本；
  user1 决定更新pod B而不更新pod C， 那么运行 pod update B, 将会将 B由版本1.0.0更新到1.1.0（相应的，Podfile.lock 也进行更新）pod C将仍然是1.0.0而不是1.2.0；

六、在Podfile 中使用确切的版本并不能适用所有场景

一些开发者可能认为只要在Podfile文件中制定了特定的版本比如pod 'A', '1.0.0'， 就可以保证所有团队成员可以使用相同的pod 版本，其实并不是这样。
有一个经典的例子：如果pod A有一个pod依赖 A2，并且在pod A的podspec中进行了声明：dependency 'A2', '~> 3.0'， 在这种场景下在Podfile文件中声明pod 'A', '1.0.0'确实能够保证user1和user2两者总是使用版本1.0.0，但是

• user1 可以使用 pod A2 3.4.0版本(在user1使用的时候假设A2 3.4.0版本是最新的可用）
• user2随后加入团队后，pod install获得的是 pod A2 3.5.0的版本（因为在user2的时候假设 3.5.0是可用的）
  这就是为什么说使用Podfile.lock是唯一的途径让不同开发人员在不同的电脑上使用相同的pod的版本，并且要适当使用 pod install和 pod update。