在 xcode/objective-c 中的项目之间共享类答案

【问题标题】：Sharing classes between projects in xcode/objective-c在 xcode/objective-c 中的项目之间共享类
【发布时间】：2011-01-08 17:50:02
【问题描述】：

我有一个客户端我正在为 Mac OS X 构建的服务器应用程序，使用 Objective-c/Cocoa 和 xCode。我为我拥有的两个应用程序创建了一个不同的项目，我想知道在它们之间共享课程的最佳方式。我做了几个对两者都有用的课程。到目前为止，我一直在复制它们，但我觉得这不是最好的解决方案。

我如何有效地分享课程？我应该将它作为 1 个项目重做并且只有两个构建目标吗？我该怎么做？

还有其他信息吗？

谢谢。

【问题讨论】：

标签： objective-c xcode macos sharing

【解决方案1】：

我有一个类似的问题，上面接受的答案可能会给新手带来问题。

如果两个项目通过某种协议进行通信，例如TCP/IP，或者如果它们不通信。但是，如果一个项目是一个捆绑包（例如插件），它需要访问与应用程序相同的类（同时在同一个进程中运行），您将遇到链接问题或运行时警告/关于具有相同名称的类的错误。解决这个问题最简单的方法是使用框架。使用框架，您可以将其设置为所有三个目标都在同一个项目中，或者您甚至可以将框架包含在单独的项目中。

我有一个包含应用程序和捆绑插件的项目，这是我在 Xcode 6 中遵循的步骤：

创建一个框架，复制所有共享代码。
在框架的主标头中，包含所有共享代码的标头。
构建框架以测试其构建（例如选择框架的方案并点击播放）
转到应用程序和插件包的构建阶段部分，并将新框架添加到“目标依赖项”和“将二进制文件与库链接”
要在应用程序和捆绑包的代码中包含框架内容，只需使用主标头，并使用而不是“”，例如，如果您的框架被称为 Foo，请使用 #import

当您运行主应用程序时，将自动编译对框架的更改，因此您实际上可以忽略它们是不同目标的事实。

【讨论】：

【解决方案2】：

如果您有两个或多个要共享大量公共代码的产品（例如一套产品），您可能需要考虑只创建一个 xcode 项目，然后为每个产品添加一个不同的目标将由共享代码和特定于产品的代码构建。如果有大量共享代码，客户端/服务器产品对可能是采用这种方式的绝佳选择。

归结起来，基本的处理是，对于您要构建的 xcode 项目中的每个目标，您指定应该使用哪些文件来构建它：源文件、艺术、xib 等。这样，例如，您可以设置使用文件 A、B、C、D、E、F 构建您的客户端产品，并使用文件 A、F、X、Y、Z 构建您的服务器产品。

我真的很喜欢将所有相关产品都放在一个 xcode 项目“屋顶”下，因为您不必在 xcode 项目之间跳来跳去，而且它确实简化了共享文件的 SCM 管理。

这里是苹果文档的链接：https://developer.apple.com/library/mac/#featuredarticles/XcodeConcepts/Concept-Targets.html

更新：在 xcode 中配置特定于目标的头文件时会涉及一些额外的麻烦（它总是......对吗？！）；例如，对此目标使用“myHeaderA.h”，对该目标使用“myHeaderB.h”。这是一篇很棒的帖子，分享了如何做到这一点：controlling which project header file Xcode will include。注意：以这种方式设置后，xcode 不再知道搜索任何目标头文件的路径，因此您必须手动设置它们。为此，请右键单击目标上的获取信息，选择构建类别，然后通过“标题搜索路径”设置添加路径。路径将按照您输入的顺序进行搜索。

【讨论】：

是的 - 我现在正在运行 Xcode 4.3.2，不需要更改任何内容。

【解决方案3】：

一个很好的方法是将共享代码放入 SCM 系统，并将其包含到您想要的每个项目中。这样每个项目都可以共享代码，您可以在任何地方编辑它，只需检查更改当你感觉良好时进入源代码控制——然后所有其他项目都会从你的工作中受益。

与 IMO 的其他方式相比，这具有很大的优势：

对比框架：将代码打包到一个框架中非常烦人，并且捆绑私有框架需要非常长的时间来加载——尤其是在你的应用程序中添加一些类时。 Omni Group 的 Wil Shipley（当时）曾经发现，该公司在其所有应用程序中包含的框架都会使每个应用程序的启动时间增加几秒钟。在框架中打包私有类也可以鼓励更多的耦合，而不是严格必要的——将一个真正的框架放在所有共享类所在的地方真的很诱人，所以你开始假设这段代码将永远在一起。它变得密不可分。基本上，框架就是一把锤子，这个问题就是螺丝钉。

对比仅包含文件：希望您无论如何都会将您的应用程序放入 SCM，并且简单地包含文件会产生问题，因为它们会从 SCM 中丢失。将文件复制到每个项目中会带来相反的问题 - 每个项目都将包含自己的文件版本，您必须手动传播任何有用的更改。

【讨论】：

嗨 Chuck，我正在考虑这种方法，但我不确定“将其包含在您想要的每个项目中”实际上意味着什么。您是在谈论在 XCode 中做某事还是像 SVN 外部属性之类的东西？你到底什么意思？谢谢。
感谢 Chuck 的回答，这听起来像是找我的路。但是，我几乎是这个主题的新手。你有更详细的解释/例子的来源吗？
@chuck 你有没有机会看到教程或写下你的建议？

【解决方案4】：

我在这里找到了一篇关于这个主题的好文章：http://www.clintharris.net/2009/iphone-app-shared-libraries/ 这回答了我的问题，特别是关于多个 iPhone 应用程序共享代码的问题。它没有提到框架（上图），所以我不能说他们的建议（xcode 项目参考）是否优于框架解决方案。

【讨论】：

iPhone 的情况与文件系统和共享库的限制大不相同。

【解决方案5】：

最快的解决方案是仅将 .h 和 .m 文件的引用添加到其中一个项目中。只需取消选中 xcode 中“添加现有文件”对话框中的“复制”复选框即可。请记住，如果您移动/共享您的项目，您可能还需要复制引用的文件。

【讨论】：

这可以很好地与源代码控制配合使用吗？我猜框架解决方案会更自然地与 CVS 和朋友一起工作。

【解决方案6】：

最好的方法是创建一个包含共享类的单独框架。这可以编译一次并链接到两个应用程序项目中。

见Apple's doc on what are Frameworks。

【讨论】：

根据我的经验，框架只适用于你真正锁定的代码；您不期望发生变化的地方。（实际上，这永远不会发生。事情总是在变化。）它们在纸面上听起来不错，但框架往往会妨碍我，它们会扼杀快速发展和创新（因为你不想去改变框架，以免您在另一个应用程序中破坏了某些内容）并且通常是代码共享的糟糕选择，除非您每年更新一次库（例如 Apple）。
@Womble 好吧，不要更改任何可能破坏其他应用程序的内容...如果您发现自己想要这样做，则将旧方法标记为已弃用并编写新方法。 ..