ios - ARC兼容项目中的非ARC类？

Question

我正在做一个iPhone应用程序，该应用程序执行一些视频处理，我必须将其包括到不兼容ARC的类中(dealloc，发布东西)。所以我手动去使它们符合电弧。
后来，我发现可以在ARC项目-fno-objc-arc中使其变为非ARC的任何类的编译器标志。

我的问题是，如果我确实使用编译器标志来标记这些类，那么这会产生什么影响？性能受到打击？这是个好主意吗？我的应用程式iOS 5.0以上。我找不到任何有关这样做的利弊的资源。

Answer 1

你问:

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

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

[是否有性能下降？

没有实际的性能问题。

[这是不是一个好主意？

在所有条件都相同的情况下，我通常喜欢将代码转换为ARC。我可能不建议进行转换的几种情况:

这是一个正在积极开发的库，如果我创建自己的个人ARC分支，我将在该库的 future 版本中迷失方向。

该库非常复杂，并且/或者具有不容易转换为ARC的构造。

最重要的是，如果我可以转换为ARC，我会的。通常，在此过程中，我将进行必要的测试，以确保我对库感到满意，没有泄漏等，因此这是一个高效(如果很烦人)的过程。我们都对我们包含在项目中的代码负责，并且我认为没有经过任何尽职调查(这是ARC转换和测试过程的自然产物)的人就不应集成代码。

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