[[140844]]

Carthage 是 iOS/Mac 開發生態圈的一個包管理工具，與現在流行的 CocoaPods 不同，它是一個去中心化的解決方案。知道它已經有一段時間了，但是一直沒有好好玩過，今天整合 Carthage 并自己創建 Carthage 兼容的 Framework 的過程中讓我有了很大的體會，決定寫篇文字記錄一下。

先來簡單介紹下 CocoaPods，這是現在注流的 iOS/Mac 的包管理工具，當前***版本是 0.37.2，已經支持 iOS Frameworks。它管理著共 10,822 個庫（并在不斷增長），可以讓開發者非常容易地將一個第三方庫集成進來。

經過一段時間的使用，我覺得 CocoaPods 有如下優勢：

• 使用方便，除編寫 Podfile 以外其他幾乎都是自動完成；
• 軟件包數量多，主流支持；
• 支持 iOS 8 Framework，當然也支持舊的靜態編譯；

但是 CocoaPods 作為一個有中心倉庫的解決方案，缺點也比較明顯：

• 每次更新環境都需要連接到中心倉庫，比較耗時；
• 開發者使用比較簡單，但是如果創建兼容 CocoaPods  的庫，就會相對繁瑣一些（盡管有了命令行）；
• 每次干凈編譯都會把所有第三方庫都重新編譯一次（看似很正確，直到我遇見 Carthage…）

看到這里你已經知道 Carthage 的一個優勢了，沒錯，使用 Carthage 的話，所有的第三方庫依賴，除非是更新的需要，不然平常干凈編譯 Project，它是不需要再次編譯的，大大加快平常編譯及 Archive 的時間。每次 Archive 及干凈編譯時都能節省幾十秒以上，還是非常可觀的，光是沖的這點，Carthage 就值得使用。

那么，Carthage 還有什么優勢呢？前面還提到了，它是去中心化的，沒有中心服務器，這意味著每次配置和更新環境，只會去更新具體的庫，而不會有一個向中心服務器獲取***庫的索引這么個過程，如此一來，又省了很多時間。

「好了好了，如果還有第三個優勢，我就被你說服，開始用 Carthage！」

第三個優勢就是：與 CocoaPods 無縫集成！

「什么？一個項目使用兩套包管理工具，不會出差錯嗎？」

經過我的親自試驗，我已經非常***地將我的「奇點」項目改造成了 Carthage + CocoaPods 共同管理依賴這么一個配置。沒有絲毫沖突。

因為 Carthage 并不是像 CocoaPods 那樣一個全自動+全功能的第三方庫配置工具，它的設計哲學是，完成瑣碎的部分，并把主要控制權交給開發者，它不會像 CocoaPods 那樣一定會生成一個 Workspace，這意味著我可以自由地去控制 Framework 如何放進我的 Project/Workspace，是 Required 還是 Optional。當我發現 Carthage 是如此靈活后，我毫不猶豫地在當前 CocoaPods 管理主要 Framework 的配置下，將少量其他 Framework 交給了 Carthage 管理。它們非常和諧地共存著。

事實上，我用 Carthage 還有一個主要原因，那就是創建第三方庫并讓 Carthage 可以使用實在是太簡單了，不需要弄像 CocoaPods 那樣結構復雜+聲明文件式的模式，我只需要創建一個 Project/Framework，讓 Framework 這個 Scheme 設置成 Shared 就可以了。這樣，我的第三方庫的目錄非常干凈，沒有任何與 Carthage 有關的文件，Carthage 卻能去發現并使用它，我就喜歡這樣簡單純粹的技術解決方案。

以上，便是 Carthage 的第四個優勢：結構標準的項目天然就是 Carthage 庫。

列舉完這四大 Carthage 優勢后，來談談它的不足：

• 庫依然不如 CocoaPods 豐富：盡管很多庫不需要聲明并改造就直接可以被 Carthage 用，但依然有大量 CocoaPods 能用的庫不支持，我相信時間能解決這個問題；
• 只支持 Framework，所以是 iOS 8 Only 了，隨著時間推移，這個也不會是問題；
• 工具仍不完善：在使用過程中，我發現它無法在一個結構復雜的項目中正確發現庫（比如有 iOS, Mac demo + framework 的結構）；
• 無法在 Xcode 里定位到源碼：如果你在寫代碼過程中，想跳轉到一個第三方庫去看具體的實現，這是無法辦到的，Carthage 的配置只能讓你看到一個庫的頭文件；

不知道這四個劣勢到底會在什么時候得到解決（第四個因項目配置原因我覺得是無法解決了），但是綜合上面提到的四大優勢，Carthage 的使用還是讓我省時又省力了。