performSelector一系列方法调用和延时调用导致的内存泄露

本文对performSelector:系列方法进行了一个用法的简单分析

1.

- (id)performSelector:(SEL)aSelector;

- (id)performSelector:(SEL)aSelector withObject:(id)object;

- (id)performSelector:(SEL)aSelector withObject:(id)object1 withObject:(id)object2;

这三个方法，均为同步执行，与线程无关，主主线程和子一程中均可调用成功。等同于直接调用该方法。在需要动态的去调用方法的时候去使用。

例如：[self performSelector:@selector(test2)];与[self test2];执行效果上完全相同。

2.

- (void)performSelector:(SEL)aSelector withObject:(id)anArgument afterDelay:(NSTimeInterval)delay inModes:(NSArray *)modes;

- (void)performSelector:(SEL)aSelector withObject:(id)anArgument afterDelay:(NSTimeInterval)delay;

这两个方法为异步执行，即使delay传参为0，仍为异步执行。只能在主线程中执行，在子线程中不会调到aSelector方法。可用于当点击UI中一个按钮会触发一个消耗系统性能的事件，在事件执行期间按钮会一直处于高亮状态，此时可以调用该方法去异步的处理该事件，就能避免上面的问题。

在方法未到执行时间之前，取消方法为：

+ (void)cancelPreviousPerformRequestsWithTarget:(id)aTarget selector:(SEL)aSelector object:(id)anArgument;

+ (void)cancelPreviousPerformRequestsWithTarget:(id)aTarget;

注意：调用该方法之前或在该方法所在的viewController生命周期结束的时候去调用取消函数，以确保不会引起内存泄露。

3.

- (void)performSelectorOnMainThread:(SEL)aSelector withObject:(id)arg waitUntilDone:(BOOL)wait modes:(NSArray *)array;

- (void)performSelectorOnMainThread:(SEL)aSelector withObject:(id)arg waitUntilDone:(BOOL)wait;

这两个方法，在主线程和子线程中均可执行，均会调用主线程的aSelector方法

如果设置wait为YES:等待当前线程执行完以后，主线程才会执行aSelector方法；

设置为NO：不等待当前线程执行完，就在主线程上执行aSelector方法。

如果，当前线程就是主线程，那么aSelector方法会马上执行。

注意：apple不允许程序员在主线程以外的线程中对ui进行操作，此时我们必须调用performSelectorOnMainThread函数在主线程中完成UI的更新

4.

- (void)performSelector:(SEL)aSelector onThread:(NSThread *)thr withObject:(id)arg waitUntilDone:(BOOL)wait modes:(NSArray *)array;

- (void)performSelector:(SEL)aSelector onThread:(NSThread *)thr withObject:(id)arg waitUntilDone:(BOOL)wait;

调用指定线程中的某个方法。分析效果同3。

关于objective-c的内存管理，我们都知道一个原则就是“谁创建，谁释放”，换句话说，不是我们创建的，就不用我们去释放。但是实际上objective-c的内存管理远远没那么简单，我的情况是这样的：

我在debug模式下面用CCLOG在dealloc函数里面输出一些信息，目的就是要检查场景的dealloc方法在replaceScene的时候有没有被调用，按照子龙山人大哥的说法，如果场景切换的时候dealloc没有调用，说明你这个场景的内存有问题。有可能被某个对象retain了，其retainCount在replaceScene的时候没有减少到0，所以dealloc方法是不会调用的。如果dealloc方法都没有调掉，那么这其实就是一种内存泄露。我在检查时，发现一个场景死活不调用dealloc，最后恨不得把所有的游戏逻辑都移除了，还是不走dealloc。

最后的最后才发现实际上是performSelector延时调用的问题，经查找资料，performSelector关于内存管理的执行原理是这样的执行 [self performSelector:@selector(method1:) withObject:self.tableLayer afterDelay:3]; 的时候，系统会将tableLayer的引用计数加1，执行完这个方法时，还会将tableLayer的引用计数减1，而在我的游戏里这个延时执行函数是被多次调用的，有时切换场景时延时函数已经被调用但还没有执行，这时tableLayer的引用计数没有减少到0，也就导致了切换场景dealloc方法没有被调用，出现了内存泄露。

所以最后我的解决办法就是取消那些还没有来得及执行的延时函数，代码很简单：

[NSObject cancelPreviousPerformRequestsWithTarget:self]

当然你也可以一个一个得这样用：

[NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(method1:) object:nil]

加上了这个以后，切换场景也就很顺利地执行了dealloc方法，至此问题解决！

最后在找资料时也发现了，延时调用实现长按钮的实现思路，记录下来以备后用：

在touchBegan里面

[self performSelector:@selector(longPressMethod:) withObject:nil afterDelay:longPressTime]

然后在end 或cancel里做判断，如果时间不够长按的时间调用：

[NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(longPressMethod:) object:nil]

取消began里的方法

最后最后总结：

performSelector是一个很有用的函数，跟它打过不少交道，经过血与泪的教训，总结一下它的使用如下：

使用前先检测一下，

SEL testSelector = @selector(test:);

if([tester respondsToSelector:testSelector])

{

//如果响应就执行

[tester test:@"invoke test method"];

}

使用后，如果有必要，需要显示的调用cancelPreviousPerformRequestsWithTarget:selector:object: ，否则有可能产生内存泄露，而且这种内存泄露很难发现，因为它并不违反任何规则，所以一定要注意！