Carthage是iOS/Mac开发生态中的包管理工具。与流行的CocoaPods不同，它是一种去中心化的解决方案。知道有一段时间了，就是没玩好。今天在整合Carthage和创建Carthage兼容Framework的过程中，积累了很多经验。我决定写一篇文字记录一下。首先简单介绍一下CocoaPods，它是目前iOS/Mac的包管理工具。目前最新版本为0.37.2，已经支持iOSFrameworks。它管理着总共10,822个库（并且还在不断增加），并使开发人员能够非常轻松地集成第三方库。经过一段时间的使用，我认为CocoaPods有以下优点：使用方便，除了写Podfile，几乎所有的事情都是自动完成的；软件包众多，主流支持；支持iOS8Framework，当然也支持旧的静态编译；但是CocoaPods作为带有中央仓库的方案，缺点也很明显：每次更新环境都需要连接中央仓库，比较耗时；对开发者来说使用起来比较简单，但是如果自己创建一个兼容CocoaPods的库，会比较麻烦（虽然是用命令行）；每次clean编译都会重新编译所有的第三方库（好像是对的，直到我遇到了Carthage...）你已经知道Carthage的一个优点，是的，如果你使用Carthage，所有的第三方库依赖，除非它需要更新的时候，普通干净编译Project，不需要重新编译，大大加快了普通编译和Archive的时间。每次Archive和cleancompilation都能节省几十秒以上，还是很可观的。仅此一点，Carthage就值得使用。那么，迦太基有什么优势呢？前面说了，它是去中心化的，没有中央服务器，也就是说每次配置和更新环境，只会更新特定的库，不会有索引从中央服务器获取最新的库。这个过程节省了大量时间。“好吧好吧，要是有第三个优势，我就被你说服，开始使用迦太基了！”第三个优势是：与CocoaPods无缝集成！“什么？一个项目用两套包管理工具，会不会出错？”经过我自己的实验，我把我的“Singularity”项目改造成了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，所以它是iOS8Only，随着时间的推移，这不会成为问题；工具还不够完善：在使用过程中，发现在结构复杂的项目中无法正确发现库（如iOS的结构，Macdemo+framework）；Xcode中无法定位源码：如果你在写代码的过程中想跳转到第三方库看具体实现，这是不可能的可以做到，Carthage的配置只能让你看库的头文件；不知道这四个缺点什么时候能解决（我觉得第四个由于项目配置的原因无法解决），但是综合上面提到的四个优点，使用Carthage还是省时省力的。
