我有一个应用程序，我没有在整个应用程序中使用ARC。但在某些视图控制器中，我使用的是compler标志-fobjc-arc。我不知道它是如何工作的，而且也有其优点和缺点，那是一种很好的技术？这样做是否有不利影响？任何机构都有这种体验吗？有谁能够帮助我？。我也使用Xcode 4.2和LLVM编译器3.0。它实际上是一个非弧视图控制器。但我添加了编译器flag.and，并删除了编译的错误releases.is，这就足够了将视图控制器转换为ARC的效果如何？
但是我发现这是非常棘手的，觉得这篇文章是一个很好我的事业的书面例子。 http://www.codeography.com/2011/10/10/making-arc-and-non-arc-play-nice.html
您通常会想要接近这个过程使用重构实用程序Xcode提供：Edit > Refactor > Convert to Objective-C ARC…。
MRC和ARC二进制文件能够无缝协作。它们是兼容的。
当然，您需要确保您的程序对于正在编译的模式是正确的。如果标志错误并且您省略了引用计数操作，那么静态分析器会给出一些提示 - 否则编译器在看到引用计数操作时会出错。像往常一样，在编译时和运行时检查泄漏，找出你的眼睛错过了什么。
执行速度可能略有不同（可能会更快/更慢）。记忆水高点可能会有所不同。 ARC程序通常等同于写得很好的MRC。
@ justin ..感谢你的关注。我的意思是我刚刚在编译source.then中添加了-fobjc-arc，当我编译了一些错误，如release等，然后我删除了所有的autoreleases和release。然后错误消失了。我真的是newbee arc.is，足够 – hacker 2013-03-06 09:24:11
分析仪显示在视图控制器没有泄漏.. - – hacker 2013-03-06 09:29:07
@ hacker欢迎您。自动转换为ARC通常是正确的，但并不完美。真正的节目太复杂了。所以自动化过程非常简单，大部分时间都是正确的。但是，它可以引入一些变化，并且您需要预留时间来重新测试您的程序（并进行必要的修理）。对于那里的很多程序，转换过程仍然可以减少错误计数。 – justin 2013-03-06 09:29:27
这种方法没有问题。
ARC是一个编译时功能，它会在编译时在您的弧代码中插入retain，release调用。
所以你的弧代码和编译后的非弧代码一样。所以我认为这种方法不会有问题。
但整个项目转换为ARC将是最好的办法，因为你并不需要担心的保留，呼吁释放
@ mdhun ..感谢您的关注。我的意思是我刚刚在编译source.then中添加了-fobjc-arc，当我编译了一些错误，如release等，然后我删除了所有的autoreleases和release。然后错误消失了。我真的是newbee in arc.is that enough ......现在我在该视图中没有发布控制器..分析器在视图控制器中显示没有泄漏.. – hacker 2013-03-06 09:26:15
我完全同意@Midhum，如果您想了解更多关于ARC如何使用文档http://developer.apple.com/library/ios/#releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html – tkanzakic 2013-03-06 09:30:56
@hacker：无需担心。当你将非弧转换为弧时，删除释放，保留和自动释放。如果您需要在autoreleasepool中添加任务。你可以使用'@ autorelease'关键字。 – 2013-03-06 09:50:39
ARC帮助您编写更少的代码。它可以提高性能，但你真的不应该指望那个 – 2013-03-06 09:20:18