浅析NSTimer & CADisplayLink内存泄露

简介:

偶得前言

本篇文章中我们主要谈谈NSTimer\CADisplayLink在使用过程中牵扯到内存泄露的相关问题及解决思路(文章末尾会附上Demo),有时候我们在不知情的情况容易入坑,最关键你还不知道自己掉坑了,闲话不多说,让我们开始进入正题。

NSRunLoop与定时器

我们先来回顾一下NSRunLoopNSTimer\CADisplayLink的影响。(为了方便,以下统称定时器)

大家都知道定时器的运行需要结合一个NSRunLoop(有疑惑的同学可以查看Xcode Document,此处不细说),同时NSRunLoop对该定时器会有一个强引用,这也是为什么我们不对NSRunLoop中的定时器进行强引的原因(如:self.timer = timer, 此代码可省略)。

- invalidate的作用

由于NSRunLoop对定时器有着牵引,那么问题就来了,那么定时器怎样才能被释放掉呢(先不考虑使用removeFromRunLoop:),此时- invalidate函数的作用就来了,我们来看看官方就此函数的介绍:

Removes the object from all runloop modes (releasing the receiver if it has been implicitly retained) and releases the 'target' object.

据官方介绍可知,- invalidate做了两件事,首先是把本身(定时器)从NSRunLoop中移除,然后就是释放对‘target’对象的强引用。从而解决定时器带来的内存泄露问题。

内存泄露在哪?

看到这里我们可能会有点懵逼,先上一个图(为了方便讲解,途中箭头指向谁就代表强引谁):

784359-20161105234418315-1263815328.jpg

此处我们必须明确,在开发中,如果创建定时器只是简单的计时,不做其他引用,那么timer对象与myClock对象循环引用的问题就可以避免(即省略self.timer = timer,前文已经提到过,不再阐述),即图中箭头5可避免。

虽然孤岛问题已经避免了,但还是存在问题,因为myClock对象被UIViewController以及timer引用(timer直接被NSRunLoop强引用着),当UIViewController控制器被UIWindow释放后,myClock不会被销毁,从而导致内存泄露。

讲到这里,有些人可能会说对timer对象发送一个invalidate消息,这样NSRunLoop即不会对timer进行强引,同时timer也会释放对myClock对象的强引,这样不就解决了吗?没错,内存泄露是解决了。

但是,这并不是我们想要的结果,在开发中我们可能会遇到某些需求,只有在myClock对象要被释放时才去释放timer(此处要注意释放的先后顺序及释放条件),如果提前向timer发送了invalidate消息,那么myClock对象可能会因为timer被提前释放而导致数据错了,就像闹钟失去了秒针一样,就无法正常工作了。所以我们要做的是在向myClock对象发送dealloc消息前在给timer发送invalidate消息,从而避免本末倒置的问题。这种情况就像一个死循环(因为如果不给timer发送invalidate消息,myClock对象根本不会被销毁,dealloc方法根本不会执行),那么该怎么做呢?

我们如何解决?

现在我们已经知道内存泄露在哪了,也知道原因是什么,那么如何解决,或者说怎样优雅的解决这问题呢?方式有很多.
a.NSTimer Target

784359-20161105234429346-736866318.jpg

为了解决timer与myClock之间类似死锁的问题,我们会将定时器中的‘target’对象替换成定时器自己,采用分类实现。

#import "NSTimer+TXTimerTarget.h"@implementation NSTimer (TXTimerTarget)+ (NSTimer *)tx_scheduledTimerWithTimeInterval:(NSTimeInterval)interval repeat:(BOOL)yesOrNo block:(void (^)(NSTimer *))block{    return [self scheduledTimerWithTimeInterval:interval target:self selector:@selector(startTimer:) userInfo:[block copy] repeats:yesOrNo];
}

+ (void)startTimer:(NSTimer *)timer {    void (^block)(NSTimer *timer) = timer.userInfo;    if (block) {
        block(timer);
    }
}@end

b.NSTimer Proxy

784359-20161105234450861-1317093208.jpg

这种方式就是创建一个NSProxy子类TXTimerProxy(不太清楚NSProxy的同学可以去查一下相关资料哈),TXTimerProxy的作用是什么呢?就是什么也不做,可以说只会重载消息转发机制,如果创建一个TXTimerProxy对象将其作为timer的‘target’,专门用于转发timer消息至myClock对象,那么问题是不是就解决了呢?答案:是的。

NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval:0.25 target:[TXTimerProxy timerProxyWithTarget:self] selector:@selector(startTimer) userInfo:nil repeats:YES];

[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];self.timer = timer;

实现详情文章末尾会附上Demo,感兴趣的同学可以去看看哈,有什么问题可以直接问,互相交流。

c.NSTimer Block

还有一种方式就是采用Block,iOS 10增加的API。

+ scheduledTimerWithTimeInterval:repeats:block:

The execution body of the timer; the timer itself is passed as the parameter to this block when executed to aid in avoiding cyclical references

有点类似a方式,此处不再详述。

//NSTimer Block(解决self内存泄露) 模拟器会崩溃//API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0));NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval:0.25 repeats:YES block:^(NSTimer * _Nonnull timer) {    NSLog(@"TXNSTimerBlockController timer start");
}];

[[NSRunLoop mainRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];self.timer = timer;

此处以NSTimer举例,CADisplayLink不再详述(方式都是一样)。




本文转自lzwxx 51CTO博客,原文链接:http://blog.51cto.com/13064681/1943387
相关文章
|
16天前
|
JavaScript 前端开发 Java
垃圾回收机制会导致内存泄漏吗?
【10月更文挑战第29天】虽然JavaScript的垃圾回收机制本身是为了有效地管理内存,但开发者在编写代码时需要注意上述这些可能导致内存泄漏的情况,遵循良好的编程习惯,及时释放不再使用的资源,以确保程序能够高效地利用内存资源,避免出现内存泄漏问题。
|
6月前
|
存储 Java Android开发
内存泄露
内存泄露
40 2
内存泄露
|
编解码 API iOS开发
iOS - NSTimer循环引用
iOS - NSTimer循环引用
|
Java 应用服务中间件
浅谈内存泄露
正文 定义 首先,我们要先谈一下定义,因为一堆人搞不懂内存溢出和内存泄露的区别。 内存溢出(OutOfMemory):你只有十块钱,我却找你要了一百块。
1201 0
|
Java .NET 程序员