iOS开发系列之内存泄漏分析（下）

20190702更新，新增 webView 的内存泄漏分析，欢迎大家评论补充。

接上篇，本篇主要讲解通知和 KVO 不移除观察者、block 循环引用 、NSThread 和 RunLoop一起使用造成的内存泄漏。

1、通知造成的内存泄漏

1.1、iOS9 以后，一般的通知，都不再需要手动移除观察者，系统会自动在dealloc 的时候调用 [[NSNotificationCenter defaultCenter]removeObserver:self]。ios9以前的需要手动进行移除。

原因是：iOS9 以前观察者注册时，通知中心并不会对观察者对象做 retain 操作，而是进行了 unsafe_unretained 引用，所以在观察者被回收的时候，如果不对通知进行手动移除，那么指针指向被回收的内存区域就会成为野指针，这时再发送通知，便会造成程序崩溃。

从 iOS9 开始通知中心会对观察者进行 weak 弱引用，这时即使不对通知进行手动移除，指针也会在观察者被回收后自动置空，这时再发送通知，向空指针发送消息是不会有问题的。

1.2、使用 block 方式进行监听的通知，还是需要进行处理，因为使用这个 API 会导致观察者被系统 retain。

请看下面这段代码：

[[NSNotificationCenter defaultCenter] addObserverForName:@"notiMemoryLeak" object:nil queue:[NSOperationQueue mainQueue] usingBlock:^(NSNotification * _Nonnull note) {
        NSLog(@"11111");
    }];
//发个通知
[[NSNotificationCenter defaultCenter] postNotificationName:@"notiMemoryLeak" object:nil];

第一次进来打印一次，第二次进来打印两次，第三次打印三次。大家可以在 demo 中进行尝试，demo 地址见文章底部。

解决方法是记录下通知的接收者，并且在 dealloc 里面移除这个接收者就好了：

@property(nonatomic, strong) id observer;

self.observer = [[NSNotificationCenter defaultCenter] addObserverForName:@"notiMemoryLeak" object:nil queue:[NSOperationQueue mainQueue] usingBlock:^(NSNotification * _Nonnull note) {
       NSLog(@"11111");
}];
//发个通知
[[NSNotificationCenter defaultCenter] postNotificationName:@"notiMemoryLeak" object:nil];

- (void)dealloc {
    [[NSNotificationCenter defaultCenter] removeObserver:self.observer name:@"notiMemoryLeak" object:nil];
    NSLog(@"hi,我 dealloc 了啊");
}

2、KVO 造成的内存泄漏

2.1、现在一般的使用 KVO，就算不移除观察者，也不会有问题了

请看下面这段代码：

- (void)kvoMemoryLeak {
    MFMemoryLeakView *view = [[MFMemoryLeakView alloc] initWithFrame:self.view.bounds];
    [self.view addSubview:view];
    [view addObserver:self forKeyPath:@"frame" options:NSKeyValueObservingOptionNew context:nil];
    //调用这两句主动激发kvo  具体的原理会有后期的kvo详解中解释
    [view willChangeValueForKey:@"frame"];
    [view didChangeValueForKey:@"frame"];
}

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context {
    if ([keyPath isEqualToString:@"frame"]) {
        NSLog(@"view = %@",object);
    }
}

这种情况不移除也不会有问题，我猜测是因为 view 在控制器销毁的时候也销毁了，所以 view 的 frame 不会再发生改变，不移除观察者也没问题，所以我做了一个猜想，要是观察的是一个不会销毁的对象会怎么样？当观察者已经销毁，被观察的对象还在发生改变，会有问题吗？

2.2、观察一个不会销毁的对象，不移除观察者，会发生不确定的崩溃。

接上面的猜测，首先创建一个单例对象 MFMemoryLeakObject，有一个属性title：

@interface MFMemoryLeakObject : NSObject
@property (nonatomic, copy) NSString *title;
+ (MFMemoryLeakObject *)sharedInstance;
@end

#import "MFMemoryLeakObject.h"
@implementation MFMemoryLeakObject
+ (MFMemoryLeakObject *)sharedInstance {
    static MFMemoryLeakObject *sharedInstance = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        sharedInstance = [[self alloc] init];
        sharedInstance.title = @"1";
    });
    return sharedInstance;
}
@end

然后在 MFMemoryLeakView 对 MFMemoryLeakObject 的 title 属性进行监听：

#import "MFMemoryLeakView.h"
#import "MFMemoryLeakObject.h"

@implementation MFMemoryLeakView
- (instancetype)initWithFrame:(CGRect)frame {
    if (self = [super initWithFrame:frame]) {
        self.backgroundColor = [UIColor whiteColor];
        [self viewKvoMemoryLeak];
    }
    return self;
}

#pragma mark - 6.KVO造成的内存泄漏
- (void)viewKvoMemoryLeak {
    [[MFMemoryLeakObject sharedInstance] addObserver:self forKeyPath:@"title" options:NSKeyValueObservingOptionNew context:nil];
}

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context {
    if ([keyPath isEqualToString:@"title"]) {
        NSLog(@"[MFMemoryLeakObject sharedInstance].title = %@",[MFMemoryLeakObject sharedInstance].title);
    }
}

最后在控制器中改变 title 的值，view 销毁前改变一次，销毁后改变一次：

//6.1、在MFMemoryLeakView监听一个单例对象
MFMemoryLeakView *view = [[MFMemoryLeakView alloc] initWithFrame:self.view.bounds];
[self.view addSubview:view];
[MFMemoryLeakObject sharedInstance].title = @"2";

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1.0 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
      [view removeFromSuperview];
      [MFMemoryLeakObject sharedInstance].title = @"3";
});

经过尝试，第一次没有问题，第二次就发生崩溃，报错野指针，具体的大家可以用 demo 做测试，demo 地址见底部。

解决方法也很简单，在view 的 dealloc 方法里移除观察者就好：

- (void)dealloc {
    [[MFMemoryLeakObject sharedInstance] removeObserver:self forKeyPath:@"title"];
    NSLog(@"hi,我MFMemoryLeakView dealloc 了啊");
}

总的来说，写代码还是规范一点，有观察就要有移除，不然项目里容易产生各种欲仙欲死的 bug。KVO 还有一个重复移除导致崩溃的问题，请参考这篇文章。

3、block 造成的内存泄漏

block 造成的内存泄漏一般都是循环引用，即 block 的拥有者在 block 作用域内部又引用了自己，因此导致了 block 的拥有者永远无法释放内存。

本文只讲解 block 造成内存泄漏的场景分析和解决方法，其他 block 的原理会在之后 block 的单章里进行讲解。

3.1、block 作为属性，在内部调用了 self 或者成员变量造成循环引用。

请看下面这段代码，先定义一个 block 属性：

typedef void (^BlockType)(void);

@interface MFMemoryLeakViewController ()
@property (nonatomic, copy) BlockType block;
@property (nonatomic, assign) NSInteger timerCount;
@end

然后进行调用:

#pragma mark - 7.block 造成的内存泄漏
- (void)blockMemoryLeak {
    // 7.1 正常block循环引用
    self.block = ^(){
        NSLog(@"MFMemoryLeakViewController = %@",self);
        NSLog(@"MFMemoryLeakViewController = %zd",_timerCount);
    };
    self.block();
}

这就造成了 block 和控制器的循环引用，解决方法也很简单， MRC 下使用 __block、ARC 下使用 __weak 切断闭环，成员变量使用 -> 的方式访问就可以解决了。

需要注意的是，仅用 __weak 所修饰的对象，如果被释放，那么这个对象在 block 执行的过程中就会变成 nil，这就可能会带来一些问题，比如数组和字典的插入。

所以建议在 block 内部对__weak所修饰的对象再进行一次强引用，这样在 Block 执行的过程中，这个对象就不会被置为nil，而在Block执行完毕后，ARC 下这个对象也会被自动释放，不会造成循环引用：

__weak typeof(self) weakSelf = self;
self.block = ^(){
      //建议加一下强引用，避免weakSelf被释放掉
      __strong typeof(weakSelf) strongSelf = weakSelf;
      NSLog(@"MFMemoryLeakViewController = %@",strongSelf);
      NSLog(@"MFMemoryLeakViewController = %zd",strongSelf->_timerCount);
};
self.block();
3.2、NSTimer 使用 block 创建的时候，要注意循环引用

请看这段代码：

[NSTimer scheduledTimerWithTimeInterval:1.0 repeats:YES block:^(NSTimer * _Nonnull timer) {
     NSLog(@"MFMemoryLeakViewController = %@",self);
}];

从 block 的角度来看，这里是没有循环引用的，其实在这个类方法的内部，有一个 timer 对 self 的强引用，所以也要使用 __weak 切断闭环，另外，这种方式创建的 timer，repeats 为 YES 的时候，也需要进行invalidate 处理，不然定时器还是停不下来。

@property(nonatomic,strong) NSTimer *timer;

__weak typeof(self) weakSelf = self;
_timer = [NSTimer scheduledTimerWithTimeInterval:1.0 repeats:YES block:^(NSTimer * _Nonnull timer) {
     NSLog(@"MFMemoryLeakViewController = %@",weakSelf);
}];

- (void)dealloc {
    [_timer invalidate];
    NSLog(@"hi,我MFMemoryLeakViewController dealloc 了啊");
}

4、NSThread 造成的内存泄漏

NSThread 和 RunLoop 结合使用的时候，要注意循环引用问题，请看下面代码：

- (void)threadMemoryLeak {
    NSThread *thread = [[NSThread alloc] initWithTarget:self selector:@selector(threadRun) object:nil];
    [thread start];
}

- (void)threadRun {
    [[NSRunLoop currentRunLoop] addPort:[[NSPort alloc] init] forMode:NSDefaultRunLoopMode];
    [[NSRunLoop currentRunLoop] run];
}

导致问题的就是 “[[NSRunLoop currentRunLoop] run];” 这一行代码。原因是 NSRunLoop 的 run 方法是无法停止的，它专门用于开启一个永不销毁的线程，而线程创建的时候也对当前当前控制器（self）进行了强引用，所以造成了循环引用。

解决方法是创建的时候使用block方式创建：

- (void)threadMemoryLeak {
    NSThread *thread = [[NSThread alloc] initWithBlock:^{
        [[NSRunLoop currentRunLoop] addPort:[[NSPort alloc] init] forMode:NSDefaultRunLoopMode];
        [[NSRunLoop currentRunLoop] run];
    }];
    [thread start];
}

这样控制器是可以得到释放了，但其实这个线程还是没有销毁，就算调用 “CFRunLoopStop(CFRunLoopGetCurrent());” 也无法停止这个线程，因为这个只能停止这一次的 RunLoop，下次循环依然可以继续进行下去。具体的解决方法我会在 RunLoop 的单章里进行讲解。

5、webView 造成的内存泄漏

目前 iOS 的 webView 有UIWebView 和 WKWebView 两种。

5.1、UIWebView

UIWebView 内存问题应该是众所周知了吧，Apple官方也承认了内存泄露确实存在，所以在 iOS8 推出了功能和性能都更加强大WKWebView。

大家可以看看下面这段代码：

UIWebView *webView = [[UIWebView alloc] initWithFrame:self.view.bounds];
webView.backgroundColor = [UIColor whiteColor];
NSURLRequest *requset = [NSURLRequest requestWithURL:[NSURL URLWithString:@"https://www.baidu.com"]];
[webView loadRequest:requset];
[self.view addSubview:webView];

就这么一段简单的代码，打开网页的时候，内存暴涨 200M，就算返回到上级页面，webView 销毁，内存也依然比原来高了 50M 左右，就算在控制器的 dealloc 里加载一个空的 url 也没有作用，这个大家可以用demo进行尝试。

5.2、WKWebView

总的来说，WKWebView 不管是性能还是功能，都要比 UIWebView 强大很多，本身也不存在内存泄漏问题，但是，如果开发者使用不当，还是会造成内存泄漏。请看下面这段代码：

WKWebViewConfiguration *config = [[WKWebViewConfiguration alloc] init];
config.userContentController = [[WKUserContentController alloc] init];
[config.userContentController addScriptMessageHandler:self name:@"WKWebViewHandler"];
WKWebView *wkWebView = [[WKWebView alloc] initWithFrame:self.view.bounds configuration:config];
wkWebView.backgroundColor = [UIColor whiteColor];
[self.view addSubview:wkWebView];
NSURLRequest *requset = [NSURLRequest requestWithURL:[NSURL URLWithString:@"https://www.baidu.com"]];
[wkWebView loadRequest:requset];

这样看起来没有问题，但是其实 “addScriptMessageHandler” 这个操作，导致了 wkWebView 对 self 进行了强引用，然后 “addSubview”这个操作，也让 self 对 wkWebView 进行了强引用，这就造成了循环引用。

解决方法就是在合适的机会里对 “MessageHandler” 进行移除操作，比如：

@property (nonatomic, strong) WKWebView *wkWebView;

- (void)webviewMemoryLeak {
    // 9.2 WKWebView
    WKWebViewConfiguration *config = [[WKWebViewConfiguration alloc] init];
    config.userContentController = [[WKUserContentController alloc] init];
    [config.userContentController addScriptMessageHandler:self name:@"WKWebViewHandler"];
    _wkWebView = [[WKWebView alloc] initWithFrame:self.view.bounds configuration:config];
    _wkWebView.backgroundColor = [UIColor whiteColor];
    [self.view addSubview:_wkWebView];
    NSURLRequest *requset = [NSURLRequest requestWithURL:[NSURL URLWithString:@"https://www.baidu.com"]];
    [_wkWebView loadRequest:requset];
}

- (void)viewDidDisappear:(BOOL)animated {
    [super viewDidDisappear:animated];
    [_wkWebView.configuration.userContentController removeScriptMessageHandlerForName:@"WKWebViewHandler"];
}

在 demo 里我选择了在 “ viewDidDisappear”方法里进行移除操作，这样控制器就可以得到释放了。

本次的内存泄漏分析，就写到这里，因为本人水平所限，很多地方还是没能讲得足够深入，欢迎诸位进行指正。

demo地址

欢迎大家来我的小窝做客啊，里面记录下了我进步的点点滴滴，一切逆境只是前进的理由，与君共勉。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 212,332评论 6赞 493
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 90,508评论 3赞 385
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 157,812评论 0赞 348
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 56,607评论 1赞 284
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 65,728评论 6赞 386
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 49,919评论 1赞 290
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 39,071评论 3赞 410
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 37,802评论 0赞 268
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 44,256评论 1赞 303
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,576评论 2赞 327
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,712评论 1赞 341
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 34,389评论 4赞 332
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 40,032评论 3赞 316
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,798评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,026评论 1赞 266
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 46,473评论 2赞 360
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 43,606评论 2赞 350