说到OC的内存管理, 就不得不说一说OC的内存管理机制, OC是通过引用计数, 来决定对象是否释放, 引用计数为0, 对象对应的内存便被释放, 否则, 该片内存就不会被释放。
本文主要大概解释一下内存管理的底层运行机制, 对具体源码实现不做分析, 主要通过定性结论以及一些自己的小demo起到一个科普的作用, 如想深入研究, 网上解析源码的博客不胜枚举, 希望本文能在您深入研究前对您有些许帮助。
MRC时代, 程序员需要自己管理对象的引用计数, 通过retain, release来控制对象的引用计数, 代码冗余不说, 释放非自己持有的对象还会造成crash。笔者并未经历过MRC时代, 没有深刻的体会, 再此不过多赘述, 下面我们聊一聊ARC下的内存管理。
随着ARC的出现, 随之也出现了__strong, __weak指针, 那么它们又各有什么样的作用呢?
作为一名iOS开发者, 不可能对这个问题不知道, 简单来说, strong指针就是对一个对象持有, 使之引用计数+1, 而weak指针仅仅指向该对象, 并不持有该对象, 当该对象被释放时, weak指针自动置为nil。可以看出, weak指针很安全, 至少不会非法访问而造成crash。
那么, 新的问题来了, strong 和 weak关键字的优化各是发生在什么时期呢?
- strong指针: 是在编译阶段进行处理, 实际就是编译器给加上 retain release
- weak指针: 是在运行期处理, weak指针赋值的时候, 不会对该对象进行retain, 在该对象引用计数为0时, 置为 nil, 事实上是在该对象引用计数即将变为0之前将该指针置为nil(此步骤便是运行期进行处理的)
- weak实现原理: 运行时底层会维护一个离散表, 我们可以理解为类似hashMap或NSDictionary结构的东西, 存放所有weak对象的相关信息, {对象地址 : weak指针的指针(二级指针)}, 当对象即将dealloc时, 来检查这个表, 从而改变weak指针的指向, 置为nil
这里我们可以联想到当我们要传一个NSError *error时, 传的是&error, 也是一个二级指针, 只有这样, 才能修改error指针的指向, 如果传的是一级指针, 只能修改指针指向的那块内存的内容。
结论既然已经抛出, 我们用几个小demo来验证一下并加深印象, 首先先说一下大体结构: 有 FirstViewController 和 SecondViewController 两个控制器 SecondViewController 是通过 FirstViewController modal出来的
FirstViewController 中代码
extern id strongVc;
extern __weak id weakVc;
id strongVc = nil;
__weak id weakVc = nil;
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
NSLog(@"%s, ------------%@", __func__, strongVc);
// 当从SecondViewController dismiss回来后, 点击屏幕 BAD_ACCESS 非法访问,
// 说明调用 dealloc, 不管有没有强引用, 对象对应的那块内存都会被释放
}
SecondViewController 中代码
- (void)viewDidLoad {
[super viewDidLoad];
weakVc = self; // 给weakVc赋值
}
- (void)dealloc {
NSLog(@"weakVc = %@", weakVc);
// weakVc = (null), 证明了 调用dealloc完成前, weak指针已经被置为nil
NSLog(@"self = %@", self);
// self = **
strongVc = self;
// 此时使一个强指针指向 self
}
以上注释, 就是操作结果。
此外, 我们知道ARC 不允许主动掉dealloc方法, 那么如果我们强行调用dealloc方法会怎样呢?
在SecondViewController添加以下代码
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
[self performSelector:NSSelectorFromString(@"dealloc")];
NSLog(@"%s, ------------%@", __func__, weakVc); // nil
NSLog(@"%s, ------------%@", __func__, self); // BAD_ACCESS -> crash
}
强行调用dealloc, 当访问到self时, BAD_ACCESS 导致奔溃, 进一步证明, 只要调用dealloc方法, 会把该对象对应的那部分内存释放。
以上, 是我一些小小的分享, 希望能让大家大体上有个概念, 如果有兴趣进一步了解, 可以研究研究《Objective-C高级编程》, 里面很细致的讲解了与内存管理的相关实现,可以有助于我们更好地了解OC的内存管理机制。