深入浅出学习cocoapods

最近工程项目开始3.0大版本，使用cocoapods来管理依赖。今天学习了cocoapods的原理和使用方式，从我自己学习和理解的经验来看，从以下的先后顺序来阅读比较清楚。

一、cocoapods安装和使用教程

CocoaPods是什么？

当你开发iOS应用时，会经常使用到很多第三方开源类库，比如JSONKit，AFNetWorking等等。可能某个类库又用到其他类库，所以要使用它，必须得另外下载其他类库，而其他类库又用到其他类库，“子子孙孙无穷尽也”，这也许是比较特殊的情况。总之小编的意思就是，手动一个个去下载所需类库十分麻烦。另外一种常见情况是，你项目中用到的类库有更新，你必须得重新下载新版本，重新加入到项目中，十分麻烦。如果能有什么工具能解决这些恼人的问题，那将“善莫大焉”。所以，你需要 CocoaPods。

CocoaPods应该是iOS最常用最有名的类库管理工具了，上述两个烦人的问题，通过cocoaPods，只需要一行命令就可以完全解决，当然前提是你必须正确设置它。重要的是，绝大部分有名的开源类库，都支持CocoaPods。所以，作为iOS程序员的我们，掌握CocoaPods的使用是必不可少的基本技能了。

如何下载和安装CocoaPods？

在安装CocoaPods之前，首先要在本地安装好Ruby环境。至于如何在Mac中安装好Ruby环境，请google一下，本文不再涉及。

假如你在本地已经安装好Ruby环境，那么下载和安装CocoaPods将十分简单，只需要一行命令。在Terminator（也就是终端）中输入以下命令（注意，本文所有命令都是在终端中输入并运行的。什么，你不知道什么是终端？那请小编吃饭，小编告诉你）：

sudo gem install cocoapods

但是，且慢。如果你在天朝，在终端中敲入这个命令之后，会发现半天没有任何反应。原因无他，因为那堵墙阻挡了cocoapods.org。（你会问，我靠，这都要墙！是的，小编也纳闷。）

但是，是的，又但是（不过是个可喜的“但是”）。我们可以用淘宝的Ruby镜像来访问cocoapods。按照下面的顺序在终端中敲入依次敲入命令：

$ gem sources --remove https://rubygems.org///等有反应之后再敲入以下命令$ gem sources -a http://ruby.taobao.org/

为了验证你的Ruby镜像是并且仅是taobao，可以用以下命令查看：

$ gem sources -l

只有在终端中出现下面文字才表明你上面的命令是成功的：

*** CURRENT SOURCES ***http://ruby.taobao.org/

上面所有的命令完成之时，在小编的终端上是这个的样子：

这时候，你再次在终端中运行：

$ sudo gem install cocoapods

等上十几秒钟，CocoaPods就可以在你本地下载并且安装好了，不再需要其他设置。

敲入以上命令时，小编终端上是这个样子的（由于太长，仅截取前面一部分）：

看到这里，你心里会不会说，我靠！太爽了，这么容易就可以下载并且安装好了！是的，小编也是这么想的。CocoPods就是这么简单，使用也十分简单。继续往下看吧。

如何使用CocoaPods？

好了，安装好CocoPods之后，接下来就是使用它。所幸，使用CocoPods和安装它一样简单，也是通过一两行命令就可以搞定。

小编在这里用两种使用场景来具体说明如何使用CocoaPods。

场景1：利用CocoaPods，在项目中导入AFNetworking类库

AFNetworking类库在GitHub地址是：https://github.com/AFNetworking/AFNetworking

为了确定AFNetworking是否支持CocoaPods，可以用CocoaPods的搜索功能验证一下。在终端中输入：

$ pod search AFNetworking

过几秒钟之后，你会在终端中看到关于AFNetworking类库的一些信息。比如：

这说明，AFNetworking是支持CocoaPods，所以我们可以利用CocoaPods将AFNetworking导入你的项目中。

首先，我们需要在我们的项目中加入CocoaPods的支持。你可以跟随小编的步骤，先利用Xcode创建一个名字CocoaPodsDemo的项目，用于以下的教程。创建好之后，在继续下一步之前，小编先截图，看看项目没有支持CocoaPods时的项目Xcode目录结构：

上图等一下要跟项目支持CocoaPods之后的项目Xcode目录结构做对比。

你看到这里也许会问，CocoaPods为什么能下载AFNetworking呢，而不是下载其他类库呢？这个问题的答案是，有个文件来控制CocoaPods该下载什么。这个文件就叫做“Podfile”（注意，一定得是这个文件名，而且没有后缀）。你创建一个Podfile文件，然后在里面添加你需要下载的类库，也就是告诉CocoaPods，“某某和某某和某某某，快到碗里来！”。每个项目只需要一个Podfile文件。

好吧，废话少说，我们先创建这个神奇的PodFile。在终端中进入（cd命令）你项目所在目录，然后在当前目录下，利用vim创建Podfile，运行：

$ vim Podfile

然后在Podfile文件中输入以下文字：

platform :ios, '7.0'pod "AFNetworking", "~> 2.0"

注意，这段文字不是小编凭空生成的，可以在AFNetworking的github页面找到。这两句文字的意思是，当前AFNetworking支持的iOS最高版本是iOS 7.0, 要下载的AFNetworking版本是2.0。

然后保存退出。vim环境下，保存退出命令是：

:wq

这时候，你会发现你的项目目录中，出现一个名字为Podfile的文件，而且文件内容就是你刚刚输入的内容。注意，Podfile文件应该和你的工程文件.xcodeproj在同一个目录下。

这时候，你就可以利用CocoPods下载AFNetworking类库了。还是在终端中的当前项目目录下，运行以下命令：

$ pod install 

因为是在你的项目中导入AFNetworking，这就是为什么这个命令需要你进入你的项目所在目录中运行。

运行上述命令之后，小编的终端出现以下信息：

EricmatoMacBook-Pro:CocoaPodsDemo ericwang$ pod installAnalyzing dependenciesDownloading dependenciesInstalling AFNetworking (2.0.2)Generating Pods projectIntegrating client project[!] From now on use `CocoaPodsDemo.xcworkspace`.

注意最后一句话，意思是：以后打开项目就用 CocoaPodsDemo.xcworkspace 打开，而不是之前的.xcodeproj文件。

你也许会郁闷，为什么会出现.xcodeproj文件呢。这正是你刚刚运行$ pod install命令产生的新文件。除了这个文件，你会发现还多了另外一个文件“Podfile.lock”和一个文件夹“Pods”。 点击 CocoaPodsDemo.xcworkspace 打开之后工程之后，项目Xcode目录结构如下图：

你会惊喜地发现，AFNetwoking已经成功导入项目了（红框部分）！

现在，你就可以开始使用AFNetworking.h啦。可以稍微测试一下，在你的项目任意代码文件中输入：

#import <AFNetworking.h>或者#import "AFNetworking.h"

然后编译，看看是否出错。如果你严格按照小编上述的步骤来，是不可能出错的啦。

至此，CocoPods的第一个应用场景讲述完毕。别看小编写了这么多，其实过程是十分简单的。总结一下就是：

1. 先在项目中创建Podfile，Podfile的内容是你想导入的类库。一般类库的原作者会告诉你导入该类库应该如何写Podfile；
2. 运行命令：`$ pod install.

下面，小编继续讲述第二种使用场景。

场景2：如何正确编译运行一个包含CocoPods类库的项目

你也许曾经遇到过（特别是新手iOS开发者）这种情况，好不容易在GitHub上找到一份代码符合自己想需求，兴冲冲下载下来，一编译，傻眼了，发现有各种各样错误。一看，原来是缺失了各种其他第三方类库。这时候莫慌，你再仔细一看，会发现你下载的代码包含了Podfile。没错，这意味着你可以用CocoaPods很方便下载所需要的类库。

下面，小编以代码 UAAppReviewManager 为例来说明如何正确编译运行一个包含CocoPods类库的项目。

UAAppReviewManager是一个能够让你方便地将提醒用户评分的功能加入你的应用中。当你去UAAppReviewManager的GitHub地址下载这份代码之后，打开Example工程（UAAppReviewManagerExample），编译，你会发现Xcode报告一大堆错误，基本都是说你编译的这份代码找不到某某头文件，这就意味着你要成功编译UAAppReviewManager的Example代码，必须先导入一些第三方类库。同时你会发现在UAAppReviewManagerExample文件夹下面有三个跟CocosPods相关的文件（文件夹）：Podfile，Podfile.lock和Pods，如下图：

用

这时候，打开终端，进入UAAppReviewManagerExample所在的目录，也就是和Podfile在同一目录下，和场景1一样，输入以下命令（由于已经有Podfile，所以不需要再创建Podfile）：

$ pod update

过几秒（也许需要十几秒，取决于你的网络状况）之后，终端出现：

Analyzing dependenciesFetching podspec for `UAAppReviewManager` from `../`Downloading dependenciesInstalling UAAppReviewManager (0.1.6)Generating Pods projectIntegrating client project[!] From now on use `UAAppReviewManagerExample.xcworkspace`.

这时候，再回到UAAppReviewManagerExample文件夹看一看，会看到多了一个文件UAAppReviewManagerExample.xcworkspace：

根据终端的信息提示，你以后就需用新产生的UAAppReviewManagerExample.xcworkspace来运行这个Example代码了。

打开UAAppReviewManagerExample.xcworkspace，编译运行，成功！如下图：

注意，这里有个小问题，如果刚刚你不是输入$ pod update，而是输入$ pod install，会发现类库导入不成功，并且终端出现下面提示：

[!] Required version (UAAppReviewManager (from `../`)) not found for `UAAppReviewManager`.Available versions: 0.1.6

这里的意思大概是Podfile文件过期，类库有升级，但是Podfile没有更改。$ pod install只会按照Podfile的要求来请求类库，如果类库版本号有变化，那么将获取失败。但是 $ pod update会更新所有的类库，获取最新版本的类库。而且你会发现，如果用了 $ pod update，再用 $ pod install 就成功了。

那你也许会问，什么时候用 $ pod install，什么时候用 $ pod update 呢，我又不知道类库有没有新版本。好吧，那你每次直接用 $ pod update 算了。或者先用 $ pod install，如果不行，再用 $ pod update。

二、如何编写pod的spec文件

pod命令：

$ pod list# 列出所有可用的第三方库

$ pod search query

搜索名称包含query的类库，query可以替换为你想搜索的名字（如json)，不区分大小写。也可以使用pod search --full query命令作更仔细的搜索，该命令不但搜索类库的名称，同时还搜索类库的描述文本，所以搜索速度也相对慢一些。

pod list和pod search命令只搜索存在于本地~/.cocoapods文件夹的所有第三方库，并不会连接到远程服务器。如果你要从服务器更新本地第三方库的描述文件，可以:

$ pod repo update master

创建自己项目的Podspec描述文件

CocoaPods还是一个相对年轻的项目，所有的项目的Podspec文件都托管在https://github.com/CocoaPods/Specs。可能有一些库并未收录其中。下面我们通过为微博sso认证登录库编写Podspec文件来学习相关的概念。

初始化一个Podspec文件

$ pod spec create weibo_ios_sdk_sso-oauth

该命令将在本目录产生一个名为weibo_ios_sdk_sso-oauth.podspec的文件。用编辑器打开该文件，里面已经有非常丰富的说明文档。下面我们介绍如何声明第三方库的代码目录和资源目录，还有该第三方库所依赖ios核心框架和第三方库。

去除所有的注释，podspec文件如下所示:

Pod::Spec.new do |s|  s.name     = 'ADVProgressBar'  s.version  = '0.0.1'  s.license  = 'MIT'  s.summary  = 'Progress Bar Design with Percentage values.'  s.homepage = 'https://github.com/appdesignvault'  s.author   = { 'appdesignvault' => 'appdesignvault' }  s.source   = { :git => 'https://github.com/appdesignvault/ADVProgressBar.git', :commit => 'f17b15c15574d6d101cd5fcfd58239e16e806647' }  s.platform = :ios    s.source_files = 'ADVProgressBar/Classes/*.{h,m}'  s.resources = "ADVProgressBar/Resources/*.png"  s.framework = 'UIKit'  s.requires_arc = true  end

其中s.name和s.summary用来声明库的名称和一个简短的说明文档。pod search命令就是根据这两项内容作为搜索文本的。s.homepage声明库的主页，s.version库原代码的版本，s.license所采用的授权版本，s.author库的作者。

s.source 声明原代码的地址，以微博sso认证登录库为例，它托管在https://github.com/mobileresearch/weibo_ios_sdk_sso-oauth中，在其未尾加上.git扩展名就是库的原代码地址了，所以该行应声明为:

s.source = { :git => 'https://github.com/mobileresearch/weibo_ios_sdk_sso-oauth.git'}

对于很多第三方库而言，在发布的时候都会打上一个tag，如版本0.0.1就会打上一个名为v0.0.1的tag，但是weibo_ios_sdk_sso-oauth库还未打上所何tag，我们可以选择一个最新的commit来作为该库0.0.1版的代码。s.source最终如下：

s.source = { :git => 'https://github.com/mobileresearch/weibo_ios_sdk_sso-oauth.git', :commit => '68defea78942ecc782ffde8f8ffa747872af226d'}

以后我们可以根据该库不同的版本创建相应的podspec文件，例如0.0.2，0.1.0等。

让我们在浏览器中看一下weibo_ios_sdk_sso-oauth的目录结构:

--|+-- demo|+-- src|+-- .gitignore|+-- README.md

demo目录保存一个示例项目，src才是库的原代码目录。src的目录结构如下:

-- src    |    +-- JSONKit    |    +-- SinaWeibo    |    +-- sinaweibo_ios_sdk.xcodeproj    |    +-- SinaWeibo-Prefix.pch

JSONKit目录说明这个库本身依赖于JSONKit第三方库。我们可以在podspec文件中的s.dependency声明段中声明。SinaWeibo目录才是包含所有原代码的目录，我们需要在s.source_files中声明

s.source_files = 'src/SinaWeibo/*.{h,m}'

前一部分src/SinaWeibo/是一个相对目录，目录的层级关系一定要跟代码库的保持一致。最后一部分*.{h,m}是一个类似正则表达式的字符串，表示匹配所有以.h和.m为扩展名的文件。

src/SinaWeibo/目录下还有一个SinaWeibo.bundle目录，该目录存放一些资源文件（如图片等），这些文件并不需要进行编译。可以使用s.resourcs声明

s.resources = "src/SinaWeibo/SinaWeibo.bundle/**/*.png"

前一部分跟上面相同，**表示匹配所有子目录，*.png表示所有以.png为扩展名的图片文件。

通过查看代码我们知道，weibo_ios_sdk_sso-oauth还依赖一个ios的核心库QuartzCore

s.framework = 'QuartzCore'

在前面我们已经说过，weibo_ios_sdk_sso-oauth库自身也依赖于另外一个第三方库JSONKit，声明如下:

s.dependency 'JSONKit', '~> 1.4'

这行声明与Podfile文件中的声明类似。

最终的结果如下：

Pod::Spec.new do |s|  s.name         = "weibo_ios_sdk_sso-oauth"  s.version      = "0.0.1"  s.summary  = 'weibo.com sso oauth, 微博sso认证登录功能'  s.homepage     = "https://github.com/mobileresearch/weibo_ios_sdk_sso-oauth"  s.license      = 'MIT'  s.author       = {'mobileresearch' => 'mobileresearch'}  s.source       = { :git => 'https://github.com/mobileresearch/weibo_ios_sdk_sso-oauth.git', :commit => '68defea78942ecc782ffde8f8ffa747872af226d' }  s.platform = :ios  s.source_files = 'src/SinaWeibo/*.{h,m}'  s.resources = "src/SinaWeibo/SinaWeibo.bundle/**/*.png"  s.framework  = 'QuartzCore'  s.dependency 'JSONKit', '~> 1.4'end

可以将该spec文件保存到本机的~/.cocoapods/master/目录中仅供自己使用，也可以将其提交到CocoaPods/Specs代码库中。下面我们将其保存到本机中

$ mkdir -p ~/.cocoapods/master/weibo_ios_sdk_sso-oauth/0.0.1$ cp weibo_ios_sdk_sso-oauth.podspec ~/.cocoapods/master/weibo_ios_sdk_sso-oauth/0.0.1

是否可以通过搜索找到该库:

$ pod search weibo

同样在需要依赖于weibo_ios_sdk_sso-oauth这个库的项目，可以将下列添加到项目的Podfile文件中

pod 'weibo_ios_sdk_sso_oauth', '0.0.1'

保存文件，并用pod install安装weibo_ios_sdk_sso-oauth库。

三、深入理解cocoapod

Cocoapods是 OS X 和 iOS 下的一个第三方库管理工具。你能使用CocoaPods添加被称作“Pods”的依赖库，并轻松管理它们的版本，而不用考虑当前的时间和开发环境。

CocoaPods会生成一个{project name}.xcworkspace项目文件，在workspace里面包含两个项目，一个是我们的主项目，一个是pods项目。CocoaPods将所有的依赖库都放到另一个名为Pods项目中，然后让主项目依赖Pods项目，源码管理工作都从主项目移到了Pods项目中。Pods项目最终会编译成一个名为libPods.a的文件，主项目只需要依赖这个.a文件即可。对于资源文件，CocoaPods提供了一个名为Pods-resources.sh脚本，该脚本在每次项目编译的时候都会执行，将第三方库的各种资源文件复制到目标目录中。CocoaPod还通过一个名为Pods.xcconfig的文件来在编译时设置所有的依赖和参数。

Cocoapods意义体现在两个方面。首先，引入第三方库无可避免地要进行各种各样的配置。对于Objective-C的初级开发者来说，项目配置可是一件艰巨的任务。在配置编译阶段和链接器选项的过程中，极有可能引入许多人为的错误。而CocoaPods简化了这一切，它能自动配置编译选项，拯救了开发者。

其次，使用CocoaPods可以很方便地查找新的第三方库。当然，这可不是说让你七拼八凑别人代码而开发出一个“移栽”应用。而是让你找到真正好用的库，缩短你的开发周期，提升你的代码质量。

接下来，我们将通过分析pod安装的过程，一步步揭示CocoaPods背后的技术。

 

核心组件

CocoaPods是用ruby写的，并划分成了若干个Gem包。CocoaPods在解析执行过程中最重要的几个包的路径分别是：CocoaPods/CocoaPods、 CocoaPods/Core 和 CocoaPods/Xcodeproj。

CocoaPods / CocoaPod

这是面向用户的组件，每当你执行一个pod命令时，这个组件将被激活。它包括了所有实用CocoaPods的功能，并且还能调用其他gem包来执行任务。

CocoaPods / Core

Core gem提供了与CocoaPods相关的文件（主要是Podfile和podspecs）的处理。

Podfile

Podfile用于配置项目所需要的第三方库。它能被高度定制，所以你可以尽可能地给它添加你想要的特性。如果您还想对Podfile了解更多的话，请查看Podfile指南(地址 http://guides.cocoapods.org/syntax/podfile.html)。

Podspec

.podspec文件描述了一个库将怎样被添加进工程中。.podspec文件可以标识该第三方库所需要的源码文件、依赖库、编译选项，以及其他第三方库需要的配置。

CocoaPods / Xcodeproj

这个包负责工程文件直接关系的处理。它能创建以及修改.xcodeproj文件和.xcworkspace文件。它也可以作为一个独立的包使用，当你要编写修改项目文件的脚本时，可以考虑使用CocoaPods/Xcodeproj。

 

运行 pod install 命令

pod install的执行引发了很多操作。了解底层运行过程最简单的方式就是给pod install语句添加 –verbose 参数。现在，运行

1

podinstall--verbose

将会出现以下执行结果：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

Analyzing dependencies

 

Updating spec repositories

Updating spec repo `master`

$/usr/bin/gitpull

Already up-to-date.

 

Finding Podfile changes

- AFNetworking

- HockeySDK

 

Resolving dependencies of `Podfile`

Resolving dependencies fortarget `Pods' (iOS 6.0)

- AFNetworking (= 1.2.1)

- SDWebImage (= 3.2)

- SDWebImage/Core

 

Comparing resolved specification to the sandbox manifest

- AFNetworking

- HockeySDK

 

Downloading dependencies

 

-> Using AFNetworking (1.2.1)

 

-> Using HockeySDK (3.0.0)

- Running pre installhooks

- HockeySDK

 

Generating Pods project

- Creating Pods project

- Adding sourcefiles to Pods project

- Adding frameworks to Pods project

- Adding libraries to Pods project

- Adding resources to Pods project

- Linking headers

- Installing libraries

- Installing target `Pods-AFNetworking` iOS 6.0

- Adding Build files

- Adding resource bundles to Pods project

- Generating public xcconfig fileat `Pods/Pods-AFNetworking.xcconfig`

- Generating private xcconfig fileat `Pods/Pods-AFNetworking-Private.xcconfig`

- Generating prefix header at `Pods/Pods-AFNetworking-prefix.pch`

- Generating dummy sourcefileat `Pods/Pods-AFNetworking-dummy.m`

- Installing target `Pods-HockeySDK` iOS 6.0

- Adding Build files

- Adding resource bundles to Pods project

- Generating public xcconfig fileat `Pods/Pods-HockeySDK.xcconfig`

- Generating private xcconfig fileat `Pods/Pods-HockeySDK-Private.xcconfig`

 

 - Generating prefix header at `Pods/Pods-HockeySDK-prefix.pch`

 

- Generating dummy sourcefileat `Pods/Pods-HockeySDK-dummy.m`

- Installing target `Pods` iOS 6.0

- Generating xcconfig fileat `Pods/Pods.xcconfig`

- Generating target environment header at `Pods/Pods-environment.h`

- Generating copy resources script at `Pods/Pods-resources.sh`

- Generating acknowledgements at `Pods/Pods-acknowledgements.plist`

- Generating acknowledgements at `Pods/Pods-acknowledgements.markdown`

- Generating dummy sourcefileat `Pods/Pods-dummy.m`

- Running post installhooks

- Writing Xcode project fileto `Pods/Pods.xcodeproj`

- Writing Lockfile in`Podfile.lock`

- Writing Manifest in`Pods/Manifest.lock`

Integrating client project

整个过程中执行了很多操作，不过把它们分解之后，会发现它们都很简单。让我们逐步来分析。

阅读Podfile文件

你是否吐槽过Podfile的语法太过诡异，其实这是ruby的语法而不是OC。相较而言，Podfile要比现有的其他格式更加简单好用一些。

安装的第一步是要弄清楚哪些第三方库被显式或隐式地声明了。CocoaPods加载podspecs文件时，获取了第三方库的名称及版本列表。Podsspecs文件存储在本地，路径为~/.cocoapods。

版本控制和冲突

CocoaPods使用语义版本命名约定来解决对版本的依赖。由于冲突解决系统建立在非重大更改的补丁版本之间，这使得解决依赖关系要容易得多。举个栗子，两个完全不同的第三方库同时依赖CocoaLumberjack。它们其中一个依赖的版本是2.3.1，而另一个则为2.3.3，解析器可以自动使用较新的版本，在这里则是2.3.3，因为这可以与2.3.1向后兼容。

但这并不总是有效。有许多第三方库还并不支持这个约定，这让解决方案变得非常复杂。

当然，总是会有一些冲突需要手工解决。如果一个第三方库依赖CocoaLumberjack 1.2.5，而另一个依赖CocoaLumberjack 2.3.1，最后只能靠调用这两个第三方库的用户来手动地决定CocoaLumberjack的版本了。

加载源码

CocoaPods执行的下一个步骤是加载源代码。每个.podspec文件都包含了源代码的索引，这些索引一般指向了一个git地址或者git tag。它们以commit SHA码的方式存储在 ~/Library/Caches/CocoaPods中。而在这些路径中创建文件则由 Core 包负责。

源代码将依照Podfile、.podspec和缓存文件的信息下载到相应的第三方库路径。

生成Pods.xcodeproj

每次pod install 执行后并且检测到改动时，Pods.xcodeproj文件将呗Xcodeproj gem更新。如果Pods.xcodeproj文件不存在，则会以默认配置生成，若已存在，则Pods.xcodeproj会使用现有的配置。

安装第三方库

当Cocoapods向项目中增加了一个第三方库的时候，不仅仅是将添加代码这么简单。由于每个第三方库有不同的target，所以每次添加第三方库时，都只有几个文件被添加。每个源代码都需要：

• 一个包含编译选项的.xcconfig文件
• 一个同时拥有编译设置和CocoaPods默认配置的私有.xcconfig文件
• 编译所必须的prefix.pch文件
• 另一个编译必须的文件dummy.m

一旦每个pod的target都完成了以上步骤，整个Pods的Target就会被创建。这增加了相同的文件，与另外几个。如果有源代码中包含了资源bundle，向app的target中添加bundle的方式将写入Pods-Resources.sh。还有一个叫Pods-environment.h的文件，文件中含有许多检查组件是否来自pod的宏定义。最后，将生成两个确认文件，一个.plist文件，一个用于给用户查阅许可信息的markdown文件。

写入到磁盘

直到现在，许多已完成的过程都使用的是内存中的对象。为了让这些过程的结果可重复被使用，我们需要将所有结果都记录在一个文件中。所以Pods.xcodeproj和另外两个非常重要的文件：Podfile.lock和Manifest.lock都将被写入磁盘。

Podfile.lock

这是CocoaPods创建的最重要的文件之一。它记录了需要被安装的pod的每个已安装的版本。如果你想知道已安装的pod是哪个版本，可以查看这个文件。推荐将Podfile.lock文件加入到版本控制中，这有助于整个团队的一致性。

Manifest.lock

这是每次运行pod install时创建的Podfile.lock文件的副本。如果你见过“沙盒文件和Podfile.lock文件不同步”的错误，这个错误就是因Manifest.lock文件和Podfile.lock文件不一样引起。由于Pods所在的目录并不总在版本控制之下，这样可以保证开发者运行app之前都能更新他们的pods，否则app可能会crash，或者在一些不太明显的地方编译失败

xcproj

如果您已经依照我们的建议在系统上安装了xcproj，它会将您的Pods.xcodeproj文件转换成就旧有ASCII格式的plist文件。为什么要这么做呢？因为Xcode所依赖和使用的plist在很久以前就已经不被其他软件支持了。如果没有xcproj，你的Pods.xcodeproj文件将会以XML格式的plist文件存储，当你用Xcode打开它时，它会被改写，造成大量的文件冲突。

 

运行结果

运行pod install的最终结果是许多文件被添加到你的工程和系统中。这个过程通常只需要几秒钟。当然没有Cocoapods这些事也都可以完成。只不过所花的时间就不仅仅是几秒而已了。

四、查看项目结构，更深入理解