1

我正在开发一个进行一些视频处理的 iPhone 应用程序，我必须包含不符合 ARC 的类（ dealloc ，release stuff ）。所以我手动去使它们符合弧形。后来我发现了任何可以在 ARC 项目中使其非 ARC 的类的编译器标志-fno-objc-arc。

我的问题是，如果我用编译器标志标记这些类，这会有什么影响？性能受到打击？这是个好主意吗？我的应用程序 iOS 5.0 及更高版本。我找不到任何谈论这样做的利弊的资源。

4

2 回答 2

3

你问：

如果我用编译器标志标记这些类，这会产生什么影响？

我认为您唯一需要担心的是确保非 ARC 库遵循与内存管理相关的 Cocoa 命名约定（例如，retainCount如果名称以alloc、new、copy或开头，则仅返回带有 +1 的对象mutableCopy）。否则，您的 ARC 将无法正确管理生成的对象。大多数编写良好的类都符合这种模式，所以你应该完全可以使用该fno-objc-arc标志，但这完全取决于所讨论的类。

[有] 性能受到影响吗？

不存在实际性能问题。

[这是不是一个好主意？

在所有条件相同的情况下，我通常喜欢将代码转换为 ARC。我可能会避免转换的几种情况：

  • 这是一个正在积极开发的库，如果我创建自己的个人 ARC 分支，我将失去该库的未来修订版。

  • 该库非常复杂和/或具有不易转换为 ARC 的构造。

最重要的是，如果我可以转换为 ARC，我会的。通常在这个过程中，我会进行必要的测试，以确保我对库感到满意，没有泄漏等，所以这是一个富有成效（如果烦人）的过程。我们都对我们项目中包含的代码负责，我认为任何人都应该在没有经过尽职调查的情况下集成代码，这是 ARC 转换和测试过程的自然副产品。

如果我转换为 ARC，我愿意将转换回馈给原始作者（例如，通过 GitHub “拉取请求”或作者开放的任何机制），以便可以将其集成到代码库中。

于 2013-01-26T21:57:20.363 回答
0

乍一看，使用或不使用 ARC 没有性能问题。releaseARC基本上是正常的引用计数，插入调用的不是程序员，而是编译器。

于 2013-01-26T20:03:16.747 回答