前几天在给游戏做收尾测试时，发现了一个关于内存泄露的问题，一直没找着问题所在，经过反复调试和查找资料今天终于解决了，特此记录下来以免以后再犯！

关于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: ，否则有可能产生内存泄露，而且这种内存泄露很难发现，因为它并不违反任何规则，所以一定要注意！