CocoaPods 深入浅出 - 业务开发篇

点 击 关 注   “ 微 店 技 术 团 队 ” ， 阅 读 更 多 技 术 干 货

前言

在日常的 iOS 开发工作中，业务开发人员要不断跟随 app 业务功能迭代，不断聚焦在持续优化产品功能上，而大型项目的依赖管理基本都是采用 CocoaPods ，如果对  CocoaPods 工程依赖相关操作不够熟练，就会导致工程初始化的各种问题，在开发中也会带来蹩脚的开发体验，为了让业务交付更加流畅、迅速，下面从业务开发人员日常的开发流程入手，详细介绍如下  CocoaPods 命令。

• init - 在工程  xcodeproj 目录生成  Podfile 配置文件

• install - 根据  Podfile.lock 指定版本，安装工程依赖

• outdated - 检查当前工程过期的依赖库

• update - 更新依赖库，并创建新的  Podfile.lock

• deintegrate - 让已经用  CocoaPods 管理的项目，解除 CocoaPods 的配置

使用讲解

CocoaPods 的基本使用流程就像玩游戏一样，也自己的逻辑闭环。一般大家刚开始玩游戏的时候都要创建自己的角色，在这里就是用 pod init 来初始化  CocoaPods 配置文件  Podfile ；然后需要为自己的角色买些装备，在这里就是  pod install 安装需要的依赖库；当然在玩游戏的过程中装备要不断的升级，在这里就要用  pod outdated 和  pod update 来完成依赖库的更新操作；当你把这个游戏玩通关了就想退出这个游戏，在这里就可以用 pod deintegrate 来取消使用  CocoaPods

下面我们以一个实际的案例来演示具体的操作步骤和注意事项：

1. 创建  HelloCocoaPods 示例工程

2. 初始化  Podfile

3. 在  Podfile 中添加如下常用依赖库

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

target 'HelloCocoaPods' do
  # Comment the next line if you don't want to use dynamic frameworks
  use_frameworks!

  # Pods for HelloCocoaPods

  pod 'AFNetworking'
  pod 'Masonry'
  pod 'SDWebImage'
  pod 'SVProgressHUD'

4. 执行  pod install

5. 打开工程进行开发

6. 检查依赖库是否有更新版本

业务开发人员在开发一段时间后，有时候一些第三方库或者公司内部的一些组件修复了一些 bug ，那就需要更新这些依赖库，怎么才能检测到依赖库有版本更新呢？ CocoaPods 提供了  pod outdated 命令。

从上面的命令行输出可以看出， pod outdated 会首先更新  repo 仓库，然后检测已经安装的依赖库是否有版本更新，并用  绿 、 蓝 、 红 是三种颜色来表示当前的  Podfile 配置是否可以更新到相应版本。

注意：这里如果在检查更新的时候更新 repo 仓库，可以执行： pod outdated --no-repo-update

7. 升级依赖库

上面检测到依赖库有版本更新后，业务开发人员就要根据实际情况来更新，推荐的做法是执行 pod update your_library (--no-repo-update) ，这里比方说我更新下  SDWebImage 。

Podfile.lock
pod install

8. 提交代码到  git 仓库

在提交代码到 git 仓库的时候，要注意本地生成三方库的 Pods目录是不需要提交到远端 git 仓库中的，主要有两个原因：

• 提交 Pods 文件夹到远端会给 git 仓库带来很多不必要的文件管理的成本，会给后续 CI、CD 流程带来麻烦

• 每次 pod install 完之后 Pods 文件夹中的文件可能会变动，会导致一些不必要的代码文件冲突，给正常的业务代码提交带来困扰

9. 还原工程到初始状态

有些项目可能有还原工程到初始化状态的需求，比方说：改用 Carthage 或者组件打包的时候有自己的构建流程等，这时候可以执行 pod deintegrate 来完成该操作。

以上流程基本覆盖了业务开发人员经常使用的命令，但是对于业务开发人员只知道这些命令还不够，还需要为自己的业务配置好 Podfile 文件，才能更好的迭代开发业务，那么下面就带大家一起玩转  Podfile 。

玩转  Podfile

Podfile 定义

一般情况下，一个 Podfile 文件的标准定义如下：

platform :ios, '9.0'
inhibit_all_warnings!

target 'MyApp' do
  pod 'ObjectiveSugar', '~> 0.5'

  target 'MyAppTests' do
    inherit! :search_paths
    pod 'OCMock', '~> 2.0.1'
  end
end

post_install do |installer|
  installer.pods_project.targets.each do |target|
    puts "#{target.name}"
  end
end

Podfile 配置案例实战

随着工程配置越来越复杂，依赖的库越来越多，就需要在 Podfile 种加入很多额外的配置项，下面就根据一些具体场景案例来讲解下  Podfile 的各种配置方法。

CASE 1：当工程中有很多个 Target ，比方说有主  Target 还有一些其他的  Extension 的  Target , 这时候它们需要依赖一些共同的库，该怎么配置  Podfile 呢?

这里推荐使用 target 或者  abstract_target 来完成配置，官方示例如下：

# Note: There are no targets called "Shows" in any of this workspace's Xcode projects
abstract_target 'Shows' do
  pod 'ShowsKit'

  # The target ShowsiOS has its own copy of ShowsKit (inherited) + ShowWebAuth (added here)
  target 'ShowsiOS' do
    pod 'ShowWebAuth'
  end

  # The target ShowsTV has its own copy of ShowsKit (inherited) + ShowTVAuth (added here)
  target 'ShowsTV' do
    pod 'ShowTVAuth'
  end

  # Our tests target has its own copy of
  # our testing frameworks, and has access
  # to ShowsKit as well because it is
  # a child of the abstract target 'Shows'

  target 'ShowsTests' do
    inherit! :search_paths
    pod 'Specta'
    pod 'Expecta'
  end
end

CASE 2：在业务开发过程中， Podfile 有时候写  tag ，有时候写  branch ，有时候还写  path ，有时候还能写  commit ，他们分别在什么场景下使用？

pod 'AFNetworking'
pod 'AFNetworking', '3.2.1'
pod 'AFNetworking', :git => '<https://github.com/gowalla/AFNetworking.git>', :branch => 'dev'
pod 'AFNetworking', :path => '~/Documents/AFNetworking'

以上是根据 AFNetworking 列出的几种使用场景，当然这里不局限于这一个库，其他库也是一样的，下面逐一说明区别：

• 第一种是通用用法，也是比较推荐的用法， CocoaPods 会自动帮你找到最新版本的依赖库，然后安装

• 第二种用法，是在某些库需要指定到某个特定功能版本的时候，才进行版本指定，一般情况下不推荐使用

• 第三种用法，一般是某些依赖库在某个特性分支开发完成了，需要与其他业务人员进行联调，这个时候可能该库还有一些 bug , 无法打  tag 执行发布操作

• 第四种用法，业务开发人员可能用的少一些，一般是组件开发人员将自己开发库所在的 podspec 文件所在的位置用  path 进行指定，方便自测所用

CASE3：有些组件库，没有好的迭代更新节奏，版本号发布规则也是各不相同，这时候必须要指定版本，怎么办呢？

其实 CocoaPods 官方已经给出了比较规范的版本号规则，如下：

里面给出了 语义化 版本的概念，并给出了链接 语义化版本 2.0.0 | Semantic Versioning，组件和业务开发人员建议还是要仔细阅读下这个版本规范，毕竟  约定由于配置 ，在这里其实  CocoaPods 还列出了一些版本号的限定规则，如下：

• = 0.1 （使用 0.1 版本）

• 0.1 （使用大于 0.1 的任何版本，不包含 0.1）

• = 0.1 （使用大于等于 0.1 的任何版本，包含 0.1）

• < 0.1 （使用低于 0.1 的第一个最大版本，不包括 0.1）

• <= 0.1 （使用小于等于 0.1 的第一个最大版本，包括 0.1）

• ~> 0.1.2 （在 [0.1.2, 0.2) 之间的版本，不包括 0.2，等同于 >=0.1.2 and < 0.2.0）

• ~> 0.1.3-beta.0 （大于等于 0.1.3 的 beta 或者是 release版本，最大到 0.2，包括 0.2，这里的 - 后面的内容不会进行版本比较）

CASE4：工程中的 Podfile 里开始的地方有  source 和  plugin 这两个配置，是用来干什么的？

• source 一般  source '<https://github.com/artsy/Specs.git' > 这样来用，这说明公司内部有自己的  repo 仓库，这里的地址就是  repo 仓库的  git 地址，会在后续组件开发部分详细介绍如何制作自己的  repo 仓库。

• plugin 是用来  hook CocoaPods 的执行流程的，CocoaPods Guides - How to use CocoaPods plugins 这篇官方文章介绍了一些  plugin 的发展历程，具体如何编写  plugin 会在后续章节详细介绍。

CASE 5：业务开发人员有时候需要对 Pods 工程的  build settings 进行修改，如果手动修改每次  pod install 完成后就被覆盖了，该怎么办？

这种情况最好的解决办法就是用 post_install ，在  pod_install 中可以取到  Pods 工程下的所有  target , 然后可以对  config 进行设定，这样做就不用害怕每次执行命令的时候会被覆盖了，示例如下：

pod 'AFNetworking'

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['GCC_ENABLE_OBJC_GC'] = 'supported'
    end
  end
end

注意：在编辑 Podfile的时候，推荐使用 Sublime，Visual Studio Code 这种代码编辑器来进行更改，一是编辑的时候会有代码高亮，看着比较舒服，二是可以避免出现标点符号一会中文、一会英文的问题Podfile 里写的库，是指当前工程需要依赖的库，如果有隔级依赖的情况，比方说 HelloCocoaPods -> A库 -> B库 -> C库，那么在 Podfile 中不建议把 A, B, C 三个库都写上，更不提倡在 Podfile 里写上 B,C 库，然后把 A 库的代码拖到工程里，这样其实已经破坏了 CocoaPods 的依赖关系，尤其是组件开发人员，在发布自己的组件到 repo 仓库的时候，很有可能还要重新调整一遍代码结构，以保障业务开发人员能够使用，合理的做法是在 Podfile 中只写 A 库 的依赖，其他依赖关系，有各自库的组件开发人员保障，所以还是建议在组件开发的时候大家都遵循 CocoaPods 的标准。

CASE 6：在 pod install 的时候，可能会出现错误提示： 当前的依赖的库的版本与 Podfile.lock 中的不一致 ，该怎么处理？

这种情况下，大部分开发者很可能直接删掉 Podfile.lock ，然后重新  pod install 了，出现这种情况的原因，就是别的业务开发人员更新了一些组件，然后把  Podfile.lock 提交到  git 仓库，然后你更新下来，这个时候你本地的  repo 仓库，很有可能没有更新，也就是没有一些库的最新版本，这种情况如果再碰上比较着急的需求，一般业务开发人员也就是直接删掉  Podfile.lock 然后重新  pod install ,再把自己的  Podfile.lock 文件传上去，但这时候问题就出现了，刚才对这些组件升级的业务开发人员做的工作相当于被回退了，正确的做法是执行  pod install --repo-update ，那肯定有些人会说不把  Podfile.lock 放入  git 仓库，不就没这个问题了；那紧接着问题就来了，那在  app 发布的时候，如何才能打  tag 锁定当前依赖库的版本呢？难道还要自己维护个版本号的表，一个个的对或者在  Podfile 里把所有库都指定上版本，如果那样做已经完全违背了  CocoaPods 的设计理念。

综上所述，针对业务开发人员，给出如下建议：

• 如果使用了 CocoaPods ，那就不要使用手动配置  Xcode build settings 的操作，拥抱  Podfile 来配置

• Podfile.lock 一定要提交到  git 仓库，这是官方标准做法，可以省去很多其他繁琐配置流程

• 给出一个 Podfile 版本号指定规则： 能不指定就不指定，能指定区间的就不指定具体的，迫不得已才指定具体版本

• Podfile 或者  Podfile.lock 文件的改动最好由  Team leader 一人进行修改，其他人按照  Podfile.lock 进行安装即可，这样可以有效避免混乱

One More Thing

在 CocoaPods 1.7.0 版本里， pod install 加入了  --deployment 选项，也是为了防止在上线的时候  Podfile 或者  Podfile.lock 进行了改动，导致上线的产品无法与预期相符，如果改动了会有如下错误警告：

参考链接

语义化版本 2.0.0 | Semantic Versioning:  https://semver.org/lang/zh-CN/