原文連接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
在 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)。咱們建議你仔細閱讀有關此更改的提案,以瞭解更多信息:
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 的更新版本中,咱們計劃徹底取消對它的支持。
經過在 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
了。
在歷史版本中,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 對於 CocoaPods 的正常運行相當重要,可是,多年來,它的規模已經急劇增加,使其成爲 CocoaPods 的第一大難題。
這對於那些網絡鏈接速度較慢的人來講尤爲如此,由於這種狀況下克隆整個 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
才能正常使用。
從 1.7.0 開始,咱們添加了對 Windows 系統的支持!咱們鼓勵 Windows 用戶使用 CocoaPods 並在 GitHub Issues 中向咱們報告任何問題:
CocoaPods 1.7.0 是一個很是使人興奮的巨大版本更新,咱們建議您經過以下方式升級並參與測試:
$ gem install cocoapods --pre
複製代碼
歡迎關注咱們的公衆號:zsxjtip,也歡迎加入咱們的羣組討論問題。能夠加微信 coldlight_hh
/wsy9871
進入咱們的 iOS
/flutter
微信羣。