在 Cocoa 中的进程之间传递数据的最佳实践答案

【问题标题】：Best practices for passing data between processes in Cocoa在 Cocoa 中的进程之间传递数据的最佳实践
【发布时间】：2010-10-04 23:37:10
【问题描述】：

我正在解决一个需要我在 64 位 Cocoa 应用程序中执行以下操作的问题：

从我的应用程序中生成一个 32 位 Cocoa 辅助工具（命令行工具）。此帮助程序将打开一个文件（准确地说是 QuickTime 电影）并使用仅限 32 位的 API（Quicktime-C API）访问有关该文件的信息
从 32 位进程收集的数据需要传回 64 位应用程序。
64 位应用程序应等到 32 位进程完成后再继续

在 Cocoa 中有很多方法可以实现这一点，但据我所知，这是我可以采用的两种方法。

选项 1：带有管道的 NSTask

所以我对 StackOverflowers 的问题是，哪个选项“更好”？
哪种做法更好？
哪个更有效率？

我倾向于选项 2，因为似乎涉及的代码更少。如果这两种方法都不是很好，有没有更好的方法来做到这一点？

【问题讨论】：

【解决方案1】：

您说子流程将是一个应用程序。不要为此使用 NSTask——它会混淆 Launch Services。（如果你的意思是它是一个辅助工具，让好奇的专家用户可以从命令行运行它，那么 NSTask 就可以了。）

无论哪种方式，DNC 都可以工作，但如果子进程确实是一个应用程序，则不要使用 NSTask+NSPipe——使用分布式对象。

【讨论】：

啊，我的错。我的意思是 32 位应用程序将成为一个辅助工具（命令行实用程序）。我将更新问题描述以澄清。感谢您的帮助，-尼克
我就是这么想的。在这种情况下，NSTask + NSPipe 是可以的，但通常更适合您可能希望在文件中找到的输出（例如，HTML、RTF、图像、声音、电影）。对于较小的或混合的（例如 HTML + 电影）有效负载，DNC 或 DO 可能是更好的选择。

【解决方案2】：

NSDistributedNotificationCenter 可以正常工作，但请记住，您的应用程序并不能“保证”接收操作系统的分布式通知。我实际上并没有在实践中看到这一点，但在您选择技术时要牢记这一点。

您没有提到的另一个选项是分布式对象。分布式对象正是为此目的而制作的。它处理序列化或设置在进程之间或通过网络工作的代理对象。文档有点缺乏，它不支持 Cocoa 的一些较新的部分，比如绑定，它不是很容易使用，但是当我处理两个以复杂方式协同工作的进程时，我仍然更喜欢它。

【讨论】：