Strumenti e crescita dell'heap, quando la crescita è davvero una perdita?

Question

Sto utilizzando strumenti su un dispositivo per cercare di capire se ho perdite di memoria o abbandonato. Nello specifico sto usando perdite e allocazioni. Mentre gli strumenti non evidenzia alcuna perdita, ciò non significa che non abbia problemi di memoria. Ci sto lavorando da settimane, e non mi sembra di essere più vicino a capire quali problemi ho (ugh).

Sto testando una particolare azione eseguendo un heapshot dopo l'azione e ripetendo. Dopo le prime poche generazioni di "stabilirsi", posso vedere che la crescita e il conteggio persistente iniziano tutti ad un certo numero (diversi kb). Dopo molte iterazioni ripetute (diciamo 10-20), alcune (non tutte) lentamente finiscono per drenare a 0. Ci vuole un po ', ma succede. Le generazioni in cui rimane memoria persistente non mi mostrano mai nulla di utile, poiché la traccia dello stack mostra tutte le librerie di sistema.

Quindi le mie domande sono:

1. Che cosa significa questo tipo di comportamento indica? Ho problemi di memoria? C'è qualche tipo di memoria pigra della memoria da qualche parte?
2. In un mare di iterazioni che mostrano memoria persistente, cosa significa una iterazione di crescita dell'heap zero?
3. Se la traccia dello stack per una particolare generazione punta solo alle librerie di sistema, significa che la crescita dell'heap per quella generazione è valida o che c'è un bug? O potrebbe ancora significare che c'è qualcosa che trattiene il ricordo dalla mia parte?
4. Che cosa significa quando la traccia dello stack mostra la libreria e il metodo, ma è disattivata come il codice di sistema e ha un'icona piccola, contro una linea con la libreria e il metodo che è in nero e ha una piccola persona icona?
5. Se ho qualcosa come un ciclo di mantenimento, la crescita persistente non sarebbe coerente?

Qualsiasi risposta alle informazioni sarebbe estremamente utile!

Answer 1

mi prendo una pugnalata alle vostre domande:

Che cosa significa questo tipo di comportamento indica? Ho problemi di memoria? c'è qualche tipo di memoria pigra della memoria da qualche parte?

Poiché non è possibile sapere come i quadri di sistema a gestire le loro esigenze di memoria privata, si deve supporre che sì, ci potrebbe essere pigro/rilascio della memoria accade ogni volta che si chiama nei quadri del sistema differito, che nella maggior parte le app sono "tutto il tempo". Oltre a non essere in grado di escluderlo, posso dire con certezza che ci sono sicuramente allocazioni di lunga durata innescate da un uso apparentemente innocuo del framework di sistema. (Si veda la discussione di utilizzo longeva memoria del UIWebView in this answer per un esempio.)

In un mare di iterazioni che mostrano memoria permanente, che cosa fa una crescita zero mucchio iterazione significa?

Difficile dire. Una buona ipotesi di primo ordine potrebbe essere che la crescita dell'heap associata all'iterazione fosse in qualche modo esattamente compensata da una release lazy/deferred della memoria allocata per una precedente iterazione.

Se l'analisi dello stack per una particolare i punti di generazione solo per le librerie di sistema, questo significa la crescita heap per che generazione è valido o che ci sia un bug? O potrebbe ancora significare che c'è qualcosa che trattiene la memoria dalla mia parte?

Se gli strumenti mostrano una crescita dell'heap, allora quella crescita dell'heap è quasi certamente esistente. Dipende se la crescita dell'heap è qualcosa su cui hai il controllo diretto. Se non fai chiamate nei framework di sistema (non probabile), allora è sicuramente colpa tua. Una volta effettuata una chiamata nei framework di sistema, è necessario accettare la possibilità che il framework possa allocare memoria che rimane allocata dopo il ritorno della chiamata.

Cosa significa quando l'analisi dello stack mostra la libreria e il metodo, ma è in grigio come il codice di sistema e ha una piccola icona casa, vs aa linea con la libreria e il metodo che è in nero e ha un po 'l'icona della persona ?

Linee in grigio indicano che Strumenti non dispone di simboli di debug per quella linea. È tutto. Non indica nulla di specifico per quanto riguarda l'uso della memoria.

Se ho qualcosa come un ciclo di mantenimento, la crescita persistente dello non è coerente?

Se ogni iterazione creato un nuovo oggetto grafico con ciclica conserva, allora sì, ci si aspetta che ogni iterazione causerebbe una crescita mucchio da almeno la dimensione di tale oggetto grafico. Detto questo, i piccoli oggetti grafici possono essere facilmente persi nel "rumore". Se hai dei sospetti, un modo è quello di fare in modo che gli oggetti di una classe "sospetta" eseguano un'enorme allocazione che li distingua dal "rumore". Ad esempio, rendi il tuo oggetto malloc un megabyte (o più) per ogni istanza (e, ovviamente, liberalo quando l'istanza è deallocata). Ciò può aiutare le aree problematiche a rimanere dove potrebbero non essere originariamente.