迦太基或CocoaPods:这是问题

该帖子最初发布在我的个人博客中 阅读原始帖子,这样您就不会错过任何内容。

每种成熟和现代的编程语言都提供了一种官方的代码分发解决方案,以共享和重用已经编写的代码。 共享,分发和重用代码的机制通常由程序包管理器处理。 流行的软件包管理器的示例包括用于Ruby的RubyGems,用于PHP的Composer,用于NodeJS的NPM,用于Java的Gradle等,它们不仅提供官方解决方案,而且具有集中的存储库来托管开发人员创建的软件包。 但是,Apple例外,Objective-C和Swift之类的语言已公开发布,而没有正式支持程序包管理解决方案或具有用于存放程序包的集中存储库。 这为第三方公司或开发人员提供了构建非官方工具来管理Objective-C或Swift软件包的机会。 这就是诸如Cocoapods和Carthage之类的工具进入市场并获得普及的原因。

目前,iOS的Swift依赖性管理目前只有两个主要选项,即Cocoapods和Carthage。 Apple目前正在使用的官方软件包管理器是Swift Package Manager,用于共享和分发Swift软件包,它将取代iOS开发领域中的当前软件包管理器。 但是,它的发展正在成为速度乌龟,目前它不支持iOS,因此现在不值得考虑。 有一种解决方法可使其与iOS项目的Xcode模板一起使用,但可能会在更高版本的Xcode中破坏。 等待耐心等待苹果宣布对iOS应用程序提供Swift Package Manager官方支持是个好主意。 我们可以希望有一天,iOS开发人员将拥有Apple提供的iOS官方软件包管理解决方案。

在本文中,我们将对Swift依赖项管理器CocoaPods和Carthage进行严格评估,以便iOS开发人员可以为其应用程序做出正确的选择。

可可豆

爱它或恨它,您必须使用它。 Cocoapods自从Objective-C时代就存在了,并且也可以与Swift一起使用。 到目前为止,这实际上是用于iOS项目的依赖管理,这是事实上的标准工具。 CocoaPods是一个Ruby库,需要使用RubyGem进行安装。CocoaPods具有可在Xcode项目中使用的所有软件包的集中存储库。 CocoaPods不是单个项目,而是使用Ruby编写的项目的集合。 我在这里简要介绍了Ruby和iOS生态系统的历史。 CocoaPods是使用Ruby构建的,并且可以使用OS X上可用的默认Ruby安装。

  $ sudo gem install cocoapods 

如果您来自Ruby开发背景,则可以使用RVM和Bundler来管理Ruby和Ruby库的版本。 可以使用pod init命令初始化CocoaPods,该命令将创建模板Podfile,但是我们可以创建自己的简单Podfile,如下所示

 平台:ios,“ 8.0” 
use_frameworks!
 以“ MyApp”为目标 
pod'SwiftyJSON','〜> 2.3'
结束

这将设置SwiftyJSON,这是非常流行的Swift库,用于为My App目标解析JSON。 现在,我们可以使用magical命令下载依赖项

  $ pod安装 

执行此命令后,您会感到困惑,并且可能无法识别旧的Xcode项目,因为CocoaPods使用此神奇的命令对Xcode项目进行了许多更改。 我敢肯定,只要iOS应用可以在pod install命令之后编译并正确构建,我们当中就不会有很多人会费心去知道发生了什么变化。 我们将简要介绍安装后发生的变化。

CocoaPods做了哪些更改?

上面的命令(pod安装)非常神奇,它可以对我们的Xcode项目进行很多更改。 在大多数情况下,很难理解发生了什么变化。

  • CocoaPods创建Xcode Workspace目录,该目录具有.xcworkspace扩展名,可在其中构建所有依赖项。 为了使CocoaPods工作,我们必须使用Xcode工作区。
  • CocoaPods在目标的构建阶段中添加了一些脚本。 通常,将三个脚本添加到目标的构建阶段
  • 添加了Podfile.lock(库的锁定版本)
  • 将Pod框架链接到“将二进制文件与库链接”
  • 一个Pods目录,其中包含Pod依赖项的源代码,支持文件,xcconfigfiles
  • Xcode构建设置中的许多内容。 这里很难涵盖所有内容。

当您运行神奇的pod install命令时,上面提到的所有这些都将在后台发生。

CocoaPods构建过程

CocoaPods项目的典型构建过程包括以下步骤。

  • 每当您进行干净构建或运行项目的pod安装或pod更新时,CocoaPods都会每次构建和编译我们的框架。
  • Xcode然后检查Podfile.lock是否已更改(如果已更改),则Xcode将再次构建依赖项框架,否则将使用预构建的框架。
  • 使用CocoaPods进行干净的构建或删除派生数据时,您可能已经看到该项目花费很长时间。
  • CocoaPods将为此目标构建Podfile中提到的所有库,在某些情况下,您可能不想一直构建某些库,但CocoaPods不会提供该选项。

如何删除CocoaPods

一旦采用了CocoaPods,就没有干净的方法将其从项目中解集成。 CocoaPods对您的Xcode项目,构建设置和目录结构进行了许多更改。 如您所见,集成CocoaPods花费一分钟,但是从项目中删除却是ving牛。 CocoaPods具有Pod Deintegrate和Pod Clean命令,但仍然需要确保已完成操作。 但是,有一些手动操作可以完全摆脱iOS项目中的CocoaPods。

  1. 删除独立文件(Podfile Podfile.lock和您的Pods目录)
  2. 删除生成的xcworkspace
  3. 打开您的xcodeproj文件,删除对Pods.xcconfig和libPods.a的引用(在Frameworks组中)
  4. 在您的Build Phases下,删除Copy Pods Resources,Embed Pods Frameworks和Check Pods Manifest.lock阶段。
  5. 这似乎很明显,但是您需要以其他方式集成第三方库或从代码中删除对它们的引用。

椰子足的好处

  • CocoaPods易于设置
  • CocoaPods自动执行整个构建过程,将依赖关系链接到目标。
  • CocoaPods社区在解决苹果的缺点方面做得非常出色
  • CocoaPods支持具有子规范的库。
  • 社区成长的贡献者很多
  • 对于使用较少代码的小型项目而言,效果很好,因此可以使某些项目快速运行。

CocoaPods的缺点

  • 它要求了解另一种编程语言,例如在其上构建CocoaPods的Ruby。
  • 已经使用Xcode工作区时很难集成。
  • 集成后很难移除。
  • CocoaPods控制整个Xcode项目,如果失败,则整个项目停止构建。 修复CocoaPods引发的错误是一项艰巨且耗时的任务,需要了解iOS项目中CocoaPods进行了哪些更改。
  • 窗格将您的项目强制为特定的结构。 不了解更改内容的CocoaPods更新Xcode项目和文件就像魔术一样。 它以黑匣子方式工作。
  • 与Continuous Integration Server集成非常困难,因为我们必须安装和管理Ruby库。 需要为每个构建安装并构建所有依赖项,或者我们必须检入项目内的整个第三方依赖项。 缓存机制并不总是能带来干净的结果。
  • iOS应用程序的构建变得不透明且缓慢。
  • 对于不熟悉Ruby的iOS开发人员而言,构建支持CocoaPods的库和框架变得如此痛苦。 开发人员需要编写.podspec文件,并遵循许多不相关的Ruby约定。
  • 集中
  • 由于涉及依赖项的两步过程,因此无法同时使用框架和项目。

迦太基

迦太基是Cocoa应用程序的另一个简单的依赖项管理器。 Carthage纯粹是用Swift编写的,用于管理iOS依赖性,而无需更改Xcode项目中的任何内容。 如果您想知道当CocoaPods出现时为什么迦太基存在,您可以在这里阅读这些区别。 迦太基只是使用xcodebuild工具下载并构建依赖项,但不会更改Project文件或Xcode项目构建设置(如CocoaPods)。 在目标的构建阶段,我们必须手动将框架二进制文件拖到链接框架和库中。

我们可以使用HomeBrew安装Carthage,也可以从Github下载.pkg并手动安装。

  $酿造安装迦太基 

现在我们可以使用迦太基了。 如上所述,我们需要使用Carthage获取SwiftyJSON,然后我们必须创建具有以下内容的名为Cartfile的文件。

  github“ SwiftyJSON / SwiftyJSON” 

现在,我们已经在Cartfile中指定了依赖项,运行

  $迦太基更新 

这会将依赖项提取到Carthage / Checkouts文件夹中,然后构建每个。 现在,CocoaPods的所有功能都会自动执行,就像魔术一样,我们必须手动执行。

在应用程序目标的“常规设置”选项卡上的“链接的框架和库”部分中,将要使用的每个框架从磁盘上的Carthage / Build文件夹中拖放。 完成所有手动工作之后,我们应该能够导入依赖项。 但是,上面提到的手动工作是一次或在添加新的依赖项之后。

迦太基做了什么改变?

迦太基不会触摸Xcode设置或Project文件。 迦太基非常简单,只需签出并构建依赖项,然后将其留给您即可将二进制文件添加到Xcode中。 它使您可以完全控制我们要添加到Xcode中的内容。

迦太基建造过程

迦太基项目的典型构建过程包括以下步骤。

  • 迦太基使用迦太基更新命令检索库和框架,该命令仅发生一次。
  • 在构建项目时,Xcode不会重建任何框架。 这样可以加快构建过程。
  • 在获得任何依赖关系的新版本时,框架都需要重建。

如何去除迦太基?

集成后,很容易从iOS项目中删除Carthage。 我们可以采取几个步骤来确保将Carthage从Xcode项目中完全删除。

  • 删除Cartfile和Cartfile.resolved
  • 删除迦太基目录
  • 从目标构建阶段删除链接的框架。
  • 从构建阶段删除copy-frameworks脚本。

而已。 您不再使用迦太基。

迦太基的好处

  • Carthage是适用于iOS的分散,简单无情的依赖管理
  • Carthage纯粹是用Swift编写的,因此iOS开发人员可以了解Carthage背后的技术,并可能使用CarthageKit编写另一种工具
  • 如果迦太基不适合项目的需求,那么它很容易集成,也很容易从项目中删除。
  • 迦太基不会触摸您的Xcode设置或项目文件。 它只是下载并构建依赖项,因此您可以适当地控制自己在做什么。
  • 迦太基的灵活性使它适合大型或折衷的代码库
  • 使用Carthage可以更轻松地构建和更新库。
  • 迦太基可以轻松地与Continuous Integration服务器集成。
  • 使Swift库Carthage兼容很容易。
  • 去中心化
  • 支持子模块

迦太基的缺点

  • 迦太基设置时需要执行太多手动步骤。
  • 迦太基仍是一个新的框架,作为CocoaPods的贡献者并不多
  • 迦太基仅适用于动态框架。 它不适用于静态库。
  • 迦太基没有干净的方法来支持库中的子规范。
  • 来自Objective-C背景的传统iOS开发人员不愿使用Carthage。
  • 迦太基检出并构建框架,我们可能需要检入这些框架以加快构建速度,从而增加存储库的大小。
  • 一些用户报告说,迦太基在构建框架时速度很慢。
  • 装有自制软件的迦太基不向后兼容。
  • 并非所有的框架都适用于迦太基,尤其是需要使用git子模块添加的较旧的库。

迦太基是非常简单的Swift依赖项管理器,但是它涉及很多手动设置才能上手。

选择迦太基或CocoaPods的提示

现在,我们已经看到了CocoaPods和Carthage的优缺点,但问题是,为您的iOS项目选择哪个。 我讨厌这个答案,但是答案是“取决于”。 迦太基或CocoaPods没什么错,但选择正确的一个确实取决于团队和团队中工程师的技能。

这里有一些提示:

  • 首先,除非确实需要,否则请避免将任何依赖项添加到您的iOS项目中。 Apple为您提供了许多本机框架和工具。 也有可能向Apple提供的本机框架添加额外的功能。 在对项目添加任何依赖项之前,请先思考10次。 例如,在进行网络通话时,您真的需要Alamofire吗?苹果的本地URLSession无法解决您的问题。 尝试使用本机框架实现所有目标,因为苹果极有可能破坏您的项目。
  • 在开始新项目时,请在使用CocoaPods之前先思考100次。 当您开始使用CocoaPods时,很难将其从Xcode项目中删除,并且您将失去对Xcode项目的控制。
  • 首先喜欢Carthage,因为它是用Swift编写的,如果您认为它不合适,那就去CocoaPods并与Ruby打交道。
  • 在将库与大型代码库集成时,请使用Carthage,因为它只需构建一次。
  • 如果您打算在项目中使用许多库,那么CocoaPods并不是一个好的选择,因为它们每次执行干净构建时都会构建框架。 同样如前所述,您没有机会停止构建不经常更新的库。 这为您的构建过程增加了额外的时间。
  • 不要害怕在单个项目中同时使用CocoaPods和Carthage,因为如上所述,在许多情况下它都是有意义的。 我们可以同时利用CocoaPods和Carthage的功能。
  • 如果您不熟悉Ruby,那么绝对不要使用CocoaPods。 在本地计算机以及Continuous Integration服务器上维护Ruby和Ruby库的版本将变得非常困难。
  • 使用CocoaPods子规范可以很好地处理使用多个存储库的库,而对于Carthage则没有干净的解决方案。
  • 无论选择什么,请始终在SCM存储库中签入第三方库的源代码。 当Github中的库丢失时,切勿冒险。
  • 使用迦太基检查私有或内部框架。

结论

迦太基和CocoaPods都有其优缺点,但是对于任何项目而言,选择一种工具可能都很困难。 我个人倾向于先选择迦太基,然后在迦太基失败时尝试与Ruby和Cocoapods打交道。 对于CocoaPods成为白象的许多旧Objective-C iOS项目,如果您的项目迁移到Swift,是时候进行一些更改并尝试Carthage了。 如果您对此帖子有误解,请随时纠正我。 您在Carthage或Cocoapods上的使用经验是什么,请在下面的评论中分享?

像XCBlog的 XCTEQ 发布的帖子一样 您可能还喜欢我们的一些服务,例如访客博客或Mobile DevOps(CI / CD)或测试自动化。 Github 搜索我们的 服务 ,开源项目, 或者在 Twitter Facebook Youtube LinkedIn 上关注我们 下载我们的 XCBlog iOS应用程序以离线阅读博客。

X CTEQ 一家专门从事基于Mobile DevOps,CI / CD,Mobile,AI / ML的测试自动化Checkout XCTEQ产品和服务的公司, 网址 http://www.xcteq.co.uk 或写信给我们info@xcteq.co。英国..