Objective-C 中的引用计数警告？
长期以来，我一直认为自己是一个垃圾收集势利小人——尽管我暗恋 C++，但我发现自己嘲笑那些积极选择使用没有（阅读：缺少）垃圾收集的语言的开发人员的选项。
然后我遇到了 Objective-C。哇！它的引用计数系统看起来非常简单——我什至可以说优雅。在针对 OSX 进行开发时，开发人员可以选择使用时髦的 GC；在为 iOS 进行开发时，开发人员会陷入引用计数的困境。
我的问题是：
如果我正在开发一个可以潜在移植到 iOS 的 OSX 应用程序，Objective-C 的引用计数系统是否足够耗时（开发方面和错误修复方面）以保证应用程序的第一个版本忽略它？
如果我依赖引用计数*，假设我不够聪明，无法构建任何极其复杂的循环数据结构，那么我可能会遇到什么问题？有了像自动释放这样的功能，一切看起来都很简单，但我知道如果真是这样，Apple 就不会投入精力来创建垃圾收集器。我应该注意什么？
* 我知道即使我乱扔 retain 和 release （它们将被忽略），我也可以使用垃圾收集器。但是，考虑到非 GC 应用程序经常使用 RAII，我不明白如果分代GC将“替换”对retain和release的调用。资源会不会延迟释放？
I've long considered myself a garbage collection snob – despite a secret love for C++, I find myself sneering at developers who actively choose to use languages without (read: missing) garbage collection when they're given the option.
And then I met Objective-C. Wow! Its system of reference counting seems brilliantly simple – I'd even go so far as to say elegant. When developing for OSX, developers are given the option to use a snazzy GC; when developing for iOS, developers are stuck with reference counting.
My question is:
If I am developing an OSX application that could potentially be ported to iOS, is Objective-C's reference counting system time-consuming enough (development-wise and bug-fixing-wise) to warrant ignoring it for the application's first version?
What problems am I likely to run into if I rely on reference counting*, assuming I'm not clever enough to construct any diabolically complex cyclical data structures? With features like autorelease, it all seems so easy, but I know that Apple wouldn't have invested the effort into creating a garbage collector if this were really the case. What should I be on the lookout for?
* I am aware that I can use the garbage collector even if I am throwing around retains and releases (they'll be ignored). However, considering non-GC applications often use RAII, I don't understand how that would work if a generational GC were to "replace" calls to retain and release. Wouldn't resources potentially be released late?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我在开发代码以移植到 iOS 方面的经验是，采用仅 GC 的代码并将其向后移植到引用计数有点乏味且耗时，并且可能容易出错。话虽如此，只要您尽可能多地使用属性（让它们保留，即使它在 GC 中没有区别）并且启用静态分析器构建阶段，这还不错。静态分析器将捕获大多数未能遵守内存管理规则的情况。如果您在 dealloc 中未能释放 ivar，它不会注意到，但您可以浏览并系统地添加所有 dealloc 方法。
请记住，您不能直接将 Mac 应用程序移植到 iPhone，MVC 的 VC 部分必须完全重写，因此您可以采取仅针对垃圾收集编写 Mac UI 的方法，并且仅使模型类兼容同时具有 GC 和引用计数。
My experience with developing code to port to iOS is that taking GC only code and back porting it to reference counting is a bit tedious and time consuming and potentially error prone. Having said that, as long as you use properties (make them retain even though it makes no difference in GC) as much as possible and you enable the static analyser build phase, it's not too bad. The static analyser will catch most failures to observe the memory management rules. It won't notice if you fail to release an ivar in dealloc, but you can go through and systematically add all the dealloc methods.
Bear in mind that you can't directly port a Mac application to the iPhone, the VC part of MVC has to be completely rewritten, so you could take the approach of writing the Mac UI solely for garbage collection and only make the model classes compatible with both GC and reference counting.