iOS 深入浅出学习内存管理

随着iOS进入ARC管理时代,开发者几乎不需要关注内存的管理问题。但是ARC并不是万能的,只能说它可以解决大部分情况下的内存管理问题,在有些框架中和某些使用到C语言的场景中,还是需要我们自己手动进行内存管理的。

1、iOS的内存管理模型

1.1、关于内存消耗和引用计数

在iOS程序中,内存通常被分为如下5个区域:

栈区:存储局部变量,在作用域结束后内存会被回收,由系统进行内存管理。
堆区:存储OC对象,需要开发者手动申请和释放。
BSS区:用来存储未初始化的全局变量和静态变量。
数据区:用来存储已经初始化的全局变量、静态变量和常量。
代码段:加载代码。

上面的5个区中,除了堆区需要开发者手动进行内存管理外,其他的都由系统自动进行回收。

引用计数是OC提供的内存管理技术,其实每个OC对象都有一个retainCount属性,简单理解,这个属性就是一个计数器。

一个OC对象是否应该被释放,取决于其他地方对他的引用情况,每有一个地方对他引用,他自身的引用计数就加1,当有一个地方不再引用他时,他的引用计数就减1,最终根据其引用计数是否为0来确定这块内存是否被回收。

1.2、MRC内存管理

Xcode默认开启了ARC功能,我们可以在功能配置中将其关闭:


image.png
MRC内存管理有如下两个原则:

1、谁持有对象,谁负责释放,不是自己持有的不能释放。
2、当对象不再被需要时,需要主动释放

“谁持有对象,谁负责释放”,是指自己创建的对象要自己负责对其进行释放,不是自己创建的对象,如果对其进行了强引用,那么自己也要负责对其进行释放。

在OC中会对对象持有的方法如下:

函数名 --- 意义
alloc --- 进行内存分配
new --- 创建并初始化对象
copy --- 复制对象
mutablecopy --- 可变复制对象
retain --- 进行持有

需要注意的是上面5个方法,前4个都是创建新的对象,让其引用计数为1,retain方法的作用是对当前对象进行持有,使引用计数加1。release函数的作用是让引用计数减一。

1.3、关于ARC

ARC并非修改了我们MRC中的内存管理原则,也并没有在运行时增加什么特性,ARC只做了一件事,就是在编译时帮组开发者将retain和release这样的方法补上。
那么ARC具体做了什么工作呢?首先在MRC中,如果要对一个并非自己创建的对象进行引用,需要我们手动retain函数进行持有,例如:

- (void)mrcTest {
    
    NSArray *array = [[NSArray arrayWithObject:@""] retain];
}

在ARC中,编译器会自动帮我们retain的添加,开发者唯一要做的是使用指针指向这个对象,当指针被置空或被指向新值时,原来的对象会被release一次。同样,对于自己生成的对象,当其离开作用域时,编译器也会为其添加release操作。

ARC中的所有权修饰符:
__weak
__strong
__unsafe_unretained
__autoreleasing

实际上我们使用的指针默认都是使用__strong修饰的,在ARC环境中,下面两行代码意义完全一致:

    __strong NSArray *array1 = [NSArray array];
    NSArray *array2 = [NSArray array];

__strong修饰符通常用来对变量进行强引用,主要有下面三个作用:

1、使用 __strong修饰的变量如果是自己生成的,则会被添加进自动释放池,在作用域结束后,会被release一次。
2、使用 __strong修饰的变量如果不是自己生成的,则会被强引用,即会被持有,使其引用计数加1,在离开作用域后,会被release一次。
3、使用 __strong修饰的变量指针如果重新赋值或被置为nil,则变量会被release一次。

__weak修饰符通常用来对变量进行弱引用,其最大的用途是避免ARC环境下的循环引用问题。循环引用是ARC中造成内存泄露的主要问题。__weak修饰符主要有如下两个作用:

1、被__weak修饰的变量仅提供弱引用,不会使引用计数增加。变量对象如果是自己生成的,则会被添加到自动释放池,会在离开作用域时被release一次,如果不是自己生成的,则在离开作用域后,不会进行release操作。
2、被__weak修饰的变量指针,变量如果失效,则指针会被自动置为nil。

关于__weak的第二点,我们使用代码进行验证

- (void)arcTest {
    id __weak obj1 = nil;
    {
        id __strong obj0 = [[NSObject alloc]init];
        obj1 = obj0;
        NSLog(@"a = %@",obj1);
    }
    NSLog(@"b = %@",obj1);
}

打印结果:
2020-06-17 13:50:08.121698+0800 ARCDemo[2748:630350] a = <NSObject: 0x2826d0b60>
2020-06-17 13:50:08.122211+0800 ARCDemo[2748:630350] b = (null)

在{ }的作用域内,由于obj1是__weak修饰的,所以在作用域内,只是对obj0进行了弱引用,当作用域结束的时候,obj0会release,retainCount变为0,obj0被回收释放。这时候obj1会被置为nil。

__unsafe_unretained这个修饰符比较特殊,字面意思可以看出这个修饰符是不安全的,和上面的__weak修饰符相比,这个修饰符的作用也是对变量进行弱引用,不同的是,当变量失效的时候,其指针不会被自动置为nil。其作用如下:

1、被__unsafe_unretained修饰的变量仅提供弱引用,不会使其引用计数增加。变量对象如果是自己生成的,则会在离开作用域时被release一次,如果不是自己生成的,则在离开作用域后,不会进行release操作。
2、当变量失效后,被修饰指针不会被安全处理为nil,旧地址依然保存,变为野指针。

__autoreleasing与自动释放池有关,后续在自动释放池的时候再说明。

在使用ARC时的几条重要原则:
1、不能使用retain、release、autorelease函数,不可访问retainCount属性。
2、不能调用dealloc函数,可以覆写dealloc函数,但是在实现中不可以调用父类的dealloc函数。
3、不能使用NSAutoreleasePool,可以使用@autoreleasepool代理。
4、对象型变量不能作为C语言的结构体。

1.4、属性修饰符

内存管理相关属性修饰符:

名称 -- 作用
assign -- 直接赋值,和引用计数无关,用来声明简单数据类型的属性,如:int。
retain -- 对旧对象进行释放,并强引用新的对象,使其引用计数加1,用着MRC中。
strong -- 对新对象进行强引用,释放旧对象,使其引用计数加1,用着ARC中。
copy -- 在实现setter方法时,采用copy函数,会生成新的对象被自己持有。
weak -- 弱引用,不对所赋值的对象进行持有,是安全的,当对象不可用时,会被置为nil,用着ARC中。
unsafe_unretained -- 弱引用,和weak不同的地方是,如果引用对象不可用,则当前指针不会被置为nil,会产生野指针。

2、自动释放内存

从上节中我们知道,当使用copy、alloc、new、mutableCopy、retain函数时会对对象进行持有。其实还有很多方法返回对象,例如[NSArray array],类型这类函数返回的对象不符合上面的原则,自然我们不能对其进行释放操作,可是这些对象的内存管理是谁负责的呢?他们又是谁持有的呢?这就涉及到自动释放池了。

2.1、关于autorelease方法

release函数的作用是对当前对象进行一次释放操作,这里的释放只是相对于持有的一个概念,并不是对对象所使用的内存进行释放,内存的释放是当引用计数为0时才进行,release只是会使对象的引用计数减1。autorelease,顾名思义,为自动释放,其本质上是使release函数的调用被延迟了。我们简单的把使用了autorelease方法的对象称为自动释放对象,自动释放对象的内存管理是交给自动释放池的。

2.2、自动释放池

当我们用xcode创建一个新工程的时候,在main.m文件中,你都能看到如下代码:

int main(int argc, char * argv[]) {
    NSString * appDelegateClassName;
    @autoreleasepool {
        // Setup code that might create autoreleased objects goes here.
        appDelegateClassName = NSStringFromClass([AppDelegate class]);
    }
    return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}

@autoreleasepool {}就是我们说的自动释放池,当自动释放池操作结束后,其会向被添加进自动释放池的所有对象发送release消息。在MRC中要将对象添加进自动释放池,即调用autorelease方法,

系统维护的自动释放池

iOS系统在运行应用程序时,会自动创建一些线程,每个线程都默认拥有自己动释放池,在每次执行时间循环时,都会将其自动释放池清空。因此在大多数情况下,开发者都不必手动创建自动释放池,但是有一种情况除外。
系统的自动释放池会在每次事件循环结束后清空,但是若果在大量的循环中生成自动释放对象,则有可能导致内存消耗瞬间增长。例子如下:

- (void)viewDidLoad {
    [super viewDidLoad];
    for (int i = 0; i < 100000; i ++) {
        UIView *view = [[UIView alloc]init];
    }
}

运行工程中,使用内存检测工具,会发现内存急剧增加,当所有循环结束后,内存又急速下降。那么我们将代码修改后,内存的增长会平稳很多,这是我们常使用自动释放池进行的内存优化方法。

- (void)viewDidLoad {
    [super viewDidLoad];
    for (int i = 0; i < 100000; i ++) {
        @autoreleasepool {
            UIView *view = [self creatView];
        }
    }
}

- (UIView *)creatView {
    return [[UIView alloc]init];
}

3、杜绝内存泄露

在iOS开发中,内存泄露是让开发者头疼的一件事。ARC虽然可以帮助开发者解决大部分的内存管理问题,但其对内存泄露依然束手无策。

内存泄露的核心问题就是循环引用。在OC中,对象会对其内的属性进行持有,当一个对象的引用计数为0,将其内存回收时,这个对象会向其中所有的属性发送release消息,让其中的属性对象进行释放。
但是如果对象内的某个属性再次对当前对象进行了持有,则会产生循环引用。因为对象只有在引用计数降为0时,才会向其内的属性发送release消息,同样,只有其内属性接收到了release消息时,才会对他们所持有的所有对象进行释放,当前对象的引用计数才可能降为0,此时就产生了循环引用。

循环引用常出现的场景

A、Block与循环引用

#import "ViewController.h"

typedef BOOL (^MyBlock)(NSInteger param);
@interface ViewController ()
@property (nonatomic, strong)MyBlock myBlock;
@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    int a = 0;
    NSMutableString *string = [[NSMutableString alloc]initWithString:@"hello"];
    self.myBlock = ^BOOL(NSInteger param) {
        [string appendString:@" world"];
        a++;
        return NO;
    };
}

首先我们需要了解block相关知识。

在Block中,任何外部数据都不能被修改,上面的代码中可变字符串之所以能修改,是因为对象指针所指向的内存存放的只是对象数据的地址,并不是对象数据本身,只要地址不修改,只修改对象数据是没问题的。

如果我们修改下代码,发下编译器会直接报错,因为我们重新alloc了string,导致对象指针指向的内存地址发生了改变,代码如下:

image.png

在Block内部无法修改外部的原因是在Block中访问外部变量时,都会对其进行一份拷贝,需要注意的是这里的拷贝是直接拷贝,如果你在Block内部和外部对变量对象进行打印,可以看到其地址是不一样的.当然OC给我们提供了__block关键字,使用它可以直接访问原始变量。

我们再看下面的代码:

    self.myBlock = ^BOOL(NSInteger param) {
        NSLog(@"%@",self);
        return NO;
    };

在Block中使用外部的对象时,都会对对象进行一次强引用。而myBlock是当前类中的属性,所以当前类对象对myBlock有强引用,只有当当前类对象引用计数为0时,才会对其属性对象myBlock发送release消息;同样,由于在myBlock内部使用到了self关键字,使得myBlock对当前类对象又进行了强引用,当前类对象要想释放,必须等myBlock对象的引用计数降为0,这就造成了循环引用,产生了内存泄露。
那如何解决呢,我们只需要在Block中使用弱引用的指针即可,示例如下:

    __weak typeof(self) weakSelf = self;
    self.myBlock = ^BOOL(NSInteger param) {
        NSLog(@"%@",weakSelf);
        return NO;
    };
Block类型

这里在额外的对Block类型进行下补充

A.GlobalBlock
.位于全局区
.在Block内部不使用外部变量,或者只使用静态变量和全局变量

B.MallocBlock
.位于堆区
.在Block内部使用局部变量或OC属性,并且赋值给强引用或者Copy修饰的变量

C.StackBlock
.位于栈区
.和MallocBlock一样,可以在Block内部使用局部变量或OC属性。但是不能赋值给强引用或者Copy修饰的变量

B、代理与循环引用

代理产生循环引用的逻辑,我们就不详细介绍了,基本思想就是视图控制器对有代理的view保持了强引用,在设置代理时,代理属性delegate采用了strong修饰符修饰,这样就导致了ViewController对象又被view对象强引用了,从而产生了内存泄露。最便捷修复方式就是在声明delegate属性时使用weak修饰符修饰。

C、定时器引起的内存泄露

定时器NSTimer,作为开发者的我们应该是经常用到:

#import "ViewController.h"
@interface ViewController ()
@property (nonatomic, strong)NSTimer *timer;
@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    self.timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(timerRun) userInfo:nil repeats:YES];
}

- (void)timerRun {
    NSLog(@"runing...");
}

但是当我们pop或dismiss该页面的时候,发现控制器并未走dealloc方法,也就是说其并没有被释放。此处造成循环引用的原因是定时器对象实际上持有了当前视图控制器对象,只有当定时器失效后,其才会释放所持有的当前视图控制器。
因此,在视图控制器返回前,我们要手动调用invalidate方法来使定时器失效。
那么我们在什么时候去调用invalidate方法呢,其实我们只要在页面即将要销毁的时候去调用该方法,就可以销毁定时器了,这时我们发现控制器走了dealloc方法:

- (void)viewWillDisappear:(BOOL)animated {
    [super viewWillDisappear:animated];
    if ([self isBeingDismissed] || [self isMovingFromParentViewController]) {
        //页面正在dismissed或pop的时候,我们销毁定时器
        [self invalidateTimer];
    }
}

- (void)invalidateTimer {
    [self.timer invalidate];
    self.timer = nil;
}

- (void)dealloc {
    NSLog(@"dealloc");
}

4、关于 僵尸 对象

僵尸对象和内存泄露并无关系,但是和内存泄露一样,产生僵尸对象也是极严重的内存管理问题。前面我们提到过,当一个对象被释放后,如果其指针没被置空,那么这个指针就成了野指针,此时这个指针指向的对象就是“僵尸对象”。

    NSObject * obj = [[NSObject alloc]init];
    [obj release];
    NSLog(@"%@",obj);

在MRC下,一个常见的僵尸对象问题是过早的调用了release方法,如上图。由于我们提前调用了release方法,导致对象被释放,字后访问会产生异常。但是需要注意的是,这个异常并不是每次都会产生,Xcode默认并不会对僵尸对象进行检查,当我们使用野指针试图访问一个僵尸对象时,如果此时内存数据有效,则会访问成功,如果无效,则会产生异常。
Xcode为我们提供了一个工具帮我们捕获僵尸对象,其默认是关闭的,我们可以将其打开:


image.png

再次运行工程,当访问到僵尸对象时,Xcode打印区会输出相关信息供参考:

-[NSObject isProxy]:message sent to deallocated instance 0x60a01123b2

那么我们如何避免在访问到将是对象而导致的崩溃呢?
我们知道,向空指针发送任何消息都是无效的,在ARC中,使用__weak 和__strong修饰的变量指针在对象被释放后会自动置为nil,这就大大减少了野指针问题。其实我们也可以借助OC的消息转发机制来规避所有的僵尸对象问题。

首先创建一个NSObject类的类别,用来进行系统dealloc函数的替换。
NSObject +NSZombie.h:

#import <Foundation/Foundation.h>

NS_ASSUME_NONNULL_BEGIN

@interface NSObject (NSZombie)

@end

NS_ASSUME_NONNULL_END

NSObject +NSZombie.m:

#import "NSObject+NSZombie.h"
#import <objc/runtime.h>
#import "Zombie.h"
@implementation NSObject (NSZombie)
+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        //替换方法
        SEL originalSel = NSSelectorFromString(@"dealloc");
        SEL swizzledSel = @selector(newDealloc);
        Method originalMethod = class_getInstanceMethod([self class], originalSel);
        Method swizzledMethod = class_getInstanceMethod([self class], swizzledSel);
        BOOL didAddMethod = class_addMethod([self class], originalSel, method_getImplementation(swizzledMethod), method_getTypeEncoding(swizzledMethod));
        if (didAddMethod) {
            class_replaceMethod([self class], swizzledSel, method_getImplementation(originalMethod), method_getTypeEncoding(originalMethod));
        } else {
            method_exchangeImplementations(originalMethod, swizzledMethod);
        }
    });
}

- (void)newDealloc {
    [self newDealloc];
    //重新设置类
    ///每当有对象调用dealloc方法时,就会对其内的isa指针进行重定向,将其类修改为我们自定义的Zombie类
    object_setClass(self, [Zombie class]);
}
@end

Zombie作为僵尸类如下:

#import <Foundation/Foundation.h>

NS_ASSUME_NONNULL_BEGIN

@interface Zombie : NSProxy

@end

NS_ASSUME_NONNULL_END


#import "Zombie.h"
#import <objc/runtime.h>
@implementation Zombie
- (NSMethodSignature *)methodSignatureForSelector:(SEL)sel {
    NSLog(@"僵尸对象: %p 调用了函数: %@",self,NSStringFromSelector(sel));
    return [[NSObject new] methodSignatureForSelector:sel];
}

- (void)forwardInvocation:(NSInvocation *)invocation {
    [invocation invokeWithTarget:[NSObject new]];
}
@end

当Zombie对象执行了未定义的方法时,会调用上面的methodSignatureForSelector:函数,这个函数用来进行选择器的签名,在这里我们可以获取到僵尸函数的内存地址、所调用的方法等数据。forwardInvocation:函数用来对消息进行处理,这样做的目的是防止产生Crash。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 219,270评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,489评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 165,630评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,906评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,928评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,718评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,442评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,345评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,802评论 1 317
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,984评论 3 337
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,117评论 1 351
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,810评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,462评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,011评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,139评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,377评论 3 373
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,060评论 2 355

推荐阅读更多精彩内容