在一个符合ARC标准的项目中，如何处理非ARC类？
在使用或不使用自动引用计数（ARC）时，一开始看起来没有性能问题。ARC基本上是普通的引用计数，只是编译器而不是程序员插入了释放（release）调用。
然而，在ARC兼容项目中使用非ARC类会导致一些问题。这是因为非ARC类不会自动进行内存管理，而ARC会自动管理内存。因此，当在ARC项目中使用非ARC类时，可能会导致内存泄漏或释放过早的问题。
解决这个问题的方法是使用手动引用计数（MRC）的技术来管理非ARC类的内存。这涉及到手动插入retain和release调用来跟踪引用计数并确保正确的内存管理。
以下是在ARC兼容项目中使用非ARC类的示例代码：
// 非ARC类的声明
@interface NonARCClass : NSObject
@property (nonatomic, strong) NSString *name;
@end
// 非ARC类的实现
@implementation NonARCClass
- (void)dealloc {
[_name release];
[super dealloc];
}
@end
// 使用非ARC类的ARC项目
NonARCClass *nonARCObject = [[NonARCClass alloc] init];
nonARCObject.name = @"Test";
// 使用nonARCObject
[nonARCObject release];
在上面的示例中，我们手动插入了release调用来释放nonARCObject对象的内存。这确保了在ARC兼容项目中使用非ARC类时正确管理内存。
使用非ARC类在ARC兼容项目中可能会导致内存管理问题。为了解决这个问题，可以使用手动引用计数技术来手动管理非ARC类的内存。这涉及到手动插入retain和release调用来正确跟踪引用计数并确保内存的正确释放。
在一个ARC兼容的项目中使用非ARC类是一个常见的问题。如果标记了这些类，会有什么后果？唯一需要担心的是确保非ARC库遵循与内存管理相关的Cocoa命名约定（例如，只有在名称以alloc、new、copy或mutableCopy开头时，返回+1的retainCount的对象）。否则，ARC将无法正确管理生成的对象。大多数编写良好的类都会遵循这种模式，所以可以放心使用fno-objc-arc标志，但这完全取决于所涉及的类。
在实际性能方面没有问题。
如果可以转换为ARC，我会这样做。通常在这个过程中，我会进行必要的测试，确保我对库感到满意，没有泄漏等等，所以这是一个有成果（尽管有点烦人）的过程。我们都对我们项目中包含的代码负责，我认为在没有经过ARC转换和测试过程的尽职调查的情况下，不应该整合代码。
如果我转换为ARC，我会提供将转换结果贡献给原始作者的机会（例如通过GitHub的“pull request”或作者接受的任何其他机制），以便可以将其集成到代码库中。