在這個幾乎每一個開源 iOS 第三方組件都支持 CocoaPods 的時代邮丰，為什么要選擇另一個組件支持數(shù)量少、項目配置相對繁瑣范嘱、無法直接查看組件源碼的包管理工具呢趣效？Carthage 到底好在哪呢？
最初看到 Carthage 第一眼就被「去中心化」這個高大上的名詞給嚇到了艾帐，但是它并不是個很復(fù)雜的事乌叶。在項目中，原來我們把一個組件做成 Pod柒爸，需要寫 Podspec准浴，用 development pod 或者更新 Specs 倉庫的項目，私有組件還要更新捎稚、指定自己的 Specs 源乐横。
最早 CocoaPods 還沒有流行的時候，我曾是 CocoaPods/Specs 倉庫的主要貢獻者之一今野。當(dāng)時第三方組件默認的安裝方式就是拖拽和 git submodule葡公，CocoaPods 為了推廣自己，有一個建議第三方倉庫支持 CocoaPods 的文字模板条霜，以 issue 的形式發(fā)到對方的倉庫里催什。讓倉庫擁有者辛辛苦苦地寫一個 podspec，還要更新 README 一般都要等上好幾天宰睡，而且很難一次就做對蒲凶。所以最好都是幫對方寫好 podspec，改好 README夹厌，發(fā) Pull Request豹爹，再代為更新 CocoaPods/Specs 倉庫，非常費事費力矛纹。
而組件支持 Carthage 的唯一要求就是臂聋，項目的里有一個 shared Framework target 存在。每次更新組件都不需要去更新任何 Podspec 或 Specs 倉庫或南。私有倉庫不需要額外設(shè)置 Specs 倉庫孩等，不需要 pod trunk。去中心化采够，意義非凡肄方。
另一個 Carthage 的設(shè)計優(yōu)勢是，先天只支持 Dynamic Framework蹬癌，只在更新時編譯权她，這是為 Swift 項目量身定制的特性虹茶。在發(fā)版本時不需編譯所有依賴，在項目 clean 時不需要重新編譯所有依賴隅要，開發(fā)者只有在用 carthage update 更新組件后才需要重新編譯組件蝴罪，而且一般只做一次。
另外組件作者可以進一步提供編譯好的 Framework 壓縮包步清，隨 release 發(fā)布要门，節(jié)省使用者的編譯時間。試想如果項目中的每一個依賴都這么做了廓啊，carthage update 會像 apt-get 一樣又快又好用欢搜。
再來說說公認的缺點。項目配置的步驟的確不如寫一個 Podfile 然后 pod install 那樣簡單谴轮，但其實也沒有多么痛苦吧炒瘟。Carthage 不會像 CocoaPods 那樣對項目做大量改動，也沒有要求一定要用 xcworkspace书聚。甚至如果放棄打包 dsym唧领，不用 copy-framework 腳本也是可以的。至于不能直接點到源碼雌续，可以用拖入 Carthage/checkouts 目錄中的 xcproj 的方式來臨時解決斩个，這樣就和使用 CocoaPods 或 git submodule 差不多了。
最后分享近兩年使用 Carthage 發(fā)現(xiàn)的一些小技巧驯杜，但我覺得是 Carthage 的 CLI 命令設(shè)計得比較奇葩受啥。如：
只更新不編譯：
carthage update --no-build只編譯特定依賴的 iOS 版:
carthage build --platform iOS RxSwift刪除一個依賴的時候不需要重新 update，只要刪除 Cartfile.resolved 中相應(yīng)的行鸽心，和 Carthage 中的目錄即可
如果經(jīng)常用的庫沒有提供編譯好的 Framework滚局，可以 fork 一個自己提供，然后就不用每次都編譯了
最后我想說的是顽频，Carthage 并沒有占據(jù)絕對的上峰藤肢，有很多常用組件如 Facebook 的大部分 SDK、Lookback SDK糯景、Fabric Framework 等都不支持 Carthage嘁圈。選擇自己習(xí)慣的、適合當(dāng)前項目的包管理工具蟀淮，以及使用配置更好的 Mac 能省去不少時間最住。
BTW: firefox - ios 使用了Carthage
本文轉(zhuǎn)自：https://lex.sh/why-carthage/
