performSelector延時調用導致的內存泄露

? 轉載：http://blog.csdn.net/wangqiuyun/article/details/7587929

前幾天在給游戲做收尾測試時，發現了一個關于內存泄露的問題，一直沒找著問題所在，經過反復調試和查找資料今天終于解決了，特此記錄下來以免以后再犯！

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

轉載于:https://www.cnblogs.com/huangzizhu/p/3697142.html

總結

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

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