今天又折騰了下 Swift 包管理。
目前是用 CocoaPods,其實也沒太大問題,但總覺得 對程式碼的侵入太強。這不,iPaste for iOS 起了個新專案,想換個清爽點的,於是就又折騰了下。
除了 Pod,主要有 2 個選擇:Carthage 和 Swift Package Manager. 後者現在還太嫩,僅適合 Swift 專案,很多第三方並不支援,遂放棄。
那就來到了 Carthage;其實 Carthage 並不複雜,實質是下載第三方庫的原始碼、本地編譯為 Frameworks. 剩下的事情,就要開發者自己手動操作了。其實手動也沒什麼,就是把 Frameworks 作為 Linked Frameworks 加入專案中,並在編譯時複製入 .app.
為什麼不用 Embeded 方式呢?因為畢竟第三方庫是會變的,如果用 Embeded 相當於寫死了版本,後續升級時有些麻煩。當然,也是可行的。
這裡就可以看出 Pod 和 Carthage 的二點不同:
- Pod 實質是使用原始碼整合
- 好處:在寫程式碼時可以方便跳轉至第三方庫的原始碼中
- 壞處:編譯速度慢,尤其是全新編譯或打包時
- Carthage 實質是使用 Framework 整合
- 好處與壞處,正好與 Pod 相反
- 不過,在整合 dYMS 後,也可以在除錯期間跳入第三方庫的原始碼中,但依然不能在寫程式碼時跳轉
Carthage 這裡有個坑:Swift 編譯器版本。
- 如果你電腦上僅有一個 Xcode,沒什麼問題。而如果你同時安裝了 Xcode Beta、又恰巧要為 Xcode Beta 的專案新增依賴,就有問題了。
- Carthage 預設是用
xcrun swift --version
所得到的 Swift 版本進行編譯的。而預設情況下,這個肯定是 Xcode 而非 Xcode Beta 的執行環境。再來個而,Swift 3.2 的專案,是無法引用 Swift 3.1 編譯器編譯出來的 Frameworks 的。 - 解決方案也很解決,使用 Xcode Beta 中的編譯器即可。只是,貌似 Carthage 並沒有相關的引數方便地切換(比如,我試了
TOOLCHAINS=com.apple.dt.toolchain.Swift_3_2 carthage update --platform iOS
來指定 Swift 編譯器版本,不過貌似並沒有幹活),最後比較土的先將 Swift 預設編譯器改為 Xcode Beta 版本,編譯後再改回來。
sudo xcode-select -s /Applications/Xcode-beta.app/Contents/Developer
carthage update --platform iOS
sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
sudo xcode-select -s /Applications/Xcode.app/Contents/Developer複製程式碼
Carthage 這麼簡潔美好,萬萬沒想到,最後還是倒入了 Pod 的懷抱。
因為 Firebase 只支援 Pod 方式整合?!
根本原因是,Firebase 並沒有完全開源,部分程式碼只能用靜態庫的方式釋出。而 Carthage 目前對靜態庫的支援並不好(雖然網上也有人成功了,但畢竟不是官方支援,有些麻煩,放棄了)
早說嘛,我就不折騰 Carthage 了,何必呢?
另外,還折騰了 iOS 與 macOS 專案間共享程式碼。因為我不想將二者放在一個工程裡,怕同時除錯時麻煩,就分為 2 個專案了。現在看來,主要有如下方式整合:
- 建立本地 Pod 專案
- 好處是可以方便跳入原始碼,道理和上面介紹的一樣
- 壞處是,建立本地 Pod 專案,麻煩啊
- 最後,還是用了這個方式
- 使用 Frameworks + Carthage 整合
- 好處是整合簡單
- 壞處也是 Carthage 本身的限制:看原始碼麻煩
- 共享相同的原始碼檔案
- 由於我是自己寫程式碼,不需要和別人共享,這也不失為一條路。
- 而且,這個方式最簡單。
總算,這個事情有了結論,明天可以靜心地優化 iOS 與 macOS 間的資料同步了。
部落格原文:0830 - 迂迴於 Swift 包管理