我只是想知道,手动不保留/释放的方便(和推测更可靠的代码,结果吗?)超过使用ARC的任何“成本”?
你对ARC的经验是什么,你会推荐它吗?
所以:
> ARC给项目带来多少利益?
> ARC是否有像Java中的垃圾收集一样的成本?
>你一直在使用ARC,如果是,你怎么发现它到目前为止?
好的,现在我会告诉你的小缺点:
>如果你是一个长期的ObjC开发人员,你会抽搐大约一个星期,当你看到ARC代码。你会很快克服这个。
>在Core Foundation代码中有一些(非常)小的复杂性。在处理任何将ID作为voID *处理的问题上有更多的复杂性。像C数组的ID可能需要更多的思考做正确。花哨处理ObjC va_args也会导致麻烦。大多数涉及ObjC指针数学的事情是棘手的。在任何情况下,你不应该有这么多。
>你不能把一个ID放在结构中。这是相当罕见的,但有时它用于打包数据。
>如果你没有遵循正确的KVC命名,并且你混合ARC和非ARC代码,你将有内存问题。 ARC使用KVC命名来做出有关内存管理的决策。如果它是所有的ARC代码,那么没关系,因为它会做同样的“错误”在两边。但是如果它是混合的ARC /非ARC,那么有一个不匹配。
> ARC会在ObjC异常抛出期间泄漏内存。一个ObjC异常应该在时间上非常接近你的程序的终止。如果你捕获大量的ObjC异常,你使用它们不正确。这是可修复的使用-fobjc-arc-exceptions,但它招致以下讨论的惩罚:
> ARC在ObjC代码中的ObjC或C异常抛出期间不会泄漏内存,但这是以时间和空间性能为代价的。这是另一个很长的原因,以最小化你使用ObjC。
> ARC在iPhoneOS 3或Mac OS X 10.5或更早版本上根本不工作。 (这使我无法在许多项目中使用ARC。)
> __weak指针在iOS 4或Mac OS X 10.6上不能正常工作,这是一种耻辱,但相当容易解决。 __weak指针是伟大的,但他们不是ARC的第一卖点。
对于95%的代码在那里,ARC是辉煌的,没有任何理由,以避免它(只要你可以处理 *** 作系统版本的限制)。对于非ARC代码,您可以在逐个文件的基础上传递-fno-objc-arc。 Xcode不幸的是,这实际上比它应该做的更难。你应该把非ARC代码移动到一个单独的xcodeproj来简化这个。
总之,切换到ARC只要你可以,永远不回头。
编辑
我看到了一些关于“使用ARC不能代替知道Cocoa内存管理规则”的意见。这是真的,但重要的是要了解为什么,为什么不。首先,如果你的所有代码都使用ARC,你违反了Three Magic Words的地方,你仍然没有问题。可怕的说,但你去。 ARC可能保留一些你并不意味着它保留的东西,但它会释放它们,所以它永远不会重要。如果我今天在Cocoa教一个新类,我可能花不超过五分钟的实际内存管理规则,我可能只提到内存管理命名规则,同时讨论KVC命名。使用ARC,我相信你实际上可以成为一个体面的开始程序员,而不学习内存管理规则。
但你不能成为一个体面的中间程序员。你需要知道这些规则,以便与Core Foundation正确衔接,每个中间程序员都需要在某个时候处理CF。您需要知道混合ARC / MRC代码的规则。当你开始使用voID *指针指向ID(你需要继续正确地执行KVO)时,你需要知道规则。和块…好,块内存管理只是奇怪。
所以我的观点是,底层的内存管理仍然很重要,但在那里我花了大量的时间陈述和重述新的程序员的规则,与ARC它成为一个更高级的话题。我宁愿让新开发人员在对象图方面进行思考,而不是用底层的objc_retain()调用。
总结以上是内存溢出为你收集整理的iphone – 到ARC还是不ARC?优缺点都有什么?全部内容,希望文章能够帮你解决iphone – 到ARC还是不ARC?优缺点都有什么?所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)