关于performSelector:afterDelay:的一个坑及思考

原文连接: kukumalucn.github.io/blog/2018/1…git

前言

刚在群里看到这样一段代码,颇有意思:github

- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event
{
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        NSLog(@"1");
        [self performSelector:@selector(test) withObject:nil afterDelay:0];
        NSLog(@"2");
    });
}
- (void)test
{
    NSLog(@"3");
}
复制代码

这段代码的执行结果会是什么呢? 是打印“一、2”,仍是“一、三、2”,或者是“一、二、3”?面试

内容

1.问题探究

这实际上是一道颇有意思的面试题,内容涉及runloop这个知识点。 答案是只打印:“一、2”。 缘由群里的大神给了解答:xcode

由于[self performSelector:@selector(test) withObject:nil afterDelay:.0]实际在runloop里面,是一个定时器,可是由于在子线程,runloop是默认没有开启的。多线程

这除了涉及runloop,还有多线程的问题,有兴趣的能够深究。 其实咱们只要仔细阅读苹果API的注释,就能解释这个问题:async

想要执行-test方法,注释里也提供了解决办法:oop

[self performSelectorOnMainThread:@selector(test) withObject:nil waitUntilDone:YES];
复制代码

其实针对上述的逻辑,更简单的是:ui

[self performSelector:@selector(test) withObject:nil];
复制代码

2.引起的思考

2.1.不要懒

之因此要提上述的问题,除了这个面试的“考点”,其实在平时的开发过程当中也要注意本身代码的严谨性。 我发现本身在阅读别人的代码时,就见过一样的写法,其实甚至那些比较有名的三方库,例如“YYText”中,也有相似的代码存在:spa

[self performSelector:@selector(test) withObject:nil afterDelay:0];
复制代码

写这段代码的人只是为了经过selector来马上执行某一方法,delay并非他们的需求,为何还要“画蛇添足”呢? 这里一大部分缘由,极可能仍是由于咱们被xcode的自动提示给“惯坏了”:线程

毕竟当你写代码时,罗列的一堆提示,只是按照API类似度排列出来的,不少人看到了本身须要的就直接回车了,不须要delay,直接写0,就好了,反正“都同样”…… 其实这是一个误区,看起来很类似的API,实则并不同,并且很不同:

  • 咱们经常使用的这个perform,是NSObject.h这个头文件下的方法:

  • 能够delay的,是NSRunLoop.h下的方法:

  • 而以前提到的回调主线程的,是NSThread.h里的方法:

虽然他们都是NSObject的方法或者是分类补充方法,但实际上,是隶属于不一样的模块的。

2.2.更深入的缘由

可是“YYText”的做者应该是不会犯这种低级错误的,那就应该还有更深入的缘由了:

咱们不少人应该老是会被上述的警告所困扰,大多数人的解决方式,就是利用相似相面的方式去屏蔽警告,这种作法虽然简单,但实际是有风险的:

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
//code
#pragma clang diagnostic pop
复制代码

其实除了利用IMP或者NSInvocation那种比较“高端”的方式,更多的状况下,在方法没有返回值时,或者咱们不须要返回值时,咱们能够用:

[self performSelector:@selector(test) withObject:nil afterDelay:0];
复制代码

这种方式去避免警告的,看上面的那三个对比你就会发现,后两类API,一样是performSelector,却没有返回值,这其实也是有官方注释的依据的:

但其实你也要注意到了,官方的建议仍是很严谨的,是用performSelectorOnMainThread,而不是delay0的方式,至于缘由,咱们又回到了文章一开头的讨论了。

总结

经过上面看似无心义的探究,咱们仍是能够获得很深入的教训的:“苹果霸霸”仍是很严谨的,多看API的注释,老是没错的。


本文做者: 霖溦
本文连接: kukumalucn.github.io/blog/2018/1…
版权声明: 本博客全部文章除特别声明外,均采用 CC BY-NC-ND 4.0 许可协议。转载请注明出处!

相关文章
相关标签/搜索