上文讲过,在开始使用CocoaPods,执行完pod install之后,会生成一个Podfile.lock文件。这个文件看起来跟我们关系不大,实际上绝对不应该忽略它。
PODS: - AFNetworking (2.1.0): - AFNetworking/NSURLConnection - AFNetworking/NSURLSession - AFNetworking/Reachability - AFNetworking/Security - AFNetworking/Serialization - AFNetworking/UIKit - AFNetworking/NSURLConnection (2.1.0): - AFNetworking/Reachability - AFNetworking/Security - AFNetworking/Serialization - AFNetworking/NSURLSession (2.1.0): - AFNetworking/NSURLConnection - AFNetworking/Reachability (2.1.0) - AFNetworking/Security (2.1.0) - AFNetworking/Serialization (2.1.0) - AFNetworking/UIKit (2.1.0): - AFNetworking/NSURLConnection - Reachability (3.0.0) - SBJson (4.0.0) DEPENDENCIES: - AFNetworking (~> 2.0) - Reachability (~> 3.0.0) - SBJson (~> 4.0.0) SPEC CHECKSUMS: AFNetworking: c7d7901a83f631414c7eda1737261f696101a5cd Reachability: 500bd76bf6cd8ff2c6fb715fc5f44ef6e4c024f2 SBJson: f3c686806e8e36ab89e020189ac582ba26ec4220 COCOAPODS: 0.29.0Podfile.lock文件最大得用处在于多人开发。对于没有在Podfile中指定Pods依赖库版本的写法,如下:
pod 'SBJson'该句话用于获取当前SBJson这个Pods依赖库的最新版本。
在这种情况下,如果团队想使用当前最新版本的SBJson依赖库,有两种方案:
鉴于Podfile.lock文件对团队协作如此重要,我们需要将它添加到版本管理中。
对于普通用户来说,使用CocoaPods我们打交道最多的就是Podfile文件。CocoaPods是用ruby实现的,因此Podfile文件的语法就是ruby的语法。接着从以下几个方面来介绍Podfile:
这是在上篇文章中,遗留的一个问题。通常情况下我们都推荐Podfile文件都放在工程根目录,如下图所示:
xcodeproj "/Users/wangzz/Desktop/CocoaPodsTest/CocoaPodsTest.xcodeproj" platform :ios pod 'Reachability', '~> 3.0.0' pod 'SBJson', '~> 4.0.0' platform :ios, '7.0' pod 'AFNetworking', '~> 2.0'指定路径使用的是xcodeproj关键字。
此后,进入Podfile文件所在路径,执行pod install命令就会和之前一样下载这些Pods依赖库,而且 生成的相关文件都放在了Podfile所在目录下面, 如下图:
和之前一样,我们仍然需要使用这里生成的workspace文件打开工程。
Podfile本质上是用来描述Xcode工程中的targets用的 。如果我们不显式指定Podfile对应的target,CocoaPods会创建一个名称为default的隐式target,会和我们工程中的第一个target相对应。换句话说, 如果在Podfile中没有指定target,那么只有工程里的第一个target能够使用Podfile中描述的Pods依赖库。
如果想在一个Podfile中同时描述project中的多个target,根据需求的不同,可以有不同的实现方式。为了说明问题,在原来的工程中再创建一个名称为Second的target,现在的project中包含的target有:
①多个target中使用相同的Pods依赖库
link_with 'CocoaPodsTest', 'Second' platform :ios pod 'Reachability', '~> 3.0.0' pod 'SBJson', '~> 4.0.0' platform :ios, '7.0' pod 'AFNetworking', '~> 2.0'这种写法就实现了CocoaPodsTest和Second两个target共用相同的Pods依赖库。
②不同的target使用完全不同的Pods依赖库
target :'CocoaPodsTest' do platform :ios pod 'Reachability', '~> 3.0.0' pod 'SBJson', '~> 4.0.0' platform :ios, '7.0' pod 'AFNetworking', '~> 2.0' end target :'Second' do pod 'OpenUDID', '~> 1.0.0' end
其中,do/end作为开始和结束标识符。
pod 'AFNetworking' //不显式指定依赖库版本,表示每次都获取最新版本 pod 'AFNetworking', '2.0' //只使用2.0版本 pod 'AFNetworking', '> 2.0' //使用高于2.0的版本 pod 'AFNetworking', '>= 2.0' //使用大于或等于2.0的版本 pod 'AFNetworking', '< 2.0' //使用小于2.0的版本 pod 'AFNetworking', '<= 2.0' //使用小于或等于2.0的版本 pod 'AFNetworking', '~> 0.1.2' //使用大于等于0.1.2但小于0.2的版本 pod 'AFNetworking', '~>0.1' //使用大于等于0.1但小于1.0的版本 pod 'AFNetworking', '~>0' //高于0的版本,写这个限制和什么都不写是一个效果,都表示使用最新版本
根据Podfile文件指定的内容,安装依赖库,如果有Podfile.lock文件而且对应的Podfile文件未被修改,则会根据Podfile.lock文件指定的版本安装。
每次更新了Podfile文件时,都需要重新执行该命令,以便重新安装Pods依赖库。
若果Podfile中指定的依赖库版本不是写死的,当对应的依赖库有了更新,无论有没有Podfile.lock文件都会去获取Podfile文件描述的允许获取到的最新依赖库版本。
$ pod search OpenUDID后面的OpenUDID为参数。
-> OpenUDID (1.0.0) Open source initiative for a universal and persistent UDID solution for iOS. pod 'OpenUDID', '~> 1.0.0' - Homepage: http://OpenUDID.org - Source: https://github.com/ylechelle/OpenUDID.git - Versions: 1.0.0 [master repo]这里我们搜到了一条可用数据,里面描述了OpenUDID库的简要信息。其实我们真正需要的是上述结果中的第三行:
pod 'OpenUDID', '~> 1.0.0'不难看出,这是我们需要添加到Podfile文件中的。
有了这条命令,就可以方便、迅速地找到需要的Pods依赖库。