在为10.5+写作时，我应该使用Objective-C垃圾收集吗？

Question

在OS X 10.5+环境中编写相当典型的Mac代码时，使用垃圾收集有哪些缺点？

到目前为止，我写的所有其他内容都是10.4兼容的，或者在iPhone上，所以我对保留/发布变得相当舒服，但现在我正在开发一个只有10.5的大型项目。想知道继续使用Objective-C 2.0垃圾收集器是否有任何缺点。

你们有什么想法？

Answer 1

如果您正在编写新的Cocoa代码并定位到Mac OS X 10.5，请使用Objective-C垃圾回收。

如果你正在编写一些可能还需要在iPhone上运行的代码，你可以通过将代码保存在一个单独的框架中来编写并测试这两个模型的代码，并用属性-retain和-release使用，并将框架和单元测试目标设置为 GC支持的，而不是仅GC 。

Xcode将运行您的单元测试包两次，一次启用GC，一次关闭GC，您的框架将在两种执行模型下运行。然后，如果您最终想要将该模型级代码带到iPhone，您可以将其放在以iPhone为目标的静态库中，或直接将其包含在您的iPhone项目中。

无论您是否考虑在iPhone上运行代码，如果您的应用程序需要Leopard，您绝对应该定位垃圾收集。它将简化开发，Objective-C垃圾收集器的性能非常好。

Answer 2

如果可以将您的应用程序移植到iPhone，则不应使用它。

如果您有特殊用例，垃圾收集可能会对性能产生负面影响。如果没有GC，您可以精确控制对象的破坏，这不是GC世界的情况。在大多数项目中，打开GC是值得的，因为它不易出错且更容易。

在理论中，没有GC的内存管理总是比使用GC更快，但是，在大多数实际应用中并非如此（因为GC通常比人类更优化）。

Answer 3

我更喜欢自己处理内存管理，因为我喜欢拥有这种级别的控制权。我从其他语言（C＃）的经验中了解到GC不允许你完全忽略内存问题，并且在Cocoa中使用弱引用和回调使用（void *）这样的东西是相同的，其中对象没有明确拥有另一个对象。你基本上是为另一个挑战（内存泄漏）。就个人而言，这些天我并不倾向于犯太多内存管理错误，我所做的那些错误很容易被追踪。

在某些情况下（例如为NSOutlineView实现数据源方法，你不想保留提供给大纲视图的对象）我认为GC会非常有用，但我还没有用它完成了任何真正的测试。

Apple在GC programming guide中列出了其他一些优点和缺点。

Answer 4

GC从10.8开始不推荐使用。实际上从来都不是一个好主意，采用这种技术，除非性能和稳定性目标从未得到满足。

“手动”管理内存实际上非常简单，因为管理代码可以在很大程度上被考虑在内。我的代码库有＆lt; 1％的代码与内存管理相关，而且比它需要的大。因此，我对ARC也持怀疑态度，因为它所解决的问题非常小，即使是相当小的技术问题使得它不值得。