在同一iOS项目中混合使用ARC和非ARC代码有多安全？

Question

我正在修改一个非ARC的开源应用程序。我的大部分iOS经验都是使用启用了ARC的Objective-C，因此当我创建并添加新文件到项目中时，我倾向于使用编译器标志使它们符合ARC（特别是当我面对奇怪的非ARC代码错误时）。

让我夜不能寐的问题是：在我的项目中混合使用ARC和非ARC代码有多安全可靠？当进行QA测试时，是否会变成测试内存泄漏和性能等方面的噩梦？换句话说...将现有的非ARC代码转换为ARC代码并摆脱潜在的麻烦是否值得呢？

- abbood

---

这些是编译器标志，而不是链接器标志。此外，使用ARC并不能使您免于需要测试您的应用程序以检测泄漏和性能问题。 - Kurt Revis

Answer 1

你可以自由混合而不会出现任何问题。

- sosborn

---

是的，确实这就是你需要的所有答案。有一个注意事项（关于预编译代码具有糟糕命名惯例欺骗ARC过度释放），但我认为这不适用于此情况。 - borrrden

嗯，我非常尊重你们两个，并承认你们的技术经验。不过，我希望能够看到一些证据或文献支持你们的回答？还是说你们的回答仅基于个人经验（这本身可能已足够）？ - abbood

@abbood - ARC并不是魔法，它只是在编译时查看您的代码并添加必要的保留和释放。生成的代码与您自己编写的代码没有任何区别。从过渡到ARC发布说明中可以看到：“如果对于某些文件使用手动引用计数更方便，则还可以选择按文件使用ARC。” - sosborn

你能解释一下 -fno-objc-arc 编译标志的目的/需要吗？我正在使用一个 pre-arc 库，它说要为其每个源文件添加此标志。 - devios1

需要使用-fno-objc-arc标志来编译不使用ARC的代码。打开ARC后，retain/release/autorelease是非法的。如果您编译不适用于ARC并包含这些调用的代码，则必须为该文件关闭ARC。请确保使用静态分析器查找任何问题 - 静态分析器基本上会找出ARC将执行哪些retain/release调用，代码执行哪些调用，并进行比较。 - gnasher729

Answer 2

我认为开启ARC后，某些代码是被禁止的，例如这个方法，因此不安全。

- (void)dealloc
{
    [super dealloc];
}

当然，在发布时：

[exampleVariable release];

这可以存在于非ARC项目中。

- user2047438

---

我的问题是假设所有这类不安全的代码已经被考虑在内（即被取出）。 - abbood

在这种情况下，这是完全安全的，因为这是唯一重要的事情。 - user2047438

考虑到非ARC代码，这样做不会本质上使其成为ARC代码吗？ - devios1