本文對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: ，否則有可能產生內存泄露，而且這種內存泄露很難發現，因為它并不違反任何規則，所以一定要注意！

總結

以上是生活随笔為你收集整理的performSelector一系列方法调用和延时调用导致的内存泄露的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。