作为子项目添加的静态库与作为目标添加的静态库答案

【问题标题】：Static Library added as sub-project vs static library added as target作为子项目添加的静态库与作为目标添加的静态库
【发布时间】：2013-08-30 13:22:53
【问题描述】：

首先，我想说的是，我对这个主题还很陌生，所以我对它的工作原理的一些一般方面有点困惑。基本上我正在开发一个有两个目标的 iOS 项目，一个是我正在开发的应用程序本身，它是一个前端 iOS 客户端，一个是一个静态库，前开发人员用来定义属于后端框架。

应用程序本身（我正在处理的客户端）和静态库（后端框架）的文件都在同一个 xcode 项目包中。即使我从未完成静态库的“设置过程”，任何东西在编译时似乎都可以正常工作。

现在的问题是：我正在设置单元测试，因为我想开始开发采用测试驱动开发方法的新功能，所以我苦苦挣扎的一件事是我是否必须生成两个单独的测试目标，一个用于 iOS 应用程序，一个用于静态库（因为它们是两个单独的目标），或者为静态库和 iOS 应用程序使用一个测试目标。因此，在互联网上阅读以找到解决方案，我发现，正如 Apple 建议的那样 here ，一种常见的方法是将静态库添加为应用程序项目的“子项目”。

我只是在问自己为什么以及我目前的情况有什么不同（一个项目，目标，其中之一是静态库）。有什么缺点吗？我应该重新组织整个项目吗？

【问题讨论】：

标签： ios objective-c xcode static-libraries ocunit

【解决方案1】：

我的经验与 Apple 和常用方法一致。我建议将框架作为子项目。（我在查找标头时遇到了一些问题，但这是我对 Xcode 缺乏掌握，而不是过程中的缺陷。）

为每个项目独立设置单元测试。这样，您的测试就符合您使用框架的目标：您已经成功地将框架与父项目完全解耦。

如果您在父项目中编写所有单元测试，那么当另一个项目需要该框架时会发生什么？你有两个选择。您无法测试框架，或沿原始父级字符串。做正确的事并拆分测试。

我有一个我构建的开源框架，名为SpiffyKit，它有一个名为 SpiffyTester 的父项目。（我承认我没有进行太多单元测试，因为它都是 UI，没有逻辑。）它可以作为一个很好的起点示例。

【讨论】：

好的，我同意你的解耦问题，但是我的问题的观点略有不同，我想知道为什么要与子项目而不是与每个目标不同的目标解耦链接的不同文件。我想知道为什么一个比另一个更好，因为我发现通过子项目添加东西有点棘手，它只是一个概念上的东西，比如：“有一天你可能也想将该库添加到另一个项目，所以它应该存在一个单独的项目”，或者还有其他与我不知道的捆绑维护和分发过程相关的问题？
我认为这两个都是正当的理由。您可能希望将库添加到另一个项目，或者您可能希望共享该库而不共享其余代码。 Cocoa 项目的原子单元是 Xcode 项目。出于上述所有原因，坚持使用该单位是个好主意。

【解决方案2】：

根据您的需要，您可以使用Pods、静态或将其添加到项目中。如果您将库添加为“子项目”，那么当您同时处理 2 个项目时会很有用。例如，如果您向库中添加新内容，您只需编译库，瞧，您就可以访问项目中的新库。但是，如果您只是链接静态库，则必须打开该库的项目，然后构建，然后在库中替换它并添加新的头文件，这需要大量的设置工作。

【讨论】：

CocoaPods 在这里不合适。
既然他问这个问题，我认为他应该知道将库/代码添加到项目中的所有方法，以获得额外的知识，并且有点思考永远不会让任何人心动。
我已经知道可可豆荚，有时我在一些项目中使用过它，但事实并非如此。这会增加额外的复杂性，我要添加到我的项目中的库是我们仍在处理并经常更新的代码，代码应该准备好并且可编辑，我们应该能够快速测试它。