CocoaPods导入与使用及常见错误处理

创建日期: 2020年1月7日
安装环境：
macOS Mojave 10.14.6
Xcode Version 11.3 beta
网络：日本东京

cocoapods

一. 安装Pod

1.检查pod是否存在

$ pod --version
//运行结果：-bash: pod: command not found

pod不存在。如果显示pod的版本信息，则

2.我们选用gem来安装CocoaPods，先判断gem是否存在

$ gem --version
//运行结果：2.5.2.3

gem存在。
更新gem版本，

$ sudo gem update --system

如果结果正确，可直接跳到【3.通过gem安装CocoaPods】

运行结果

出错，解决办法：

方法一：重新再执行一次这个指令

方法二： High Sierraでcocoapodsが使えなくなった時にやったこと

我用方法一后，成功了。

如果gem不存在，先安装gem，具体手顺，参考下面链接。
https://juejin.im/post/5d2ed9b0f265da1b971aa8f3

3.通过gem安装CocoaPods

$ sudo gem install -n /usr/local/bin cocoapods

因为要sudo，会要求输入电脑密码。

4.安装成功与否以及版本确认

$ pod --version
//运行结果：1.8.4

安装成功。

5.更新Podspec索引文件,创建本地索引库

$ pod setup

这个过程需要花费些时间，如果没有报错，就说明一切安装成功了。

我在运行该指令的时候，发现没有反应，调查后，又修改了文章，升级了gem。因为在国外，不涉及被墙的问题。如果在国内，参考：pod 安装 pod setup 没有反应

二. 使用

1.创建新项目时，添加CocoaPods

//打开项目文件夹
$ cd Sample
//制作Podfile
$ pod init

运行上面的命令之后，你的文件夹会多出一个Podfile文件，主要配置了你所需要的第三方库及其版本信息。
如果你不习惯使用vi编辑器，可以直接在pod init之后，打开项目文件夹，直接双击Podfile文件，如果你电脑上有相应的工具，可以直接可视化修改。自动生成的Podfile内容大概是这样的

$ cat Podfile
# Uncomment the next line to define a global platform for your project
# platform :ios, '9.0'

target 'Sample' do
  # Comment the next line if you're not using Swift and don't want to use dynamic frameworks
  use_frameworks!

  # Pods for Sample

end

Pod 引入第三方库的语法格式
Pod '[第三方库名]', '~> [版本号]'
第二个参数版本号，可以不添加，中括号要去掉。
我们以Swift的数据库处理的第三方库GRDB为例子，Podfile文件内容如下：

# Uncomment the next line to define a global platform for your project
platform :ios, '9.0'

target 'DBReader' do
  # Comment the next line if you don't want to use dynamic frameworks
  use_frameworks!
  pod 'GRDB.swift', '~> 0'

end

下面是podfile指定版本号时的逻辑运算符：
Besides no version, or a specific one, it is also possible touse logical operators:

'> 0.1' Any version higher than 0.1 0.1以上
'>= 0.1' Version 0.1 and any higher version 0.1以上，包括0.1
'< 0.1' Any version lower than 0.1 0.1以下
'<= 0.1' Version 0.1 and any lower version 0.1以下，包括0.1
In addition to the logic operators CocoaPods has an optimisicoperator ~>:

'~> 0.1.2' Version 0.1.2 and the versions up to 0.2, not including 0.2 and higher 0.2以下(不含0.2)，0.1.2以上（含0.1.2）
'~> 0.1' Version 0.1 and the versions up to 1.0, not including 1.0 and higher 1.0以下(不含1.0)，0.1以上（含0.1）
'~> 0' Version 0 and higher, this is basically the same as not having it. 0和以上，等于没有此约束。 逻辑运算符原文链接

2.引入第三方库

//进入项目文件夹
$ cd Sample
$ pod install
$ pod update

pod install的时候，会在你的项目工程中引入你podfile文件里配置的第三方文件库，并且生成三个文件：

• 和项目工程命名一样的.xcworkspace，之后启动项目要双击这个，而非之前的.xcodproj文件。
• Podfile.lock文件，主要是你所安装的pod的版本信息
• Pods文件夹，里面是你安装的第三方库

3.验证第三方库引入是否成功

双击Sample.xcworkspace,进入项目工程，在你需要的.swift文件中import 你要用的库，然后运行程序，如果没有报错，恭喜你，引用第三方库基本成功了。

三. 常见错误及解决方式

1.第三方库报错

一般,从远程仓库下拉的代码，运行出现第三方库报错时，先尝试云心pod install，再运行pod update试一下。

2.直接download的项目工程，没有关联git。运行pod update时，出错：

image

调查的解决方案：https://github.com/CocoaPods/CocoaPods/issues/9254 看 **dnkoutso **的

我的解决方案：因为上来就运行pod update，没有运行pod install造成的。具体原因，原理，之后调查。

之后，用git clone下代码后，直接运行pod update，可以成功。

四。常用命令（待补充...)

1.如何查看引用的版本？
podfile.lock文件，显示了该app使用的库的framework的版本。

五. 正确的使用pod install 和 pod update

转载链接

pod install

1. 在项目中第一次使用CocoaPods, 进行安装的时候使用这个命令.
2. 在Podfile中增加或删除某个pod后, 也是使用这个命令. 而不是pod update.

• 每次运行pod install命令, 下载并安装新的pod时, 它会为Podfile.lock文件中的每个pod写入已安装的版本. 此文件跟踪每个pod的已安装版本并锁定这些版本(.lock命名因此而来).
• 当运行pod install，它只解析Podfile.lock中尚未列在其中的pod的依赖库.
  • 对于已经在Podfile.lock中列出的pod, Podfile.lock不会尝试检查是否有更新的版本.
  • 对于尚未在Podfile.lock中列出的pod, 会搜索与Podfile（如中所述pod ‘MyPod’, ‘~>1.2’）匹配的版本或最新的版本.

注: 第一次运行pod install的时候, .xcworkspace项目和Pods目录还不存在, pod install命令也会创建.xcworkspace和Pods目录, 但这是pod install命令的顺带作用，而不是它的主要作用.

pod outdated

当运行pod outdated时, CocoaPods将列出所有比Podfile.lock（每个pod当前安装的版本）中, 已经列出的版本更新的pod版本. 这意味着如果你在这些pod上运行pod update PODNAME, 它将会把指定的pod更新到最新版本.

pod update

当运行pod update PODNAME时, CocoaPods将尝试查找PODNAME更新的pod版本, 会忽略掉Podfile.lock中已经存在的版本.

如果直接运行pod update, 没有指定PODNAME, CocoaPods会把Podfile中所有的pod都更新到最新版本.(如果已经是最新版本了, 则不更新)

预期用途

使用pod update PODNAME, 将只能更新特定的pod(检查是否存在新版本并相应地更新pod). 相反, pod install不会尝试更新已安装的pod的版本.

当向Podfile中添加一个pod时, 应该运行pod install, 而不是用pod update来安装这个新pod.

只有在想要更新特定pod（或所有的pod）的版本时才会使用pod update.

必须提交的Podfile.lock

有时候可能你不想提交Pods目录到源代码管理中. 但是在多人开发的情况下, 一定要提交Podfile.lock这个文件, 因为这个文件里面记录了你的Podfile中所有pod的版本信息. 为避免你的Podfile中的pod版本和别人的Podfile中的pod发生版本不一样的情况, 而导致出现函数找不到或者其他的错误.

场景示例

1. user1创建了项目

user1创建了一个项目, 并且想用A, B, C这3个pod库, 这个时候用pod install安装了这些pod库, 并且假设这3个库的版本号都是1.0.0, 这些版本号等信息会记录在Podfile.lock文件中.

1. user1添加了新的pod

根据项目的进度需求, 添加了D这个pod库到项目中, 这个时候应该使用pod install去安装D这个库到项目中, 即使在添加D这个库之前, B的版本被维护者更新到了1.1.0, 使用pod install也只会安装D这个库到项目中, 而不会去帮你更新B的版本. 从而不会出现因为B的版本更新后, 假如某些函数过期了, 或者某些函数被移除了, 而导致你被迫需要修改项目代码.

1. user2加入到项目中

假设团队中新增加了一位基友user2, 他克隆了项目, 并且pod install. (前提是你没有把Pods目录添加到源代码管理中), 如果你将Podfile.lock提交到了版本控制. 那么基友安装后的pod会和你的一模一样, 不会出现他的pod版本比你的高. 即便现在C的版本更新到了1.2.0, 基友安装的也是1.0.0版本. 因为在Podfile.lock中记录的pod C就是1.0.0版本.

1. 检查pod的新版本

后来, user1想要检查下是否有更新pod的版本. 运行pod outdated, 会告诉你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确切的版本, 像pod 'A', '1.0.0', 就足以保证每一个人和其他人都会有相同的版本. 然后他们甚至可以使用pod update, 即使只是添加一个新的pod, 认为它永远不会有更新其他pod版本的风险, 因为它们在Podfile中被固定到了一个特定的版本.

但事实上, 这还不足以保证我们上面场景中的user1和user2, 始终获得所有pod的完全相同的版本. 举一个典型的例子, 如果pod A中有对pod A2的依赖, 在A.podspecas中声明dependency 'A2', '~> 3.0'. 在这种情况下，pod 'A', '1.0.0'在你的Podfile中使用的时候, 确实会强制user1和user2始终使用A 1.0.0 的pod版本.

但是: user1最终可能获取到的A2版本是pod 3.4(因为那时A2是最新版本), 当user2在以后加入项目时运行pod install, 他可能会在A2的版本中获得pod 3.5(因为维护者A2可能在此期间发布了新版本).

这就是为什么为了确保在每个团队成员使用的每台电脑上, 所有相同的pod版本的唯一方法, 是使用Podfile.lock和正确使用pod install和pod update的原因.

我应该将Pods目录添加到源代码管理中吗？

是否将Pods文件夹添加到源代码管理中都取决于你，因为工作流程因项目而异. 我们建议您将Pods目录保留在源代码管理下, 不要将其添加到您的.gitignore. 但最终这个决定取决于你:

添加Pod目录的好处

• 克隆了repo后, 即使没有在机器上安装CocoaPods, 项目也可以立即构建和运行. 无需运行pod install, 也无需Internet连接.
• Pod（代码/库）总是可用的, 即使Pod的源（例如GitHub）要关闭也是如此.
• 在克隆repo后, Pod组件保证与原始安装中的组件相同.

忽略Pods目录的好处

• 源代码仓库将更小, 并且占用更少的空间.
• 只要所有Pod的源（例如GitHub）都可用, CocoaPods通常能够重新创建相同的安装.（从技术上讲, 无法保证pod install在Podfile中不使用提交SHA时, 运行将获取并重新创建相同的组件. 在Podfile中使用zip文件时尤其如此.）
• 执行源控制操作时不会有任何冲突, 例如合并具有不同Pod版本的分支.

无论你是否在忽略Pods目录, Podfile并Podfile.lock应始终版本控制下保持