多个框架和通用库 [英] Multiple frameworks and common library

问题描述

使用 iOS 8，Xcode 6 。

假设我有2个动态框架， frameworkA 和 frameworkB 并且它们都依赖于 libC 。另外，我有一个使用 frameworkA 和 frameworkB 的应用程序。我最初的想法是使 frameworkA 和 frameworkB 伞形框架和 libC 子帧。但是，Apple建议不要使用伞形框架，这个帖子描述了为什么伞形框架由于潜在的链接器冲突问题，这是个坏主意。

Let's say I have 2 dynamic frameworks, frameworkA and frameworkB and they are both dependent on libC. In addition, I have an app that uses both frameworkA and frameworkB. My original thought was to make frameworkA and frameworkB umbrella frameworks and libC a subframework. However, Apple advises against umbrella framework and this post describes why umbrella framework is a bad idea due to potential linker conflict issue.

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

My second option is to use cocoapods (still new to this so a bit fuzzy on details) to use libC as a pod which then gets compiled into frameworkA and frameworkB. However, it occurred to me that both frameworks still has its own copy of the libC. Since the app uses both frameworks, will this result in a linker conflict issue as well? Is there a better way to solve this problem?

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

UPDATE @Rob The projects I work on do require complex dependency management but I kept the problem domain simple in the question to try to better understand how and if using cocoapods can help solve the linker conflict issue with umbrella frameworks. I work with a team of developers who write libraries and can depend on each other's base libraries that provide versioned common APIs. We are required to package and deliver as few libraries as possible to a different organization that is building an app with our libraries and one of their key requirement is that we deliver a dynamic framework.

推荐答案

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

The best way to solve most problems is to put all the code in a project and compile it. When you have specialized problems that make that problematic, then you should look at other solutions, such as static libraries, and finally frameworks.

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

Static libraries can make sense if you have a code base that has pieces which require different build requirements. If all the pieces have the same build settings, then just "add files" them into your project from a "common" directory and build your project. Static libraries can be attractive if your build times are very significant and some pieces never change and you want to be able to "clean" without rebuilding those parts. But wait until you start having that problem before you go making complicated multi-package projects.

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

If you sell closed-source libraries, then frameworks are very attractive. You should strongly avoid adding third-party dependencies for the reasons you note. If you must, the best way is to help your customers package all the pieces as frameworks and have them link everything at the end. But that adds a lot of annoyance; so make sure you really need that third-party piece.

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

You might also consider frameworks if you have a very large piece of reusable code that has its own lifecycle separate from the main products. But again, keep it simple. Avoid third party stuff inside of it, and if you must have third party stuff, then have the consumers link it at the end.

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

(This isn't a new solution, BTW. When you use curl, if you want SSL, you need to also download and build OpenSSL and link them together yourself. Curl doesn't come with OpenSSL built in.)

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

But in the vast majority of cases, this is all overkill. Don't jump to frameworks. Don't jump to libraries. Just put all the code in the project and compile it. 90% of your problems will evaporate. iOS projects in particular just aren't that big usually. What problem is a framework solving?

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

If you have a lot of code that your organization uses repeatedly in lots of products, then I have heard many teams have good luck using internal CocoaPods to manage that. But that's just to simplify checking the code out. It still all goes into a project and you compile it together into one binary; no frameworks needed. Dynamic frameworks are a nice feature in for certain kinds of problems that were really painful before. But, for most situations, they're just complexity looking for a problem.

（如果你有其中一个专门的问题，请编辑你的问题，我很高兴进一步讨论如何处理它。）

(If you have one of those specialized problems, edit your question and I'm happy to discuss further how you might approach it.)

(你陷入了专门的问题，所以让我们谈谈吧关于它。我在一个大型的多团队Mac和iOS开发环境中做了很多年。我们尝试了几乎所有不同的解决方案，包括Frameworks。它们只是iOS上的新功能。）

(You fall into that "specialized problem," so let's talk about it. I did, too, for many years inside of a large multi-team Mac and iOS dev environment. And we tried just about every different solution, including Frameworks. They're only new on iOS.)

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

Within an org like you describe, I would strongly recommend packaging each dependency as its own framework (AFNetworking, JSONKit, etc) and each of your pieces as a framework, and then have the app devs link all of them together at the end. In this way, it is identical to other dynamic libraries (libcurl, openssl, etc.) which require the app dev to link everything together.

在任何情况下都不应该是动态框架包括其他可能需要的框架（即框架不应该包装第三方的东西）。那会爆炸。你不能让它不爆炸。您可能会遇到膨胀，构建冲突或运行时冲突。就像合并冲突一样。开发者必须做出选择。应用级链接正在做出这样的选择。

In no case should dynamic frameworks include other frameworks that could otherwise be required (i.e. frameworks should never package "third party" stuff). That will explode. You cannot make that not explode. You'll either have bloat, build conflicts, or runtime conflicts. It's like merge conflicts. There's a point at which a developer has to make a choice. App-level linking is making that choice.

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

Making components over-dependent on other components is the source of decades of trouble, from Windows DLL Hell to iOS apps with competing crash handlers. All the best component systems look like Legos, where the end user assembles small pieces that have minimal dependencies. As much as possible, make your internal frameworks rely on nothing but Cocoa. This has some tangible design influences:

• 避免直接要求记录或分析引擎。提供一个可以适应调用者引擎的委托接口。


• 避免使用简单的类别（只保存几行代码的方法）。只需直接编写代码即可。


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


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

• Avoid directly requiring logging or analytic engines. Provide a delegate interface that can be adapted to the engines of the caller.
• Avoid trivial categories (methods that save just a few lines of code). Just write the code directly.
• Avoid adding framework dependencies that aren't buying you a lot. Don't add AFNetworking just to save a few lines of code over NSURLConnection. Of course if you're heavily relying on the features of another framework, that's different. But as a framework developer your threshold should be quite high before requiring another framework.
• Strongly avoid being clever in the build or version control. I've seen too many cases where people want to make everything "automatic" for the app-level developer, and so make the system really complicated. Just say "you need to link this and import this and put this in your app delegate startup." Don't create complicated build and version control systems to save 2 minutes on the first build or two lines of initialization logic. These things blow up and waste hours to work around. Don't get clever with +load magic. Just make it clear and consistent.

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

And of course, good luck. Supporting other devs is always an interesting challenge.

这篇关于多个框架和通用库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！