将iOS应用程序移植到mac - 如何处理内存管理？

Question

我的代码当然包含所有保留/释放调用。 。 。用垃圾收集编写mac应用程序可能会更容易（然后我该如何处理保留/发布）或没有？

无论您推荐哪种方式，任何有关Xcode设置的指针都会有所帮助。感谢。

Answer 1

我强烈建议你不出于各种原因在Mac上使用GC，只要坚持你已经习惯做的事情。我相信当你依靠GC管理内存时，你会放弃很多细粒度控制，我个人不喜欢这样做。

由于您已经来自像iOS这样的参考计数环境，我认为留在这样的环境中是明智之举，因为此时您不会花费太多精力。

您需要将视图控制器和基于视图的代码移植到Cocoa，但这不应该太麻烦。您可以放入模型，因为它们没有任何视图依赖项。 （当然假设你做了一点理智）。

Answer 2

我会恭敬地不同意到目前为止已经回复的所有人，并告诉你不要马上解雇Mac上的垃圾收集。我的所有Mac应用程序都使用垃圾收集，我构建的所有新应用程序都会这样做。

垃圾收集为我节省了大量的麻烦，就是大量的多线程代码。在内存管理方面，我认为自己相当健全，但涉及跨线程发布和自动释放的边缘情况导致大量机器人控制软件偶尔崩溃，直到我将其转换为垃圾收集。之后所有这些问题都消失了，导致整体稳定性大大提高（我连续六个月没有看到其中一个最新版本的崩溃）。

如果开发将在Mac和iOS之间共享的代码，请务必按照标准内存管理规则进行编写，以便保持良好的习惯并保证可以来回复制和粘贴内容。然后，您可以在Mac版本中将垃圾收集作为构建时设置启用，以便在您错过泄漏或过度发布的情况下充当安全网。您不会以这种方式保存代码，但这可能会提高应用程序在部署到用户时的稳定性。

但是，某些框架（如Core Image）在垃圾收集方面效果不佳，因此如果您在应用程序中使用其中一个框架，则可能需要避免使用GC。

正如Mike Ash在他的文章“Perform Better With Garbage Collection”中指出的那样，垃圾收集器在后台线程上运行的事实可以导致多核Mac上的某些应用程序的性能略有提升。例如，它可以防止主线程中的暂停，有时在紧密循环中看到，因为自动释放池被耗尽，或者其他对象被释放。

最后，我喜欢在垃圾收集下测试我的跨平台Cocoa代码，以确定我在-dealloc（它真的不属于）的地方放置了与内存相关的清理代码，因为{{1不再在垃圾收集下调用。这有助于我更好地构建我的代码。

Answer 3

保持原样。不使用GC将允许它在mac上运行得更快。它还可以让您更好地控制事物何时停留以及何时停留，最终可能会为您提供更稳定的应用程序。

它还可以让您更轻松地将您在Mac上编写的内容移植回来。如果你回到iOS，这样做也会让你养成习惯。

所以简而言之，如果你已经做了内存管理，那就继续这样做吧！