ios中timer相关的延时调用需要注意的地方

本文探讨了iOS中常见的延时调用方法及其在多线程环境下的安全性问题。通过对NSObject中的performSelector系列方法及NSTimer的分析,指出了它们在子线程中可能存在的问题,并提供了一种使用GCD的解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

源文:http://my.oschina.net/xiguaa/blog/146424

ios中timer相关的延时调用,常见的有两种,一种是NSObject中的performSelector:withObject:afterDelay:以及performSelector:withObject:afterDelay:inModes:。这两个方法在调用的时候会设置当前runloop中timer,前者设置的timer在NSDefaultRunLoopMode运行,后者则可以指定NSRunLoop的mode来执行。还有一种延时调用,是直接配置timer来运行,利用NSTimer来配置任务。这两种方式都一个共同的前提,就是当前线程里面需要有一个运行的runloop并且这个runloop里面有一个timer。
而我们都知道的是,只有主线程会在创建的时候默认自动运行一个runloop,并且有timer,普通的子线程是没有这些的。这样就带来一个问题了,有些时候我们并不确定我们的模块是不是会异步调用到,而我们在写这样的延时调用的时候一般都不会去检查运行时的环境,这样在子线程中被调用的时候,我们的代码中的延时调用的代码就会一直等待timer的调度,但是实际上在子线程中又没有这样的timer,这样我们的代码就永远不会被调到。
回过头来看,在有多线程操作的环境中,这样的延时调用其实是缺乏安全性的。我们可以用另一套方案来解决这个问题,就是使用GCD中的dispatch_after来实现单次的延时调用:

    double delayInSeconds = 2.0;

    dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(delayInSeconds * NSEC_PER_SEC));

    dispatch_after(popTime, dispatch_get_main_queue(), ^(void){

        [self someMethod];

    });

dispatch_time的单位是纳秒,为防止用户使用时候的出现换算上的错误,Xcode在开发者打dispatch_after的时候会自动补全上面一整段代码。

而如果有循环的调用的话,可以用dispatch_source_set_timer来实现:

    int interval = 2;

    int leeway = 0;

    

    dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

    dispatch_source_t timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, queue);

    if (timer) {

        dispatch_source_set_timer(timer, dispatch_walltime(DISPATCH_TIME_NOW, NSEC_PER_SEC * interval), interval * NSEC_PER_SEC, leeway);

        dispatch_source_set_event_handler(timer, ^{

            [self someMethod];

        });

        dispatch_resume(timer);

    }


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值