Ios 多框架和公共库

使用iOS 8、Xcode 6

假设我有两个动态框架，

frameworkA

和

frameworkB

，它们都依赖于

libC

。此外，我还有一个应用程序，它同时使用

frameworkA

和

frameworkB

。我最初的想法是将

frameworkA

和

frameworkB

作为伞式框架，将

libC

作为子框架。然而，苹果建议不要使用伞式框架，这说明了为什么伞式框架是一个坏主意，因为潜在的链接器冲突问题

我的第二个选择是使用cocoapods（对它来说还是新的，所以细节上有点模糊）来使用

libC

作为pod，然后将其编译成

frameworkA

和

frameworkB

。然而，我突然想到，这两个框架仍然有自己的

libC

副本。由于应用程序同时使用这两种框架，这是否也会导致链接器冲突问题？有没有更好的办法来解决这个问题

更新

---

@Rob我所从事的项目确实需要复杂的依赖关系管理，但我在问题中保持问题域的简单，以便更好地理解使用CoCoapod如何以及是否能够帮助解决伞式框架中的链接器冲突问题。我与一个编写库的开发团队合作，他们可以相互依赖提供版本化公共API的基础库。我们需要将尽可能少的库打包并交付给使用我们的库构建应用程序的不同组织，他们的关键要求之一是我们提供一个动态框架

解决大多数问题的最佳方法是将所有代码放在一个项目中并编译它。当您遇到了使之成为问题的专门问题时，您应该考虑其他解决方案，例如静态库，最后是框架

如果您有一个代码库，其中包含需要不同构建需求的片段，那么静态库是有意义的。如果所有部分都具有相同的构建设置，那么只需从“公共”目录将它们“添加文件”到项目中，然后构建项目。如果您的构建时间非常长，并且某些部分永远不会改变，并且您希望能够在不重建这些部分的情况下“清理”静态库，那么静态库就很有吸引力。但是，等到你开始有这个问题，你再去做复杂的多包项目

如果您销售封闭源代码库，那么框架是非常有吸引力的。由于您注意到的原因，您应该强烈避免添加第三方依赖项。如果必须这样做，最好的方法是帮助客户将所有部分打包为框架，并让他们在最后链接所有内容。但这增加了很多烦恼；所以，确保你真的需要第三方的作品

您也可以考虑框架，如果您有一个非常大的可重用代码，它有自己的生命周期与主产品分离。不过，还是要保持简单。避免第三方的东西在里面，如果你必须有第三方的东西，那么让消费者在最后链接它

（顺便说一句，这不是一个新的解决方案。当您使用curl时，如果您想要SSL，您还需要下载和构建OpenSSL，并自己将它们链接在一起。curl没有内置OpenSSL。）

但在绝大多数情况下，这都是矫枉过正。不要跳转到框架。不要跳转到图书馆。只需将所有代码放入项目中并编译即可。你90%的问题都会消失。尤其是iOS项目，通常都没有那么大。框架解决了什么问题

如果您的组织在许多产品中重复使用了大量代码，那么我听说许多团队很幸运使用内部CoCoapod来管理这些代码。但这只是为了简化代码的签出。它仍然全部进入到一个项目中，您将其编译成一个二进制文件；不需要框架。对于某些以前确实很痛苦的问题，动态框架是一个很好的特性。但是，在大多数情况下，他们只是在寻找问题

（如果您有这些特殊问题之一，请编辑您的问题，我很乐意进一步讨论您可能如何解决。）

---

编辑：（你陷入了那个“特殊问题”，所以让我们来谈谈。我也是这么做的，在大型多团队Mac和iOS开发环境中工作了很多年。我们尝试了几乎所有不同的解决方案，包括框架。它们在iOS上才是新的。）

在您描述的组织中，我强烈建议将每个依赖项打包为自己的框架（AFNetworking、JSONKit等），并将您的每个部分打包为框架，然后让应用程序开发人员在最后将它们链接在一起。通过这种方式，它与其他动态库（libcurl、openssl等）相同，这些库要求应用程序开发人员将所有内容链接在一起

在任何情况下，动态框架都不应包括其他可能需要的框架（即框架不应打包“第三方”内容）。那会爆炸的。你不能让它不爆炸。您将有膨胀、生成冲突或运行时冲突。这就像合并冲突。开发人员必须在某一点上做出选择。应用程序级链接正在做出这样的选择

使组件过度依赖于其他组件是几十年麻烦的根源，从Windows DLL地狱到具有竞争性崩溃处理程序的iOS应用程序。所有最好的组件系统看起来都像乐高积木，最终用户在其中组装具有最小依赖性的小部件。尽可能使您的内部框架只依赖Cocoa。这会产生一些有形的设计影响：

• 避免直接要求日志或分析引擎。提供一个可适应调用者引擎的委托接口
• 避免琐碎的类别（只保存几行代码的方法）。直接编写代码即可。