为什么需要CocoaPods

在进行iOS开发的时候，总免不了使用第三方的开源库，比如AFNetworking、Reachability等等。使用这些库的时候通常需要：

1：下载开源库的源代码并引入工程 2：向工程中添加开源库使用到的framework 3：解决开源库和开源库以及开源库和工程之间的依赖关系、检查重复添加的framework等问题 4：如果开源库有更新的时候，还需要将工程中使用的开源库删除，重新执行前面的三个步骤，这样的操作台繁琐 所以有了CocoaPods，通过使用CocoaPods这些繁杂的工作就不再需要我们自己亲力亲为了，只需要我们做好少量的配置工作，CocoaPods会为我们做好一切！

什么是CocoaPods

CocoaPods是一个用来帮助我们管理第三方依赖库的工具。由一个单一的文件管理工程，称之为Podfile。它可以解决库与库之间的依赖关系，下载库的源代码，同时通过创建一个Xcode的workspace来将这些第三方库和我们的工程连接起来，供我们开发使用。 使用CocoaPods的目的是让我们能自动化的、集中的、直观的管理第三方开源库。也可以看这里

Cocoa pods意义

1：在引入第三方库时它可以自动为我们完成各种各样的配置，包括配置编译阶段、连接器选项、甚至是ARC环境下的-fno-objc-arc配置等。 2：使用CocoaPods可以很方便地查找新的第三方库，这些类库是比较“标准的”，一般github大神的库都很棒，这样可以让我们找到真正好用的类库。

核心组件

CocoaPods是用 Ruby写的，并由若干个 Ruby包 (gems)构成的。在解析整合过程中，最重要的几个 gems分别是： CocoaPods/CocoaPods, CocoaPods/Core,和 CocoaPods/Xcodeproj (是的，CocoaPods是一个依赖管理工具 --利用依赖管理进行构建的！)。 注：CocoaPods是一个 objc的依赖管理工具，而其本身是利用 ruby的依赖管理 gem进行构建的 CocoaPods/CocoaPod 这是是一个面向用户的组件，每当执行一个 pod命令时，这个组件都将被激活。该组件包括了所有使用 CocoaPods涉及到的功能，并且还能通过调用所有其它的 gems来执行任务。 CocoaPods/Core Core 组件提供支持与 CocoaPods相关文件的处理，文件主要是 Podfile和 podspecs。 Podfile Podfile 是一个文件，用于定义项目所需要使用的第三方库。该文件支持高度定制，你可以根据个人喜好对其做出定制。更多相关信息，请查阅 Podfile指南。 Podspec .podspec 也是一个文件，该文件描述了一个库是怎样被添加到工程中的。它支持的功能有：列出源文件、framework、编译选项和某个库所需要的依赖等。 CocoaPods/Xcodeproj 这个 gem组件负责所有工程文件的整合。它能够对创建并修改 .xcodeproj和 .xcworkspace文件。它也可以作为单独的一个 gem包使用。如果你想要写一个脚本来方便的修改工程文件，那么可以使用这个 gem。

配置项目简单流程预览

1：创建或打开 Xcode 项目 2：令行 cd 到项目目录 (拖曳文件夹到cd后面就是路径) 3： 输入项目依赖 vim Podfile,例如,OC版本 platform :ios, '8.0' target '工程名' do pod 'AFNetworking', '~> 3.0' end Swift版本如下：

platform :ios, '10.0' use_frameworks! target '<Your Target Name>' do pod 'SnapKit', '~> 3.0.2' end 4：pod install 安装 5：打开 pod 创建的 xcworkspace进行使用

安装过程中可能遇到的问题

1：执行完install命令半天没反应 这有可能是因为Ruby的默认源使用的是cocoapods.org，国内访问这个网址有时候会有问题，网上的一种解决方案是进行替换，方式如下： $ gem sources --remove https://rubygems.org/ //等有反应之后再敲入以下命令 $ gem sources -a https://gems.ruby-china.org/ 要想验证是否替换成功了，可以执行：

longshihuadeMacBook-Pro:~ longshihua$ gem sources -l *** CURRENT SOURCES *** https://gems.ruby-china.org/

详情请见：https://gems.ruby-china.org/，成功之后，再进行安装：

$ sudo gem install cocoapods

详情操作，安装CocoaPods

安装 CocoaPods是用Ruby实现的，要想使用它首先需要有Ruby的环境。幸运的是OS X系统默认的已经可以运行Ruby了，因此我们只需要执行以下命令： $ sudo gem install cocoapods 一般情况下会直接安装的，当然也可能会存在其他的问题，如gem版本过低等情况。对于问题处理，可以参考这里。 常用命令 1：查看某个库是否存在    $ pod search AFNetworking(库名) 2：更新pod                       $ pod update 3：安装pod                       $ pod install 4：升级CocoaPods          $ sudo gem install cocoapods    升级很简单，再次执行安装命令即可，需要注意的是，如果安装的时候使用了sudo，升级的时候一样需要使用该关键字，不然升级完了以后又会出现路径不匹配问题。 使用CocoaPods 如果之前做的一切顺利，接下来就可以体验体验CocoaPods的神奇之处了，需要经过以下几步：为了演示这个过程，我创建了一个名为CocoaPodsDemo的工程。 创建,编辑Podfile 1：CocoaPods的一切都是从一个名为Podfile的文件开始的，我们需要先创建这个文件。

longshihuadeMacBook-Pro:~ longshihua$ cd /Users/longshihua/Desktop/CocoaPodsDemo longshihuadeMacBook-Pro:CocoaPodsDemo longshihua$ vim Podfile longshihuadeMacBook-Pro:CocoaPodsDemo longshihua$ 如上：首先进入到工程的根目录下（这里推荐使用一个工具，只需要进入对应的工程目录，然后点击右上角的图形（如下图所示），即可显示终端下对应的路径，不需要手动输入那么麻烦,具体操作，请看这里），创建空白的Podfile文件，创建完毕的目录结构如下图： 对应的Podfile文件界面为： 2:  点击字母i，插入内容 3：根据需要，我们可以在Podfile文件中写入需要用到的第三方库，以AFNetworking库为例(github上的第三方库基本上都会有导入方式提示)，我的Podfile内容如下： platform :ios, '8.0' target 'CocoaPodsDemo' do pod 'AFNetworking', '~> 3.0' end 4：输入内容完成，按esc键退出输入，然后保存退出。vim环境下，保存退出命令是： :wq或者大写ZZ 5：最后pod install，CocoaPods就开始为我们做下载源码、配置依赖关系、引入需要的framework等一些列工作，命令的执行结果打印出来如下： longshihuadeMacBook-Pro:CocoaPodsDemo longshihua$ pod install Analyzing dependencies Downloading dependencies Using AFNetworking (3.1.0) Generating Pods project Integrating client project Sending stats Pod installation complete! There is 1 dependency from the Podfile and 1 total pod installed. longshihuadeMacBook-Pro:CocoaPodsDemo longshihua$ 6：安装完成，打开工程可以看到如下内容： 可以看到，工程的根目录下多了三个东西：CocoaPodsDemo.xcworkspace、Podfile.lock文件和Pods目录。提示我们从现在起，我们需要使用CocoaPodsDemo.xcworkspace文件来进行开发。对于Podfile.lock需要了解几点： 1：第一次 pod install 时生成记录每个 Pod 版本 2：Podfile.lock 锁定当前各依赖库的版本之后 pod install 不会更改版本pod update 才会改版本 3：多人协作时防止第三方库升级时造成版本不一致 对于工程发生的变化，有几点需要理解：

1：第三方库会被编译成静态库供我们正真的工程使用 CocoaPods会将所有的第三方库以target的方式组成一个名为Pods的工程，该工程就放在刚才新生成的Pods目录下。整个第三方库工程会生成一个名称为libPods.a的静态库提供给我们自己的CocoaPodsTest工程使用。

2：我们的工程和第三方库所在的工程会由一个新生成的workspace管理 为了方便我们直观的管理工程和第三方库，CocoaPodsTest工程和Pods工程会被以workspace的形式组织和管理，也就是我们刚才看到的CocoaPodsTest.xcworkspace文件。 原来的工程设置已经被更改了，这时候我们直接打开原来的工程文件去编译就会报错，只能使用新生成的workspace来进行项目管理。 到这里CocoaPods的基本使用内容已经OK啦！然后了解一点相关内容。

正确编译运行一个包含CocoaPods类库的项目

如果一个项目中已经包含了CocoaPods的配置文件，但是编译却出现错误，那么我们仅需要一行命令就可以配置好所有的第三方类库了： pod update 如：编译运行出错,提示没有pod文件.只要打开终端  1)cd desktop 2)然后cd 对应工程名称 3)然后pod update  机会自动安装所有pod文件.

使用 pod install 还是 pod update，原文这里

许多人开始使用CocodPods的时候认为pod install只是你第一次用CocoaPods建立工程的时候使用，而之后都是使用pod update，但实际上并不是那会事。简单来说，就是： 1.使用pod install来安装新的库，即使你的工程里面已经有了Podfile，并且已经执行过pod install命令了；所以即使你是添加或移除库，都应该使用pod install。 2.使用pod update [PODNAME] 只有在你需要更新库到更新的版本时候用。 pod install 这个是第一次在工程里面使用pods的时候使用，而且每次你编辑你的Podfile（添加、移除、更新）的时候使用。 1：每次运行pod install命令的时候，在下载、安装新的库的同时，也会把你安装的每个库的版本都写在了Podfile.lock文件里面。这个文件记录你每个安装库的版本号，并且锁定了这些版本。 2：当你使用pod install，它只处理了pods的依赖，但是不会处理Podfile.lock文件。 对于在Podfile.lock里面所列出的pods，会下载在Podfile.lock里面明确的版本，并不会去检查是否该库有新的版本。 对于不在Podfile.lock里面的库，会找到Podfile里面描述对应版本（例如：pod "MyPod", "~>1.2"）。 pod outdated 当你运行pod outdated命令，CocoaPods会列出那些所有较Podfile.lock里面有新版本的库（那些当前被安装着的库的版本）。这个意思就是，如果你运行pod update PODNAME，如果这个库有新的版本，并且新版本仍然符合在Podfile里的限制，它就会被更新。 pod update

当你运行 pod update PODNAME 命令时，CocoaPods会帮你找到并更新到这个库的新版本，而不需要考虑Podfile.lock里面的限制，它会更新到这个库尽可能的新版本，只要符合Podfile里面的版本限制。

如果你运行pod update，后面没有跟库的名字，CocoaPods就会更新每一个Podfile里面的库到尽可能的最新版本。 正确用法： 你应该使用pod update PODNAME（库名）去只更新某个特定的库（检查是否有新版本，并尽可能更新到新的版本）。相反，使用pod install，这个命令不会更新那些已经安装了的库。

当你在你的Podfile里面添加了一个库的时候，你应该使用pod install，而不是pod update，这样既安装了这个库，也不需要去更新其它的已安装库。

你应该使用pod update去更新某个特定的库，或者所有的库（在Podfile的限制中）。 提交你的Podfile.lock文件： 在此提醒，即使你一向以来，不commit你的Pods文件夹到远程仓库，你也应该commit并push到远程仓库中。 要不然，就会破坏整个逻辑，没有了Podfile.lock限制你的Pods中的库的版本。 举例：以下会举例说明在各个场景下的使用。 场景1：User1创建了一个工程 User1创建了一个工程，并且想使用A、B、C这三个库，所以他就创建了一个含有这个三个库的Podfile，并且运行了pod intall。这样就会安装了A、B、C三个库到这个工程里面，假设我们的版本都为1.0.0。因此Podfile.lock跟踪并记录A、B、C这三个库以及版本号1.0.0。 注意：由于这个工程是第一次运行pod install，并且Pods.xcodeproj工程文件还不存在，所以这个命令也会同时创建Pods.xcodeproj以及.xcworkspace工程文件，这只是这个命令的一个副作用，并不是主要目的。 场景2：User1添加了一个库 之后，User1添加了一个库D到Podfile文件中。然后他就应该运行pod install命令了。所以即使库B的开发者发布了B的一个新版本1.1.0。但只要是在第一次执行pod install之后发布的，那么B的版本仍然是1.0.0。因为User1只是希望添加一个新库D，不希望更新库B。 这就是很多人容易出错的地方，因为他们在这里使用了pod update，因为想着“更新我的工程一个新的库而已”。这里要注意！ 场景3：User2加入到这个工程中 这时User2，一个之前没有参与到这个工程的人，加入了团队。他clone了一份仓库，然后使用pod install命令。Podfile.lock的内容就会保证User1和User2会得到完全一样的pods，前提是Podfile.lock被提交到git仓库中。 即使库C的版本已经更新到了1.2.0，User2仍然会使用C的1.0.0版本，因为C已经在Podfile.lock里面注册过了，C的1.0.0版本已经被Podfile.lock锁住了。 场景4：检查某个库的新版本 之后，User1想检查pods里面是否有可用的更新时，他执行了pod outdated，这个命令执行后，会列出来：B有了1.1.0版本，C有了1.2.0版本。这时候，User1打算更新库B，但不更新库C，所以执行pod update B，这样就把B从1.0.0更新到1.1.0（同时更新Podfile.lock里面对B的版本记录），此时，C仍然是1.0.0版本，不会更新。 在Podfile中使用明确版本还不够 有时人可能认为在Podfile中明确指定某个库的版本，例如：pod 'A', '1.0.0' ,足以保证所有项目里面的人都会使用完全一样的版本。这个时候，他们可能会觉得，此时如果添加一个新库的时候，我使用pod update并不会去更新其它的库，因为其它的库已经被限定了固定的版本号。但事实上，这不足以保证User1和User2的pods中库的版本会完全一样。 一个典型的例子是，如果库A有一个对库A2的依赖（声明在A.podspec中：dependency 'A2', '~> 3.0'），如果这样的话，使用 pod 'A', '1.0.0' 在你的Podfile中，的确会让User1和User2都使用同样版本的库A（1.0.0），然而： 1：最后User1可能使用A的依赖库A2的版本为3.4（因为3.4是当时User1使用的最新版本） 2：但是当User2使用的库A2版本是3.5（假设A2的开发者刚刚发布了A2的新版本3.5）。 所以只有一个方法来保证某项目的每个开发者都使用相同版本的库，就是每个电脑中都使用同样的Podfile.lock，并且合理使用pod install 和 pod update。

参考：

CocoaPods详解之——使用篇 CocoaPods安装和使用教程 http://cocoapods.org/ 用CocoaPods做iOS程序的依赖管理 深入理解 CocoaPods raywenderlich基本使用教程