迦太基与可可足-建立时间分析用例

在开发iOS项目时，您可能会面临的最著名的难题之一就是您应该使用哪个程序包管理器：Cocoapods或Carthage。

当然，没有正确的答案。 两种方法都是可能的，并且它们都有消极点和积极点。 但是在这篇文章中，我想谈谈我在大力神开发过程中对他们俩的经历，以及为什么我们选择从可可足类转变为迦太基。

在项目开始时，选择“迦太基”或“ Cocoapods”可能与我们讨论“构建时间”无关，因为使用的框架数量可能很少。 当您的项目开始增长并向其中添加更多框架时，构建时间就成为一个问题，因为在较长的构建时间中开始浪费大量的开发时间。

在Hercules开发期间，我们意识到在项目中执行干净命令后，在构建过程中损失了大约15分钟，而在执行存档时损失了大约20分钟。 此时，我们使用了17个框架（其中一些框架与Realm，Firebase，Facebook SDK和Google SDK相当），而Cocoapods作为我们的软件包管理器。 我们的构建时间简直太糟糕了，我们不得不为此做些事情。 到那时，我们已经使用了整个冲刺来分析和检验假设，以改善这种浪费的时间。

我们从分析构建时间开始，寻找哪些关键点花费太长时间来编译。 尽管我们的项目很大（+230个源文件），但我们意识到编译源文件所花的时间并不是问题。 在每次“清理和存档”期间发生的事情是，花费大量时间来编译所有框架源文件。 之所以发生这种情况，是因为Cocoapods在每次构建过程中都将框架源文件作为项目的一部分进行附加。 这意味着，即使您从未接触过这些文件，每次执行“清理”操作也会清除所有框架源文件。 您多久修改一次外部框架文件？ 您可能会同意我的看法，几乎永远不会同意。

从那时起，我们决定从Cocoapods转到Carthage，成为我们独特的包裹管理器。

我将从使用迦太基的缺点之一开始。 当我们开始切换所有框架时，我们意识到其中的一些框架不支持Carthage-Google SDK，Firebase框架，Facebook pop和Fabric Analytics。 这意味着我们必须手动导入所有这些框架。 尽管这样做不是很大的问题，但这是我们在Cocoapods中所没有的额外工作。 另外，某些框架手动安装（例如Facebook pop）必须通过将框架PBX添加为主PBX的子项目来完成，这与通过Cocoapods添加它的行为类似，因为框架源文件将在每次构建时进行编译。

手动导入所有必要的框架后不久，我们遇到了迦太基的第二个负面问题：第一次carthage update 。 使用no-use--binaries标志在本地编译所有框架大约需要1个小时，这迫使所有框架都在本地编译。

尽管在执行了所有这些烦人的更改之后，我们还是开始收集使用迦太基的好处：清洁后2分钟的构建时间。 编译Facebook pop框架花了大约20秒钟，该框架必须作为子XCode项目导入，其余时间则编译我们自己的源文件。

从那时起，我们意识到由于Cocoapods自动对我们进行手工操作，从Cocoapods切换到Carthage最初很烦人，但是由于Build Time的减少，它为我们节省了巨大的开发时间。 同样，执行“存档”将与“清理”后编译代码的速度一样快，这意味着如果您频繁执行手动发布，迦太基将节省您的时间。

摘要

椰子足

尽管Cocoapods是更成熟的工具，具有更多的框架，并且超级易用，但它可能使您头疼，无法执行干净的构建并不得不等待所有框架的源文件进行编译。 另外，Cocoapods是集中式解决方案，因此请准备好开始失去对PBX / Workspace文件的控制，因为从现在开始，Cocoapods将开始控制并在某些您可能不会注意到的地方进行一些更改。

迦太基

到目前为止，我们注意到的两个负面问题是，如果您决定使用本地编译，则需要花费大量时间来编译所有框架，并且有必要手动导入一些框架。 虽然，我们在使用迦太基时节省的构建时间使初始负数变小了。

杂种

即使我之前没有提到，您也可以使用混合解决方案：Cocoapods和Carthage一起使用。 但是我认为后果很直观：您将从这两种工具中继承正负两点。

这就是我和我的团队同时使用两个程序包管理器的经验。 希望本文可以为您提供任何帮助，以便您更好地选择一个。 感谢您的阅读，并考虑在below下面留下评论/反馈