集成指令和最佳实践。
1 将Pods添加到Xcode工程
在你开始前
- 检查确保你要用到的Specs仓库或者cocoapods.org是可用的。
- 将CocoaPods安装到你的电脑。
1.1 安装
- 创建一个Podfile文件,然后添加你的依赖:
target ‘MyApp’ do
pod 'AFNetworking', '~> 3.0' pod 'FBSDKCoreKit', '~> 4.9'
end
- 在你的工程目录下运行$ pod install。
- 打开App.xcworkspace并进行构建。
1.2 创建带CocoaPods的新Xcode工程
按照以下步骤创建带CocoaPods的新工程:
- 照常在Xcode中创建一个新工程。
- 打开终端窗口,并且$ cd进入你的工程目录。
- 创建一个Podfile。可以通过运行$ pod init完成创建。
- 打开Podfile。第一行应该指明支持的平台和版本。
platform :ios, ‘9.0’
- 为了使用CocoaPods,你需要定义Xcode目标以连接它们。因此,例如,如果你要写一个iOS应用,它应该是你应用的名字。创建一个目标章节,写入target ‘$TARGET_NAME’ do,并在几行之后写一个end。
- 通过在目标块内部一个单独的行指明pod ‘$PODNAME’添加一个CocoaPod。
target ‘MyApp’ do
pod 'ObjectiveSugar'
end
- 保存Podfile。
- 运行$ pod install。
- 打开创建的MyApp.xcworkspace。这就是你每天都要用到的来创建app的文件。
1.3 集成到一个已存在的工作空间
将CocoaPods集成到一个已存在的工作空间需要在你的Podfile中额外的添加一行。在你的目标块之外简单的指明.xcworkspace文件,如:
workspace ‘MyWorkspace’
2 何时使用pod install 和 pod update?
许多人会将何时使用pod install和何时使用pod update混淆。特别是,他们经常在使用pod install的地方使用了pod update。
你可以在给出的引导中找到关于何时使用哪一个以及每个命令的期望用途是什么的详细的解释。
3 是否应该将Pods目录提交到源码管理中?
是否将Pods文件夹提交取决于你自己,随着工程的不同而不同。我们推荐你将Pods目录保持在源码管理中,而不要添加到你的.gitignore中。但是这个决定最终还是取决于你自己:
3.1 提交Pods目录的好处
- 在克隆仓库之后,工程可以立即编译运行,甚至不需要再计算机上安装CocoaPods。不需要运行pod install,也不需要连接网络。
- Pod工件(代码和库)总是可用的,即使Pod的来源(如GitHub)已经挂了。
- Pod工件可以保证跟克隆仓库之后的初始安装一模一样。
3.2 忽略Pods目录的好处
- 源码管理仓库会更小,使用更少的空间。
- 只要源(如GitHub)是可用的,CocoaPods通常可以重新建立相同的安装。(保证这一点的技术是在没有提交SHA到Podfile时运行pod install获取和重建相同的工件。这在使用Podfile中的压缩文件时相当正确。)
- 在执行源码管理操作时不会有任何要处理的冲突,例如合并有不同Pod版本的分支。
无论你是否提交Pods目录,Podfile和Podfile.lock应该总保持在版本管理中。
4 什么是Podfile.lock?
这个文件在第一次运行pod install之后生成,它会跟踪已安装的每一个Pod的版本。例如,假设在Podfile中指定了如下依赖:
pod ‘RestKit’
运行pod install将会安装RestKit的当前版本,这将会生成一个Podfile.lock文件指明已安装的准确版本(例如RestKit 0.10.3)。由于Podfile.lock文件,在往后的时间点在不同的设备上对这个假设的工程运行pod install仍然会安装RestKit 0.10.3,即使有新版本可用了。CocoaPods会还原Podfile.lock中的Pod版本,除非Podfile中的依赖已经更新或者调用了pod update(这会生成一个新的Podfile.lock文件)。通过这种方式,CocoaPods避免了由于依赖的库的未知变更带来的头疼问题。
下面是来自谷歌的视频,介绍了这是如何工作的: “CocoaPods and Lockfiles (Route 85)”。
5 在下面的场景中发生了什么?
直接参考ruby 源码,在Xcode中它:
- 创建或更新一个工作空间。
- 如有必要将你的工程添加到这个工作空间。
- 如有必要 将CocoaPods静态库工程添加到这个工作空间。
- 添加libPods.a到targets => build phases => link with libraries。
- 添加CocoaPods的Xcode配置文件到你的app工程中。
- 修改你app中基于CocoaPods的目标配置。
- 添加一个构建阶段以便从每个安装的pods拷贝资源到你的app包中。换句话说,在所有其他构建阶段之后有一个如下的“脚本构建阶段”:
- Shell: /bin/sh
- Script: ${SRCROOT}/Pods/PodsResources.sh
注意如果CocoaPods静态库已经在你的工程中,第3步以前可能会被跳过。这大部分是基于Jonah Williams关于Static Libraries的工作。
6 Pods and Submodules Pods和子模块
CocoaPods和git子模块试图解决非常类似的问题。他们都力争简化将第三方代码引入你的工程的步骤。子模块连接到工程的特定提交,而CocoaPod绑定了开发者发布的版本。
6.1 从子模块切换到CocoaPods
在你决定完全切换到CocoaPods之前,你当前使用的所有库都是可用的。记录下当前使用的库的版本也是个好主意,这样就可以使用相同的库安装CocoaPods。也可以逐渐完成切换,一个接一个的依赖,而不是做大的移动。
原文链接:《Using CocoaPods》