https://imtx.me/archives/1939.html

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 的使用还是让我省时又省力了。