CocoaPods 1.7.0 release 最近已經發布,能夠跟着官方的文檔快速一覽。不會簡單的翻譯官方文檔,主要是跟着文檔談談本身的見解。html
另外一篇對官方文檔的翻譯swift
此次更新帶來不少內容,解決了很多痛點。 官方的說法是底層也作了不少優化。緩存
對於開發者本身的 Pod,若是對多個版本的 swift 作了適配,可使用該語法描述:ruby
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
複製代碼
Pod 在安裝 CoconutLib
時,會根據當前 Xcode 支持,選擇最新的版本。bash
若是但願某個 Target 使用指定的 swift 版本,Pod 也是支持的:app
target 'MyApp' do
supports_swift_versions '>= 3.0', '< 4.0'
pod 'CoconutLib', '~> 1.0'
end
複製代碼
Pod 對 Swift 多版本的支持,無疑給開發這帶來了福利。Pod 會根據 target 中指定的版本以及 CoconutLiub
spec 自己所支持的 swift 版本,一塊兒決策出最終使用的 swift 版本。ide
supports_swift_versions 這個 DSL 能夠寫在 Podfile 中,會被認爲全部的 target 都使用。post
這個主要是爲了服務與 CI/CD 。 不少超級工程都是一個 projecet + 多個 target 編譯。 若是在編譯多個 target 以前就能經過 Lint 檢查出 Pod 的問題,那麼就避免同時編譯多個 target ,又同時由於同一個問題失敗,浪費大量 CI 時間。性能
在原來,若是想要了解某個 Pod 怎麼使用,咱們須要去單獨編譯它的 Example 工程。 如今 Pod 內置了 app_spec DSL。
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
複製代碼
若是想要集成 SampleApp 進來,只需以下這般:
target 'MyApp' do
use_frameworks!
pod 'CoconutLib', '~> 1.0', :appspecs => ['SampleApp']
end
複製代碼
相比較以前的新特性,這個特性無疑給超級 App 帶來了更多的方便。 當 App 工程變得超級龐大時,上百個 pod 都集成在同一個 Pod Project 中。pod.proj 文件愈來愈大,會帶來極大的性能消耗。
使用 generate_multiple_pod_projects
選項,可讓 Pod 爲每個 Pod 單獨生成一個 pod.proj 工程。
總體的編譯結構,是 main project 依賴 Pod Project ,而後 Pod Project 依賴於單獨的 Pod。
首先是帶來的編譯緩存,好比單獨更新了 Moya Pod 中的文件,從新 install 會比較快一些。
另外一個好處,我只想要看 Moya 中的代碼時,能夠不用打開完整的工程。
不過 CocoaPods 的緩存會帶來一些莫名其妙的 Bug,這個特性用於正式的工程仍是太激進,能夠如今 Side Project 中嘗試。等 1.7.0 release 以後,能夠慢慢嘗試。
通常而言,如今的 App 都是用 Development Pods 拆分單獨的業務組件進行開發,這種將組件進行一步獨立,也便於在代碼中防止下級引用上級。能保證每個單獨的組件真正的 獨立 起來。
這個特性是基於 multi project 的,由於只有使用 multi project,才能將每一個 Pod 單獨分開,在編譯過程當中不相互依賴,從而實現增量安裝。
Pod Install 的時間消耗,不只是在開發過程當中消費大量時間,同時也是 CI 的時間瓶頸,目前業內基本是經過 Pod Binary 的方式,減小 Pod 的編譯時間,不過 Pod Binary 在開發過程當中,仍有很多問題存在,好比 Assert 被忽略,沒法提早發現問題。
相信這個特性能夠給開發者帶來福音。
每一個 Pod 都會生成對應的 Xcode WorkSpace Scheme,雖然開發者通常不會去使用和配置,不過這個 scheme 特性,做爲官方的支持仍是要方便一些。
目前支持指定環境變量和啓動參數,以後會繼續拓展。
Example:
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
複製代碼
scheme DSL 也是支持 platform 的,也就是支持爲 iOS、macOS、watch OS、tvOS 設置不一樣的 scheme。
目前看來,可能只有在 Test Spec 和 App Spec 上才能用獲得。
.xcfilelist
文件沒有用過,cocoapod 如今支持在 Script Phase 階段使用 .xcfilelist
。
至關因而腳本執行的文件輸入輸出路徑也可使用變量,以方即可以減小重複文件的佔用。 另外一方面,變量天然也支持 Debug、Release、Alpha 等不一樣配置下用不一樣的值,也算是拓展性加強吧。
爲 Master Specs Repo 提供 CDN 支持。
這個特性對於大一點的 App 貌似也沒什麼用,一方面,公司內部會維護一個對應的 Master,或者直接將使用到的第三方庫的 podsepc 放在公司平臺上。
尤爲是在對第三方庫進行 Binary 後,通常不多直接去使用 Master 了。
Cocoapod 做爲 iOS 開發目前的事實標準,得益於其開源特性和方便的可拓展性,不少公司都會對其進行定製,Cocoapods 有不少坑被開發者踩到,不少大公司內部也是對 Pod 有專門的團隊去負責開發拓展。
雖然 Pod 有些地方挺坑的,但做爲事實標準,開發者仍是不得不去學習並正確使用它。
很惋惜的是,國內的大廠都去使用它,而且開發了不少私有的拓展用於工程中,卻沒有提交 PR 去支持這個開源項目。