我正在开发一款可以进行视频处理的iPhone应用程序，我必须将其包含在不符合ARC标准的类中（dealloc，发布内容）。所以我手动去了，使它们符合弧线。
后来我发现任何类的编译器标志都可以使它成为ARC项目中的非ARC -fno-objc-arc。
我的问题是，如果我用编译器标志标记这些类，那么它的代表是什么？性能打击？这是个好主意吗？我的应用程序iOS 5.0及以上。我找不到任何谈论这样做的利弊的资源。
答案 0 :(得分：3)
你问：
如果我用编译器标志标记这些类，会有什么影响呢？
我认为你唯一需要担心的是确保非ARC库遵循与内存管理相关的Cocoa命名约定（例如，如果名称以{开头}，则只返回+1 retainCount的对象{1}}，alloc，new或copy）。否则，您的ARC将无法正确管理生成的对象。大多数编写良好的类都符合这种模式，因此使用mutableCopy标志应该完全没问题，但它完全取决于所讨论的类。
[有没有]性能受到影响？
没有实际的性能问题。
[这是一个好主意吗？
在所有条件相同的情况下，我通常喜欢将代码转换为ARC。我可能会避免转换的几种情况：
这是一个积极开发的库，如果我创建自己的个人ARC分叉，我将会失去对该库的未来版本。
该库非常复杂和/或具有不易转换为ARC的构造。
最重要的是，如果我可以转换为ARC，我会的。通常在这个过程中，我会做必要的测试，以确保我对库感到舒服，没有泄漏等，所以这是一个有效（如果讨厌）的过程。我们都对我们项目中包含的代码负责，并且我认为不应该在没有经过ARC转换和测试过程的自然副产品的尽职调查的情况下集成代码。
如果我转换为ARC，我提议将转换贡献给原作者（例如通过GitHub“拉取请求”或作者打开的任何机制），以便将其集成到代码库中。
答案 1 :(得分：0)
乍一看，使用或不使用ARC没有性能问题。 ARC基本上是正常的引用计数，它不是程序员插入release调用，而是编译器。