如何找到防止在objective-c/Xcode中使用dealloc的無用參考？

我在iOS應用程序中遇到問題，經過一段時間後，對象沒有被釋放，因爲它應該是。我懷疑這是因爲還有一個參考。我正在使用ARC。如何找到防止在objective-c/Xcode中使用dealloc的無用參考？

我想知道創建引用的位置。然後，我將能夠告訴它應該在哪裏被置零，或者它應該被作爲弱引用。

我想象的那樣一個可能的解決方案：

如果我可以設置每一個地方的引用計數，又名保留計數，被修改的地方設置一個斷點，然後我會很快找到問題所在。我只是不知道如何設置這樣一個斷點。也許在ARC之前，這可以通過在retain和release內設置斷點來完成，但我不知道如何使用ARC來做到這一點。

高度簡化的例子代碼：

我在我班的一個這樣做，我知道：

// ShouldBeDeallocated.m 

- (void) dealloc { 
    NSLog(@"%s", __FUNCTION__); // this never shows up in output 
}

而且我懷疑，我前一段時間寫了這樣的代碼，但我找不到在哪裏，這是：

// UnknownSuspect.m 

@interface UnknownSuspect() 

@property (strong, readwrite) id referenceWhichIsNeverNeeded; 

@end 

- (void) someMethod:(ShouldBeDeallocated*)ref { 
    self.referenceWhichIsNeverNeeded = ref; 
    // The object pointed to by referenceWhichIsNeverNeeded will 
    // not be dealloc'ed unless the property gets overwritten. 
}

來源

2014-02-26 Daniel S.

我檢查了靜態分析器的所有警告。我也用儀器來檢查內存泄漏。大部分顯示的泄漏都會在NSMutableDictionary或malloc中說幾個字節。在那裏，我沒有發現任何與我寫的代碼有關的東西。 –

我的問題可能是http://stackoverflow.com/questions/6988911/finding-all-references-to-an-object-instance-in-obj-c的重複。 –

這個問題仍然沒有得到我完全接受的答案，但我解決了我的個人問題，通過手動閱讀我的代碼堆。通過這個手工努力，我終於找到了罪魁禍首，一個循環參考。由於某些原因，儀器不會檢測到這個循環參考，儘管它非常簡單。 –

您可以使用儀器來分析內存分配。然後你可以看到你的代碼在哪裏分配它並改變保留計數。儀器還可以幫助您追蹤代碼中存在內存泄漏的位置，即使使用ARC，仍可能發生內存泄漏。

來源

2014-02-26 16:09:41 Gavin

我仍然不知道如何發現未發佈的非弱引用，例如循環參考。我知道「儀器可以用來發現內存泄漏」，但這是一種廣泛暗示的方式。我的問題不是分配，而是我在稍後的時間裏保留了太多的參考。 –

@DanielS。這是追蹤內存問題的第一步。你應該能夠看到你的代碼中你的違規對象被保留在哪裏，並確定哪些其他對象具有對它的引用。那麼你可以看到爲什麼那些仍然保留。我認爲你的代碼中的斷點不會有多大的幫助，但分析儀器上發生的事情是內存泄漏問題的前提。您還應該在Xcode中使用靜態分析器來查看它是否看到可能導致內存泄漏的代碼可能存在的任何問題。 – Gavin

我檢查了靜態分析器的所有警告。我也用儀器來檢查內存泄漏。大部分顯示的泄漏都會在NSMutableDictionary或malloc中說幾個字節。在那裏，我沒有發現任何與我寫的代碼有關的東西。儀器能否檢測到我意外遺留的參考，但不再需要？ –

如何找到防止在objective-c/Xcode中使用dealloc的無用參考？

回答

相關問題