objective-c - 带有ARC服务器和32位代理的Objective-C分布式对象？

Question

我有一个使用 ARC 的 64 位应用程序，它提供分布式对象。使用代理对象的应用程序是 32 位应用程序，所以它没有使用 ARC。这会给我带来麻烦吗？

我还想在我的 32 位应用程序中重用 64 位/ARC 应用程序中的类。如果这些是 ARC，我如何将它们集成到非 ARC 应用程序中？

Answer 1

我不建议这样做。在 32 位和 64 位运行时之间使用分布式对象似乎是可能的，但它有一些问题。从基础常量参考：

在 Mac OS X v10.5 之前，NSNotFound 被定义为 0x7fffffff。对于 32 位系统，这实际上与 NSIntegerMax 相同。为了支持 64 位环境，NSNotFound 现在正式定义为 NSIntegerMax。但是，这意味着该值在 32 位和 64 位环境中是不同的。因此，您不应将值直接保存在文件或档案中。此外，通过分布式对象在 32 位和 64 位进程之间发送值不会让您在另一端获得 NSNotFound。这适用于通过分布式对象调用并可能返回 NSNotFound 的任何 Cocoa 方法，例如 NSArray 的 indexOfObject: 方法（如果发送到数组的代理）。

当然，您可以对 -[NSArray indexOfObject:] 进行一些基本的完整性检查，但是如果您使用的任何库或框架（包括 Cocoa 和 Foundation）使用可以返回 NSNotFound 的 API 怎么办？更不用说这只是 32 位和 64 位运行时之间通信时可能发生的一个问题，其他问题可能没有记录在案。

由于分布式对象的一些其他问题，我倾向于回避分布式对象，但即使您决心使用它们，这对我来说似乎也是一个交易破坏者。

我不相信 ARC 有任何内在的东西会阻止您一起使用 ARC 和分布式对象。然而，分布式对象的内存管理可能很棘手。如果您需要打破标准的保留释放规则来解决客户端和服务器之间的内存泄漏问题，ARC 不会让您这样做。您需要格外小心地构建您的服务器以避免这种情况。

最后，由于您不能在 32 位运行时中使用 ARC，因此您必须为这些类编写手动保留/释放代码。如果您打算最终摆脱非 ARC 代码，则可以利用__has_feature(objc_arc)。否则，最好不要在您计划在 32 位和 64 位应用程序之间共享的文件上使用 ARC。ARC 可以在每个文件的基础上启用或禁用。