美文网首页iOS Crash拦截器iOS技术
Crash拦截器 - NSTimer无法释放和内存泄漏之解除

Crash拦截器 - NSTimer无法释放和内存泄漏之解除

作者: 一纸苍白 | 来源:发表于2021-06-09 11:05 被阅读0次

    前言

    在iOS开发中,我们使用定时器(timer)的几率很高,系统中最常用的方式有GCD中提供的timer接口和我们今天要讨论的NSTimer。关于GCD相关的接口,我们今天不讨论,我们接下来看看NSTimer.

    对于NSTimer,我们都知道这家伙最让人深恶痛绝的,肯定就是它容易引起循环引用,造成内存泄漏,甚至在执行定时任务的时候导致crash。

    我们接下将会分析NSTimer是如何引起循环引用,并给出几种方案来破开这种循环引用状态。

    NSTimer造成内存泄漏的原因

    我们查看scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:timerWithTimeInterval:target:selector:userInfo:repeats:的接口文档,可以看到对target的有这样的一句解释:

    The timer maintains a strong reference to target until it (the timer) is invalidated.

    哦豁!NSTimer会对target进行强持有,如果这个时候作为target的对象(例如我们最常见的情况:UIViewController)强持有NSTimer,这就引起了循环引用。

    既然引起了循环引用,那么在破开这个引用环之前,NSTimertarget都无法被释放,这就很合理了。

    既然这样,我们就破开引用环。我们在必要的时候在target中将NSTimer置为nil。这样是否就可以释放NSTimer了呢?答案是:不行。有兴趣的同学可以试试,在NSTimerselector中加一条打印,我们会发现这该死的打印根本不会自己停,直到你因为再也不想看到它而关掉调试为止。

    在我们心态爆炸,一脸懵逼的时候,我们再看看官方文档对NSTimer的一段介绍:

    Timers work in conjunction with run loops. Run loops maintain strong references to their timers, so you don’t have to maintain your own strong reference to a timer after you have added it to a run loop.

    这段话提到了一个关键点:在我们将NSTimer加入到RunLoop中之后,RunLoop就会维持对NSTimer的强引用。这也是不管我们是否在控制器中对NSTimer进行强引用,在我们没有将NSTimer进行invalidate之前,NSTimer都无法被释放的原因了。

    说到invalidate,我们看看官方文档对这个方法的介绍:

    Stops the timer from ever firing again and requests its removal from its run loop.

    我们可以看到invalidate方法做了两个事情:1.停止了NSTimer的定时事件。2.将NSTimerRunLoop中移除。

    看到这里是否是恍然大悟,原来NSTimer得已被释放,最大的功臣是invalidate方法,如果没有它,我们想从RunLoop中移除NSTimer可就是个麻烦的事了。

    所以如果要释放NSTimer,我么必须做到两件事:1.打破NSTimertarget的引用环。2.将NSTimerRunLoop中移除,即调用NSTimerinvalidate方法。

    NSTimer循环引用的解决方案

    对于调用NSTimerinvalidate方法的必要性,默默告诫自己要加强注意之后,我们暂且不多做讨论了。我们回到循环引用的问题,下面给出几个解决方案:

    1. 手动释放NSTimer
    2. 调用苹果系统API(iOS10以后支持)
    3. 使用block解决循环引用
    4. 使用中间件NSProxy解决循环引用

    瞅准时机手动释放NSTimer

    UIViewController持有NSTimer为例,这里不管是强持有还是弱持有,都有RunLoop强持有NSTimerNSTimer强持有UIViewController,这会导致UIViewController不能自己释放。所以我们必须瞅准机会手动调用invalidate方法,将NSTimer释放掉。而这个时机嘛,具体的业务代码具体处理吧(手动阴险)。

    下面给出一种最傻瓜式的处理方式:

    - (void)viewWillAppear:(BOOL)animated {
        [super viewWillAppear:animated];
    
        self.timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(handleTimer) userInfo:nil repeats:YES];
    }
    
    - (void)viewWillDisappear:(BOOL)animated {
        [super viewWillDisappear:animated];
    
        [self.timer invalidate];
        self.timer = nil;
    }
    

    我想,嗯,这种方式真的很难满足我们各种复杂的业务场景,只能在最基本的情况下使用。这里列举出来,只是给出一种打破引用的方式(而已)。

    调用苹果系统API(iOS10以后支持)

    也许是苹果公司对NSTimer的这种无法释放的问题再也看不过眼了,也许是某个苹果工程师在写代码的时候,是在是不想忍受这种心惊胆战的编码模式了。总之,在iOS10.0以后,NSTimer类多了如下的两个接口:

    + (NSTimer *)timerWithTimeInterval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(void (^)(NSTimer *timer))block;
    + (NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(void (^)(NSTimer *timer))block;
    

    我们可以看到,这两个接口不用传targetselector。这不就意味着NSTimer不会强持有target,这循环引用的问题不就在还没开始就被扼杀了嘛!

    不过可惜的是,到iOS10才支持,目前我所处的项目都要支持到iOS9,这真是一个悲伤的故事(手动哭唧唧)。

    类对象持有 -> 使用block解决循环引用

    我们创建一个分类,代码如下:

    @interface NSTimer (NoRetainCycleWithBlock)
    
    + (NSTimer *)nrc_timerWithTimeInterval:(NSTimeInterval)ti repeats:(BOOL)repeats block:(dispatch_block_t)block;
    
    + (NSTimer *)nrc_scheduledTimerWithTimeInterval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(dispatch_block_t)block;
    @end
    
    
    @implementation NSTimer (NoRetainCycleWithBlock)
    
    + (NSTimer *)nrc_timerWithTimeInterval:(NSTimeInterval)ti repeats:(BOOL)repeats block:(dispatch_block_t)block {
        return [self timerWithTimeInterval:ti target:self selector:@selector(nrc_blockHandler:) userInfo:[block copy] repeats:repeats];
    }
    
    + (NSTimer *)nrc_scheduledTimerWithTimeInterval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(dispatch_block_t)block {
        return [self scheduledTimerWithTimeInterval:interval
                                             target:self
                                           selector:@selector(nrc_blockHandler:)
                                           userInfo:[block copy]
                                            repeats:repeats];
    }
    
    + (void)nrc_blockHandler:(NSTimer *)timer {
        dispatch_block_t block = timer.userInfo;
        if (block) {
            block();
        }
    }
    
    @end
    

    我们为NSTimer添加了两个方法,以供开发者来创建NSTimer。通过这两个方法创建NSTimer的关键点如下:

    1. NSTimer的定时任务会以block的形式进行回调。
    2. NSTimertarget传入self,这里的上下文环境是在类方法中,所以这里的selfNSTimer的类对象。即NSTimer会持有NSTimer的类对象(也就是NSTimer.class)。
    3. NSTimeruserInfo传入了blockcopy,保证block存在堆中。并且由于被NSTimer持有,所以不会被释放。
    4. NSTimerselector传入了方法nrc_blockHandler:,该方法中获取了timer.userInfo,然后执行block回调定时任务。

    上面的代码获得了什么成果呢?

    NSTimertarget换成了NSTimer的类对象,而类对象一直存在于内存中,所以即便是循环引用了,造成的影响也不是很大。

    但是我们需要注意一点是,当UIViewController(即创建timer的地方)被释放而NSTimer未被释放时,定时任务执行block,此时有可能会造成访问野指针引起的崩溃问题。

    所以,敲黑板啦!UIViewControllerdealloc中一定要记得调用invalidate方法释放NSTimer,以避免我们最最不想看到的崩溃!!!

    消息转发 -> 使用中间件NSProxy

    同样的,我们可以使用一个中间件,使NSTimer强引用中间件,而中间件弱引用UIViewController,从而打破引用环。

    对于中间件,我们选用比NSObject更为轻量级的NSProxy

    中间件的实现代码如下:

    @interface ORCWeakProxy : NSProxy
    
    @property (nonatomic, readonly, weak) id target;
    
    - (instancetype)initWithTarget:(id)target;
    + (instancetype)proxyWithTarget:(id)target;
    
    @end
    
    @implementation ORCWeakProxy
    
    - (instancetype)initWithTarget:(id)target {
        _target = target;
        
        return self;
    }
    
    + (instancetype)proxyWithTarget:(id)target {
        return [[self.class alloc] initWithTarget:target];
    }
    
    - (BOOL)respondsToSelector:(SEL)aSelector {
        return [self.target respondsToSelector:aSelector];
    }
    
    // 转发目标选择器
    - (id)forwardingTargetForSelector:(SEL)selector {
        return self.target;
    }
    
    // 函数执行器
    - (void)forwardInvocation:(NSInvocation *)invocation {
        void *null = NULL;
        [invocation setReturnValue:&null];
    }
    
    // 方法签名的选择器
    - (NSMethodSignature *)methodSignatureForSelector:(SEL)sel {
        return [NSObject instanceMethodSignatureForSelector:@selector(init)];
    }
    
    @end
    

    使用时的代码如下:

        ORCWeakProxy *proxy = [ORCWeakProxy proxyWithTarget:aTarget];
        self.timer = [NSTimer scheduledTimerWithTimeInterval:ti
                                                      target:proxy
                                                    selector:aSelector
                                                    userInfo:nil
                                                     repeats:YES];
    

    中间件的加入,使得NSTimertarget成为中间件,而中间件UIViewController是弱引用,所以UIViewController可以被释放。

    因为NSTimertarget成为中间件,所以NSTimer在执行定时任务时,会调用中间件selector方法,然而中间件肯定是没有这个selector方法的,所以我们需要在中间件中进行方法的转发。我们使用forwardingTargetForSelector:使得响应selector方法的对象转移为self.target,即UIViewController

    既然方法已经被转发了,后续的消息转发接口就不会被执行了,那么我们还有必要重写methodSignatureForSelector:forwardInvocation:吗?

    答案是:很有必要!。因为,当UIViewController被释放之后,就会出现在target上找不到selector,如果不重写,那么恭喜你,崩溃等着你(手动坏笑)!不过这两个方法只要实现,随便写写就行,只要有,其它都不要求。

    不过使用这种方式,有以下几点需要注意:

    1. NSProxy是一个虚类,所以我们无法直接使用,而是创建一个该类的子类。
    2. 重要的事情又来了,在UIViewControllerdealloc方法中,记得加上[self.timer invalidate],谢谢(手动微笑)!如果不手动释放NSTimerNSTimer依旧会持续执行定时任务,虽然你看不到,但它就在那里执行。有兴趣的小伙伴可以在中间件forwardInvocation:打个断点试试。

    中间件解决NSTimer的循环引用问题的目的已经达到了。但是在每个使用的地方,都需要引入ORCWeakProxy的头文件,这让我用起来有点不乐意啊!所以我们又添加一个NSTimer分类,代码如下:

    @interface NSTimer (NoRetainCycleWithProxy)
    
    @end
    
    @implementation NSTimer (NoRetainCycleWithProxy)
    
    + (void)load {
        static dispatch_once_t onceToken;
        dispatch_once(&onceToken, ^{
            [self orc_exchangeSelector:@selector(scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:)
                            toSelector:@selector(orc_scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:)];
    
            [self orc_exchangeSelector:@selector(timerWithTimeInterval:target:selector:userInfo:repeats:)
                            toSelector:@selector(orc_timerWithTimeInterval:target:selector:userInfo:repeats:)];
        });
    }
    
    + (NSTimer *)orc_timerWithTimeInterval:(NSTimeInterval)ti target:(id)aTarget selector:(SEL)aSelector userInfo:(nullable id)userInfo repeats:(BOOL)yesOrNo {
        return [self orc_timerWithTimeInterval:ti
                                        target:[ORCWeakProxy proxyWithTarget:aTarget]
                                      selector:aSelector
                                      userInfo:userInfo
                                       repeats:yesOrNo];
    }
    
    + (NSTimer *)orc_scheduledTimerWithTimeInterval:(NSTimeInterval)ti target:(id)aTarget selector:(SEL)aSelector userInfo:(nullable id)userInfo repeats:(BOOL)yesOrNo {
        return [self orc_scheduledTimerWithTimeInterval:ti
                                                 target:[ORCWeakProxy proxyWithTarget:aTarget]
                                               selector:aSelector
                                               userInfo:userInfo
                                                repeats:yesOrNo];
    }
    
    @end
    

    我们在分类里交换了创建NSTimer的方法,在新的方法里来创建NSTimer,并将中间件作为target传给这个NSTimer。这样,我们就可以无感知的使用中间件来解决NSTimer的循环引用问题了(nice)!

    其实写到这里,关于消息转发 -> 使用中间件NSProxy来处理NSTimer的循环引用问题,就已经写完了。但是说实话,总是被提醒:要我们手动释放NSTimer,否则就会造成内存泄漏!这让我怎么的都不是很爽。秉着如果觉得不爽,那就要让自己爽起来的态度,我又在中间件中加了一些小东西:

    1. ORCWeakProxy添加属性timer
    2. forwardingTargetForSelector:target进行判断,如果targetnil则认为target已经被释放,这个时候就释放timer

    代码片段如下:

    @interface ORCWeakProxy : NSProxy
    
    @property (nonatomic, readonly, weak) id target; 
    @property (nonatomic, weak) id timer; 
    
    - (instancetype)initWithTarget:(id)target;
    + (instancetype)proxyWithTarget:(id)target;
    
    @end
    
    - (id)forwardingTargetForSelector:(SEL)selector {
        // 如果发现target为nil后,就停掉timer
        if (self.target == nil) {
            [self.timer invalidate];
        }
        return self.target;
    }
    
    1. timer属性使用weak修饰,避免出现循环引用问题。
    2. targetnil后,调用invalidate方法释放timer,那么就不需要再在考虑UIViewController被释放,而NSTimer没被释放的问题了(手动开心)。

    以上,我们在使用NSTimer时,只需要调用接口创建NSTimer对象,并使用它满足我们的各种需求,而不再需要去关心,它会不会在满足我们的需求之后,对我们造成什么不好的影响了。

    相关文章

      网友评论

        本文标题:Crash拦截器 - NSTimer无法释放和内存泄漏之解除

        本文链接:https://www.haomeiwen.com/subject/togseltx.html