iOS 内存管理

本篇随笔记录的是看唐巧写的「iOS开发进阶」书籍的「理解内存管理」知识点汇总，这里分享给大家。

 

Objective-C 和 Swift 语言的内存管理方式都是基于引用计数「Reference Counting」的，引用计数是一个简单而有效管理对象生命周期的方式。引用计数分为自动引用计数「ARC: Automatic Reference Counting」和手动引用计数「MRC: Manual Reference Counting」，现在都是用 ARC 了，但是我们还是很有必要了解 MRC。

 

1. 引用计数的原理是什么？

当我们创建一个新对象时，他的引用计数为1；

当有一个新的指针指向这个对象时，他的引用计数就加1；

当对象关联的某个指针不再指向他时，他的引用计数就减1；

当对象的引用计数为0时，说明此对象不再被任何指针指向，这时我们就可以将对象销毁，回收内存。

 

由于引用计数简单有效，除了 Objective-C 语言外，Microsoft 的 COM「Component Object Model」、C++11（基于引用计数的智能指针 share_prt）等语言也提供了基于引用计数的内存管理方式。

举个例子：

新建工程，Xcode 默认开启的是 ARC，我们这里针对「AppDelegate.m」文件使用 MRC，进行以下配置：

选择目标工程，然后在「Build Phases」的「Compile Sources」下的「AppDelegate.m」文件配置编译器参数「Compiler Flags」值为「-fno-objc-arc」

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    NSObject *objO = [NSObject new];
    NSLog(@"Reference Count: %lu", (unsigned long)[objO retainCount]); // 1
    NSObject *objB = [objO retain];
    NSLog(@"Reference Count: %lu", (unsigned long)[objO retainCount]); // 2
    [objO release];
    NSLog(@"Reference Count: %lu", (unsigned long)[objO retainCount]); // 1
    [objO release];
    NSLog(@"Reference Count: %lu", (unsigned long)[objO retainCount]); // 1
    
    [objO setValue:nil forKey:@"test"]; // 僵尸对象，向野指针发送消息会报错（EXC_BAD_ACCESS）
    
    return YES;
}

Xcode 默认不会监控僵尸对象，这里我们配置开启他，然后就可以看到具体的跟踪信息了：

 

也可以通过选择「Product」下的「Profile」来打开「Instruments」工具集。然后选择「Zombies」，再单击右下角的「Choose」按钮进入检测界面，这时点击左上角的「Record」红色圆点按钮开始检测。

 

1.1 上面例子，为什么最后一次通过 retainCount 获取的值为1，而不是为0呢？

因为该对象的内存已经被回收，我们向一个被回收的对象发送 retainCount 消息，他的输出结果是不确定的，如果该对象所占内存被复用了，那么就可能造成程序异常崩溃。

而且当最后一次执行 release 时，系统已经知道马上要回收内存了，就没必要再将 retainCount 减1，因为不管减不减1，该对象都会被回收，回收后他所在内存区域（包括 retainCount 值）就没有意义了。不将 retainCount 减1变为0，可以减少一次内存操作，加快对象的回收。

 

1.2 什么是僵尸对象、野指针、空指针呢？

僵尸对象：所占用内存已经被回收的对象，僵尸对象不能再使用。

野指针：指向僵尸对象（不可用内存）的指针，给野指针发送消息会报错（EXC_BAD_ACCESS）。

空指针：没有指向任何对象的指针（存储的是 nil、NULL），给空指针发送消息不会报错；空指针的一个经典使用场景就是在开发中获取服务器 API 数据时，转换野指针为空指针，避免发送消息报错。

 

2. 为什么需要引用计数？

从上面简单例子，我们还看不出引用计数真正的用处，因为该对象的生命周期只是在一个方法内。在真实的应用场景中，我们在方法内使用临时对象，通常不需要修改他的引用计数，只需要在方法返回前销毁对象就可以了。

然而，引用计数真正派上用场的场景是在面向对象的程序设计架构中，用于对象之间传递和共享数据。

 

举个例子：

假如对象 A 生成了一个对象 O，需要调用对象 B 的某个方法，将对象 O 作为参数传递过去。

在没有引用计数的情况下，一般内存管理的原则是「谁申请谁释放」，那么对象 A 就需要在对象 B 不再需要对象 O 的时候，将对象 O 销毁。但对象 B 可能临时用一下对象 O，也可以觉得他重要，将他设置为自己的一个成员变量，在这种情况下，什么时候销毁对象 O 就成了一个难题了。

对于以上情况有两种做法：

（1）对象 A 在调用完对象 B 的某个方法之后，马上销毁参数对象 O，然后对象 B 需要将对象 O 复制一份，生成另一个对象 O2，同时自己来管理对象 O2 的生命周期。但是这种做法有一个很大的问题，就是他带来更多的内存申请、复制、释放的工作。本来可以复用的对象，因为不方便管理他的生命周期，就简单地把他销毁，又重新构造一份一样的，实在太影响性能。

（2）对象 A 只负责生成对象 O，之后就由对象 B 负责完成对象 O 的销毁工作。如果对象 B 只是临时用一下对象 O，就可以用完后马上销毁，如果对象 B 需要长时间使用对象 O，就不销毁他。这种做法看似解决了对象复制的问题，但是他强烈依赖于 A 和 B 两个对象的配合，代码维护者需要明确地记住这种编程约定。而且，由于对象 O 的生成和释放在不同对象中，使得他的内存管理代码分散在不同对象中，管理起来也很费劲。如果这个时候情况更加复杂一些，例如对象 B 需要再向对象 C 传递参数对象 O，那么这个对象在对象 C 中又不能让对象 C 管理。所以这种方法带来的复杂度更高，更加不可取。

引用计数的出现很好地解决这个问题，在参数对象 O 的传递过程中，哪些对象需要长时间使用他，就把他的引用计数加1，使用完就减1。所有对象遵守这个规则，对象的生命周期管理就可以完全交给引用计数了。我们也可以很方便地享受到共享对象带来的好处。

 

2.1 什么是循环引用「Reference Cycles」问题，怎么解决呢？

引用计数这种内存管理方式虽然简单，但有一个瑕疵就是他不能自动解决循环引用的问题。

举个例子：

对象 A 和对象 B 相互引用对方作为自己的成员变量，只有当自己销毁时，才将自己的成员变量的引用计数减1，因为对象 A 和对象 B 的销毁相互依赖，这样就造成我们所说的循环引用问题了。

循环引用会导致即使外界已经没有任何指针能够访问他们了，但是他们所占资源仍然无法释放的情况。

解决循环引用问题主要有两种方法：

（1）明确知道哪里存在循环引用，合理时机主动断开环中的一个引用，使得对象得以回收。这种方法不常用，因为他依赖开发人员自己手工显式控制，相当于回到以前「谁申请谁释放」的内存管理年代。

（2）使用弱引用「Weak Reference」，「weak」「__weak」类型，这种方法常用。弱引用虽然持有对象，但是并不增加他的引用计数。弱引用的一个经典使用场景就是委托代理「delegate」协议模式。

 

2.2 Xcode 中有什么工具可以检测循环引用吗？

在 Xcode 中有「Instruments」工具集可以很方便地检测循环引用。

举个例子：

- (void)viewDidLoad {
    [super viewDidLoad];
    
    NSMutableArray *mArrFirst = [NSMutableArray array];
    NSMutableArray *mArrSecond = [NSMutableArray array];
    [mArrFirst addObject:mArrSecond];
    [mArrSecond addObject:mArrFirst];
}

可以选择「Product」下的「Profile」来打开「Instruments」工具集。

然后选择「Leaks」，再单击右下角的「Choose」按钮进入检测界面，这时点击左上角的「Record」红色圆点按钮开始检测。

 

 

 

 

3. Core Foundation 对象的内存管理

ARC 是编译器特性，他不是运行时特性，更不是垃圾回收器「GC」。

ARC 能够解决 iOS 开发中90%的内存管理问题，但是另外10%的内存管理问题是需要开发人员自己处理的，这主要是与底层 Core Foundation 对象交互的部分，底层 Core Foundation 对象由于不在 ARC 的管理下，所以需要自己维护这些对象的引用计数。

实际上 Core Foundation 对象使用的 CFRetain 和 CFRelease 方法，可以认为与 Objective-C 对象的 retain 和 release 方法等价，所以我们可以以 MRC 的方式进行类似管理。

 

3.1 在 ARC 中，通过什么方式可以把 Core Foundation 对象转换为 Objective-C 对象呢？

转换的过程，其实是告诉编译器，对象的引用计数如何调整。

这里我们可以使用桥接「bridge」相关关键字来进行转换工作，以下是这些（双下划线）关键字的说明：

（1）__bridge：只做类型转换，不修改相关对象的引用计数，原来的 Core Foundation 对象在不用时，需要调用 CFRelease 方法。

（2）__bridge_retained：类型转换后，将相关对象的引用计数加1，原来的 Core Foundation 对象在不用时，需要调用 CFRelease 方法。

（3）__bridge_transfer：类型转换后，将相关对象的引用计数交给 ARC 管理，原来的 Core Foundation 对象在不用时，不需要调用 CFRelease 方法。

我们根据具体的业务逻辑，合理使用上面的三种转换关键字，就可以解决 Core Foundation 对象与 Objective-C 对象相对转换的问题了。