iOS容易造成循环引用的三种场景NSTimer以及对应的使用方法(一)

原创
2015/06/12 16:32
阅读数 961

对,这就是NSTimer ,

1.NSTimer会retain你添加调用方法的对象

        2.NSTimer是要加到runloop中才会起作用

3.NSTimer会并不是准确的按照你指定的时间触发的

        4.NSTimer就算添加到runloop了也不一定会按照你想象中的那样执行

NSTimer和它调用的函数对象间到底发生了什么

  那么timer会在未来的某个时刻执行一次或者多次我们指定的方法,这也就牵扯出一个问题,如何保证timer在未来的某个时刻触发指定事件的时候,我们指定的方法是有效的呢?

 解决方法很简单,只要将指定给timer的方法的接收者retain一份就搞定了,实际上系统也是这样做的。不管是重复性的timer还是一次性的timer都会对它的方法的接收者进行retain,这两种timer的区别在于“一次性的timer在完成调用以后会自动将自己invalidate,而重复的timer则将永生,直到你显示的invalidate它为止”。

     一方面,NSTimer经常会被作为某个类的成员变量,而NSTimer初始化时要指定self为target,容易造成循环引用。 另一方面,若 timer一直处于validate的状态,则其引用计数将始终大于0。

LIST:

#import <Foundation/Foundation.h>

#import <UIKit/UIKit.h>

@interface TsetClass : NSObject

- (void)clearTimer;

@end


//  TsetClass.m

//  TestRuntime

//

//  Created by 58 on 15/6/1.

//  Copyright (c) 2015年 58. All rights reserved.

//

#import "TsetClass.h"


@interface TsetClass ()

{

    

    NSTimer *_myTimer;

      

}

@end



@implementation TsetClass

   - (id)init

   {

        if (self = [super init]) {

       _myTimer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(handleTimer:)

                                                                    userInfo:nil repeats:YES];

            }

         return  self;

      }


- (void)handleTimer:(id)sender{

   NSLog(@"%@ say: testTimer!", [self class]);

}

   - (void)clearTimer

   {

        [_myTimer invalidate];

       _myTimer = nil;

     }

- (void)dealloc

 {

         [self clearTimer];

         NSLog(@"[Friend class] is dealloced");

      }

@end

在类外部初始化一个TsetClass对象,并延迟5秒后将friend释放(外部运行在非arc环境下)

         TsetClass *f = [[TsetClass alloc] init];         dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5*NSEC_PER_SEC), dispatch_get_main_queue(), ^{
             [f release];         });

     我们所期待的结果是,初始化5秒后,f对象被release,f的dealloc方法被调用,在dealloc里面timer失效,对象被析构。但结果却是如此:

2015-06-02 14:04:08.229 TestRuntime[8883:135129] TsetClass say: testTimer!

2015-06-02 14:04:09.231 TestRuntime[8883:135129] TsetClass say: testTimer!

2015-06-02 14:04:10.227 TestRuntime[8883:135129] TsetClass say: testTimer!

2015-06-02 14:04:11.228 TestRuntime[8883:135129] TsetClass say: testTimer!

2015-06-02 14:04:12.231 TestRuntime[8883:135129] TsetClass say: testTimer!

2015-06-02 14:04:13.227 TestRuntime[8883:135129] TsetClass say: testTimer!

2015-06-02 14:04:14.229 TestRuntime[8883:135129] TsetClass say: testTimer!

2015-06-02 14:04:15.231 TestRuntime[8883:135129] TsetClass say: testTimer!

2015-06-02 14:04:16.229 TestRuntime[8883:135129] TsetClass say: testTimer!

2015-06-02 14:04:17.231 TestRuntime[8883:135129] TsetClass say: testTimer!

2015-06-02 14:04:18.230 Te...

这是为什么呢?主要是因为从timer的角度,timer认为调用方(Friend对象)被析构时会进入dealloc,在dealloc可以顺便将timer的计时停掉并且释放内存;但是从Friend的角度,他认为timer不停止计时不析构,那我永远没机会进入dealloc。循环引用,互相等待,子子孙孙无穷尽也。问题的症结在于-(void)cleanTimer函数的调用时机不对,显然不能想当然地放在调用者的dealloc中。一个比较好的解决方法是开放这个函数,让Friend的调用者显式地调用来清理现场。如下:


TsetClass *f = [[TsetClass alloc] init];
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5*NSEC_PER_SEC), dispatch_get_main_queue(), ^{
    [f clearTimer];
    [f release];
});

到此timer的循环引用就说完了!!!

综上: timer都会对它的target进行retain,我们需要小心对待这个target的生命周期问题,尤其是重复性的timer。(NSTimer初始化后,self的retainCount加1。 那么,我们需要在释放这个类之前,执行[timer invalidate];否则,不会执行该类的dealloc方法。)

那么Timer 的使用你到底会了吗

NSTimer不是一个实时系统,因此不管是一次性的还是周期性的timer的实际触发事件的时间可能都会跟我们预想的会有出入。差距的大小跟当前我们程序的执行情况有关系,比如可能程序是多线程的,而你的timer只是添加在某一个线程的runloop的某一种指定的runloopmode中,由于多线程通常都是分时执行的,而且每次执行的mode也可能随着实际情况发生变化。假设你添加了一个timer指定2秒后触发某一个事件,但是签好那个时候当前线程在执行一个连续运算(例如大数据块的处理等),这个时候timer就会延迟到该连续运算执行完以后才会执行。重复性的timer遇到这种情况,如果延迟超过了一个周期,则会和后面的触发进行合并,即在一个周期内只会触发一次。但是不管该timer的触发时间延迟的有多离谱,他后面的timer的触发时间总是倍数于第一次添加timer的间隙。

当线程空闲的时候timer的消息触发还是比较准确的


NSTimer为什么要添加到RunLoop中才会有作用

  前面的例子中我们使用的是一种便利方法,它其实是做了两件事:首先创建一个timer,然后将该timer添加到当前runloop的default mode中。也就是这个便利方法给我们造成了只要创建了timer就可以生效的错觉,我们当然可以自己创建timer,然后手动的把它添加到指定runloop的指定mode中去。

  NSTimer其实也是一种资源,如果看过多线程变成指引文档的话,我们会发现所有的source如果要起作用,就得加到runloop中去。同理timer这种资源要想起作用,那肯定也需要加到runloop中才会又效喽。如果一个runloop里面不包含任何资源的话,运行该runloop时会立马退出。你可能会说那我们APP的主线程的runloop我们没有往其中添加任何资源,为什么它还好好的运行。我们不添加,不代表框架没有添加,如果有兴趣的话你可以打印一下main thread的runloop,你会发现有很多资源。

NSTimer加到了RunLoop中但迟迟的不触发事件

1、runloop是否运行

  每一个线程都有它自己的runloop,程序的主线程会自动的使runloop生效,但对于我们自己新建的线程,它的runloop是不会自己运行起来,当我们需要使用它的runloop时,就得自己启动。

  那么如果我们把一个timer添加到了非主线的runloop中,它不会按照预期按时触发

2、mode是否正确

  我们前面自己动手添加runloop的时候,可以看到有一个参数runloopMode,这个参数是干嘛的呢?

  前面提到了要想timer生效,我们就得把它添加到指定runloop的指定mode中去,通常是主线程的defalut mode。但有时我们这样做了,却仍然发现timer还是没有触发事件。这是为什么呢?

  这是因为timer添加的时候,我们需要指定一个mode,因为同一线程的runloop在运行的时候,任意时刻只能处于一种mode。所以只能当程序处于这种mode的时候,timer才能得到触发事件的机会。

  举个不恰当的例子,我们说兄弟几个分别代表runloop的mode,timer代表他们自己的才水桶,然后一群人去排队打水,只有一个水龙头,那么同一时刻,肯定只能有一个人处于接水的状态。也就是说你虽然给了老二一个桶,但是还没轮到它,那么你就得等,只有轮到他的时候你的水桶才能碰上用场


综上: 要让timer生效,必须保证该线程的runloop已启动,而且其运行的runloopmode也要匹配。


展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部