多个框架和通用库

用iOS 8, Xcode 6.

比方说,我有2个动态的框架,frameworkA并frameworkB和他们都依赖libC.另外,我有一个使用frameworkA和的应用程序frameworkB.我最初的想法是制作frameworkA和frameworkB伞框架和libC子框架.但是,Apple建议不要使用伞形框架,这篇文章描述了为什么由于潜在的链接器冲突问题,伞形框架是一个坏主意.

我的第二个选择是使用cocoapods(对于细节仍然是新的,因此有点模糊)libC作为一个pod然后被编译成frameworkA和frameworkB.然而,在我看来,两个框架仍然有自己的副本libC.由于应用程序使用两个框架,这是否会导致链接器冲突问题？有没有更好的方法来解决这个问题？

更新 @Rob我工作的项目确实需要复杂的依赖关系管理,但我在问题中保持问题域的简单性,试图更好地理解如何使用cocoapods来帮助解决伞框架的链接器冲突问题.我与一组编写库的开发人员合作,可以依赖彼此提供版本化通用API的基础库.我们需要将尽可能少的库打包并交付给使用我们的库构建应用程序的不同组织,其中一个关键要求是我们提供动态框架.

解决大多数问题的最佳方法是将所有代码放在项目中并进行编译.当你遇到有问题的专门问题时,你应该看看其他解决方案,比如静态库,最后是框架.

如果您的代码库具有需要不同构建要求的部分,则静态库可能有意义.如果所有部分都具有相同的构建设置,那么只需从"公共"目录"添加文件"到项目中并构建项目.如果您的构建时间非常长并且某些部分永远不会更改并且您希望能够"清理"而不重建这些部分,则静态库可能很有吸引力.但是在你开始复杂的多包项目之前,请等到你开始遇到这个问题.

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

如果您有一大块可重用的代码,并且它们自己的生命周期与主要产品分开,您也可以考虑使用框架.但同样,保持简单.避免在其中使用第三方内容,如果您必须拥有第三方内容,请让消费者在最后链接它.

(这不是一个新的解决方案,顺便说一句.当你使用curl时,如果你想要SSL,你还需要下载并构建OpenSSL并将它们自己链接在一起.Curl不附带内置的OpenSSL.)

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

如果您的组织在很多产品中反复使用了大量代码,那么我听说很多团队都有好运使用内部CocoaPod来管理它.但这只是为了简化检查代码.它仍然进入一个项目,你将它们一起编译成一个二进制文件; 没有框架需要.对于某些以前非常痛苦的问题,动态框架是一个很好的特性.但是,在大多数情况下,他们只是寻找问题的复杂性.

(如果您有其中一个专门的问题,请编辑您的问题,我很乐意进一步讨论如何处理它.)

编辑:(你陷入了"专业问题",所以我们来谈谈它.我在多个大型多人团队Mac和iOS开发环境中做了很多年.我们尝试了几乎所有不同的解决方案,包括Frameworks他们只是iOS上的新手.)

在您描述的组织内,我强烈建议将每个依赖项打包为自己的框架(AFNetworking,JSONKit等)以及每个部分作为框架,然后让应用程序开发人员将所有这些依赖项链接在一起.通过这种方式,它与其他动态库(libcurl,openssl等)相同,后者需要app dev将所有内容链接在一起.

在任何情况下,动态框架都不应包含其他可能需要的框架(即框架不应包含"第三方"内容).那会爆炸.你不能让它不爆炸.您可能会遇到膨胀,构建冲突或运行时冲突.就像合并冲突一样.开发者必须做出选择.应用级链接正在做出这种选择.

使组件过度依赖其他组件是几十年的麻烦的源头,从Windows DLL Hell到具有竞争崩溃处理程序的iOS应用程序.所有最好的组件系统看起来都像Legos,最终用户组装具有最小依赖性的小块.尽可能让你的内部框架只依靠Cocoa.这有一些有形的设计影响:

避免直接需要日志记录或分析引擎.提供可以适应调用者引擎的委托接口.

避免使用简单的类别(只保存几行代码的方法).只需直接编写代码即可.

避免添加不会为您带来太多购买的框架依赖项.不要AFNetworking只是为了保存几行代码而添加NSURLConnection.当然,如果你在很大程度上依赖于另一个框架的功能,那就不同了.但作为框架开发人员,在需要另一个框架之前,您的阈值应该非常高.

强烈避免在构建或版本控制中变得聪明.我见过很多人都希望为应用级开发人员"自动"创建所有内容,因此使系统变得非常复杂.只需说"你需要链接这个并导入它并将其放入你的app delegate startup中." 不要创建复杂的构建和版本控制系统,以便在第一个构建或两行初始化逻辑上节省2分钟.这些东西爆炸,浪费时间来解决.不要用+load魔法聪明.只要说清楚和一致.

当然,祝你好运.支持其他开发者总是一个有趣的挑战.