Come posso determinare quali oggetti contengono riferimenti ad altri oggetti che causano perdite di memoria nell'obiettivo-c?

Question

Ho provato a utilizzare lo strumento perdite e "analizzare" ecc. Per trovare la perdita, ma non riesce a trovarla. Usando le allocazioni posso determinare gli oggetti che non vengono rilasciati.

Ho notato (aggiungendo le istruzioni di debug nel metodo dealloc), che dealloc non viene chiamato per questi oggetti.

Come è possibile determinare quali oggetti contengono riferimenti a questi oggetti e impedire che vengano rilasciati?

Answer 1

Lo strumento di analisi era in grado di rilevare il problema. L'utilizzo dello strumento di allocazione per acquisire tutti i conteggi di riferimento era un inizio, ma c'erano così tante classi che non riconoscevo, o accesso diretto, non ero in grado di rintracciare il problema usando questo metodo. Invece, ho fatto un elenco delle classi di cui ero direttamente responsabile e ho esaminato ciascuna riga riga per riga finché non ho trovato i problemi. La causa era che usavo alcune librerie di terze parti che non diminuivano il numero di ritenzione di alcuni dei miei oggetti come previsto. Immagino che in questo caso, seguendo i migliori principi di progettazione del software/schemi di progettazione, e avendo recensioni approfondite del codice possa aver colto il problema in precedenza.

Answer 2

Vorrei iniziare con la costruzione e l'analisi del progetto (Shift Command B nell'IDE).

Answer 3

È possibile sovraccaricare le implementazioni di mantenimento/rilascio/autorelease in classi problematiche (se è una classe SDK, è possibile utilizzare una categoria) e impostare il punto di interruzione lì. Il punto di interruzione verrà colpito ogni volta che qualcosa mantiene il tuo oggetto.

Answer 4

Se avete bisogno di vedere dove conserva, stampa e autoreleases si verificano per uno strumenti uso oggetto:

Run in strumenti, in dotazioni fissate "conta di riferimento di registrazione" a on (si deve fermare la registrazione per impostare l'opzione). Causa il picker di eseguire, interrompere la registrazione, cercare lì ivar (datePickerView), drill-down e sarete in grado di vedere dove si sono verificati tutti i ritardi, rilasci e autoreleases.