Cocoapods 1.7.0 預覽

原文連接html

| 做者:Dimitris Koutsogiorgasios

| 翻譯:KANGZUBINgit

上個月,CocoaPods 在發佈了 1.6.0 正式版不久後,就立刻開始了 1.7.0 Beta 版的公測,它在先前版本重寫底層架構的基礎上進行了大量的擴展,是一次巨大更新。github

本文將介紹 1.7.0 的幾個新特性,主要總結自 CocoaPods 官方博文《CocoaPods 1.7.0 Beta!》,若有描述不當的地方,請查閱原文:swift

blog.cocoapods.org/CocoaPods-1…xcode

支持多個 Swift 版本

在 CocoaPods 1.4.0 中首次引入的 swift_version 字段(用於指定 pod 庫支持的 Swift 版本),現已被擴展成支持多個 Swift 版本。這對於 pod 庫的做者來講頗有幫助,同時也給 pod 庫的使用者在選擇使用哪一 Swift 版本時提供了更大的靈活性。ruby

如今,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 文件,除非您將其用於其餘工具,例如 swiftenvswift_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 reposource 替換爲以下內容來實現:

# 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 微信羣。

相關文章
相關標籤/搜索