Cocoapods 1.7.0 预览

原文连接

| 做者：Dimitris Koutsogiorgas

| 翻译：KANGZUBIN

上个月，CocoaPods 在发布了 1.6.0 正式版不久后，就立刻开始了 1.7.0 Beta 版的公测，它在先前版本重写底层架构的基础上进行了大量的扩展，是一次巨大更新。

本文将介绍 1.7.0 的几个新特性，主要总结自 CocoaPods 官方博文《CocoaPods 1.7.0 Beta!》，若有描述不当的地方，请查阅原文：

blog.cocoapods.org/CocoaPods-1…

支持多个 Swift 版本

在 CocoaPods 1.4.0 中首次引入的 swift_version 字段（用于指定 pod 库支持的 Swift 版本），现已被扩展成支持多个 Swift 版本。这对于 pod 库的做者来讲颇有帮助，同时也给 pod 库的使用者在选择使用哪一 Swift 版本时提供了更大的灵活性。

如今，pod 库的做者只需在其 podspec 配置文件中经过 swift_versions 字段指定其支持的 Swift 版本，便可实现该功能。

下面是一个 podspec 示例，指定了它支持的不一样 Swift 版本：

Pod::Spec.new do |spec|
  spec.name = 'CoconutLib'
  spec.version = '1.0'
  # ... rest of root spec entries go here
  spec.swift_versions = ['3.2', '4.0', '4.2']
end
复制代码

此时，除非 CoconutLib pod 库的使用者另有指定，不然 CocoaPods 将在安装过程当中自动选择最新版本的 Swift，在上述例子中为 4.2。

可是，在不少状况下，pod 的使用者并没有法使用最新的 Swift 版本，由于他们的开发工具链可能还不支持它。例如，在不支持 Swift 4 的旧版 Xcode 中打开的项目，将没法集成上述 CoconutLib pod 库，并最终会致使编译错误。为了解决这个问题，CocoaPods 1.7.0 提供了新的能力，即：可经过 supports_swift_versions 字段为 Podfile 文件中集成的每一个 target 指定所需的 Swift 版本。

例如：

target 'MyApp' do
  supports_swift_versions '>= 3.0', '< 4.0'
  pod 'CoconutLib', '~> 1.0'
end
复制代码

经过上述配置就能够成功集成 CoconutLib pod 库，并将使用 Swift 3.2 做为编译版本，由于它是惟一一个版本同时知足了 “MyApp target 定义中指定的版本要求” 和 “CoconutLib podspect 中声明的可支持的 Swift 版本列表”。

**注意：**咱们也能够在 Podfile 文件的根级别声明 supports_swift_versions 字段，此时它将做用于 Podfile 中声明的全部 targets。此外，对于嵌套的 targets（例如 test targets），其 Swift 版本要求将从其父级 targets 中继承，除非它们本身明确指定了。

在选择要使用的 Swift 版本时，可能会出现许多其余边缘状况（edge cases）。咱们建议你仔细阅读有关此更改的提案，以了解更多信息：

github.com/CocoaPods/C…

lint 时验证不一样 Swift 版本

Pod 库的做者一般很难维护他们的项目基础设施以支持 Swift 的多个版本（主要是对于较旧的版本），所以，在 lint CocoaPods 库时，默认将会选择最新的 Swift 版原本验证。

但对于那些拥有像 CI 系统等基础设施的 pod 库做者来讲，为了确保他们的 pod 库能够在旧版本的 Swift 下正常工做，在 lint 验证期间可使用 --swift-version 参数来指定 Swift 版本以覆盖默认值。

弃用 .swift-version 文件

到目前为止，大多数 pod 库做者都依赖于在其 repo 的根目录中指定一个 .swift-version 文件，以便于在成功发布 pod 库时声明他们所正式支持的 Swift 版本。可是，此信息不会在已发布的 podspec 中被转录，所以在集成期间，在选择要使用的 Swift 版本时，并不会考虑它。

这可能会致使许多问题，尤为是当新版本的 Swift 发布时，由于使用者可能会自动选择使用最新版本的 Swift，而此时 pod 做者还没来得及正式声明支持它。

咱们强烈建议 pod 库做者在其 podspec 文件中改为使用 swift_version 字段来声明他们官方支持的 Swift 版本。

咱们还建议删除 repo 中的 .swift-version 文件，除非您将其用于其余工具，例如 swiftenv。 swift_version 字段将始终优先于 .swift-version 文件。

最后，在 lint 时将会显示警告，提醒 pod 库的做者再也不使用 .swift-version 文件，而且在将来 CocoaPods 的更新版本中，咱们计划彻底取消对它的支持。

引入 App Specs

经过在 CocoaPods 1.3.0 中引入的 test specs，咱们能够在此基础上构建一个扩展平台，引入可由 pod 库做者来提供的不一样类型的配置说明（specifications）。在 1.7.0 版本中，咱们引入了 app apecs，容许 pod 库做者在其 podspec 中描述一个应用程序。

App specs 能够给做者带来不少帮助，例如，他们能够用于将一个示例应用与其 pod 库一块儿发布，做为使用者如何将其集成到各自应用程序的教程。

App specs 推动了“独立开发”的概念，其中，podspec 能够用做生成整个（可丢弃的）开发工做空间所需的惟一信息。

如下是 app specs 声明的示例：

Pod::Spec.new do |s|
  s.name         = 'CoconutLib'
  s.version      = '1.0'
  s.authors      = 'Coconut Corp', { 'Monkey Boy' => 'monkey@coconut-corp.local' }
  s.homepage     = 'http://coconut-corp.local/coconut-lib.html'
  s.summary      = 'Coconuts For the Win.'
  s.description  = 'All the Coconuts'
  s.source       = { :git => 'http://coconut-corp.local/coconut-lib.git', :tag => 'v1.0' }
  s.license      = {
    :type => 'MIT',
    :file => 'LICENSE',
    :text => 'Permission is hereby granted ...'
  }

  s.source_files = 'Sources/*.swift'

  s.app_spec 'SampleApp' do |app_spec|
    app_spec.source_files = 'Sample/*.swift'
  end  
end
复制代码

App specs 能够利用大多数 CocoaPods 支持的 spec DSL（特定领域语言，这里指 podspec 文件的语法）来声明依赖，编译配置项等。

默认状况下，app specs 不会自动集成到使用当前 pod 库的项目中。若是你但愿这样作，你能够在 Podfile 文件中指定，相似于 test specs：

target 'MyApp' do
  use_frameworks!
  pod 'CoconutLib', '~> 1.0', :appspecs => ['SampleApp']
end
复制代码

咱们但愿在将来可以将 app specs 提高到一个顶级（top-level）概念，在这个概念中，开发者的应用程序能够经过一个 app spec 来描述，这样仅经过 CocoaPods 集成就好，彻底不须要维护 .xcodeproj 了。

生成多个 Xcodeproj

在历史版本中，CocoaPods 老是生成一个 Pods.xcodeproj，它包含了编译项目所需的全部 targets 和 build settings。对于这种仅使用一个工程来集成整个 Podfile，通常比较适用于较小的项目。可是，随着项目的增加，Pods.xcodeproj 文件的大小也会随之增长。

Pods.xcodeproj 文件越大，Xcode 用于解析其内容的时间越长，这会下降 Xcode 的使用体验。咱们注意到，经过将每一个 pod 库集成为其本身单独的 Xcode project，并嵌套在顶级 Pods.xcodeproj 下，能够显著提升大型 CocoaPods 项目的性能，而不是把全部的 targets 都放到同一个 Xcode project 中。

此外，在大型代码库中，这项功能特别有用，由于开发人员能够选择仅打开他们须要处理的特定 .xcodeproj（位于 Pods/ 目录下），而不是打开整个工做空间（workspace），那样可能会减慢其开发过程。

不管是由于性能问题，仍是你仅是喜欢使用多个 Xcode projects 来设置 workspace，CocoaPods 如今支持使用 generate_multiple_pod_projects 安装选项来进行此设置。

你能够在 Podfile 文件中开启此功能，以下所示：

install! 'cocoapods', :generate_multiple_pod_projects => true
复制代码

默认状况下，此选项是关闭的，但咱们建议您尝试开启使用它，并向咱们报告您遇到的任何问题。咱们指望在未来对 CocoaPods 进行主要版本更新时，这将成为生成 workspace 时的默认选项。

下面咱们看一下它长什么样：

Without multi-xcodeproj (default):

With multi-xcodeproj:

**警告：**若是你项目中的 pods 依赖于使用引号语法来导入头文件，则将工程切换为使用多个 .xcodeproj 可能会致使一些编译错误。例如 #import "PDDebugger.h" 将再也不适用于依赖 PonyDebugger 的 pod 库，而应该改成：#import <PonyDebugger/PDDebugger.h>，以正确导入依赖的 framework 及其相关头文件。

增量安装

当执行 pod install 时，CocoaPods 如今支持仅从新生成自上次 install 以来发生更改的 pod 库，而不是像以前那样从新生成整个 workspace。根据项目的大小，这样作对于每一个 pod 库的 install 能够节省几秒到几分钟的时间。

你能够在 Podfile 文件中经过 incremental_installation 选项开启此功能，以下所示：

install! 'cocoapods',
         :generate_multiple_pod_projects => true,
         :incremental_installation => true
复制代码

**注意：**目前，incremental_installation 选项须要启用 generate_multiple_pod_projects 安装选项才能使其正常运行。

新增 scheme 字段

Pod 库的做者如今能够为他们的 specs，test specs 以及 app specs 自定义 scheme 的生成。目前支持指定环境变量和启动参数，并能够在未来轻松扩展。

举个例子：

Pod::Spec.new do |spec|
  spec.name = 'CoconutLib'
  spec.version = '1.0'
  # ... rest of root spec entries go here
  spec.test_spec 'Tests' do |test_spec|
    test_spec.source_files = 'Tests/**/*.swift'
    test_spec.scheme = { 
      :launch_arguments => ['Arg1', 'Arg2'], 
      :environment_variables => { 'Key1' => 'Val1'}
    }
  end
end
复制代码

以上示例将为 Tests test spec 生成以下 scheme：

**注意：**您能够选择为某一特定平台配置 scheme，例如，test_spec.ios.scheme 将仅为 iOS target 配置 scheme。

支持 .xcfilelist

在 CocoaPods 1.7.0 中，script phases 如今支持使用 .xcfilelist 来指定脚本的输入和输出路径。CocoaPods 将自动检测正在集成的 Xcode 项目是否支持 .xcfilelist，且其优先级高于单独设置的 input/output 路径条目。

这不但减小了 CocoaPods 在用户项目中占用的空间，并且也利用了在每种配置（例如 'Debug' 和 'Release'）中使用不一样 input/output 路径的能力。

实验特性

在 1.7.0 版本中还提供了一些使人兴奋且重要的实验特性。

为 Master Specs Repo 提供 CDN 支持

Master specs repo 对于 CocoaPods 的正常运行相当重要，可是，多年来，它的规模已经急剧增加，使其成为 CocoaPods 的第一大难题。

github.com/CocoaPods/S…

这对于那些网络链接速度较慢的人来讲尤为如此，由于这种状况下克隆整个 repo 及其完整提交历史几乎是不可能的。此外，因为克隆须要很长时间，CI 系统在首次设置时也会显著变慢。

在 1.7.0 中，咱们正在启动 CDN 支持，以免在本地机器或 CI 系统上克隆 master specs repo，让使用 CocoaPods 更加方便。这能够经过将 Podfile 中声明的 master specs repo 的source 替换为以下内容来实现：

# source 'https://github.com/CocoaPods/Specs' comment or remove this line.
source 'https://cdn.jsdelivr.net/cocoa/'
复制代码

此外，你能够经过执行 pod repo remove master 来删除现有基于 git 的 repo。

咱们要感谢 jsDelivr 对这项工做的支持和帮助！目前，咱们将继续保持这两种 master specs repo 的使用方式，但咱们强烈建议你切换成上述最新的 source，特别是对于首次使用 CocoaPods 来讲能够节省不少时间。

咱们将根据测试结果和服务的稳定性，但愿从 1.7.0 开始，CocoaPods 再也不须要用户克隆 master specs repo 才能正常使用。

为 Windows 系统提供支持

从 1.7.0 开始，咱们添加了对 Windows 系统的支持！咱们鼓励 Windows 用户使用 CocoaPods 并在 GitHub Issues 中向咱们报告任何问题：

github.com/cocoapods/c…

如何更新

CocoaPods 1.7.0 是一个很是使人兴奋的巨大版本更新，咱们建议您经过以下方式升级并参与测试：

$ gem install cocoapods --pre
复制代码

关注咱们

欢迎关注咱们的公众号：zsxjtip，也欢迎加入咱们的群组讨论问题。能够加微信 coldlight_hh/wsy9871 进入咱们的 iOS/flutter 微信群。