5
So che prima dell'API 10 di Android, era importante chiamare recycle() per Bitmap s che non sono più utilizzati, poiché i dati grezzi effettivi sono memorizzati nella memoria nativa.Che cosa fa chiamare bitmap.recycle() su API 11+?
Tuttavia, come di API 11, Bitmap s sono memorizzati nel mucchio, quindi la mia domanda è:
è ancora necessario per chiamare recycle() su Bitmap s se l'API è abbastanza grande (almeno 11)? Che cosa fa se lo chiamo su tale API?
Quando si dice "era importante chiamare recycle() prima dell'API 10" vuol dire che se non lo si fa, la memoria non verrà mai liberata? I documenti ufficiali dicono che è "raccomandato" ma se alloca la bitmap nella memoria nativa non capisco come possa essere liberato senza una chiamata a recycle(). – Tiago
@Tiago È possibile guardare questa lezione: https://www.youtube.com/watch?v=_CruQY55HOk#t=656. Le bitmap occupavano davvero poco spazio nell'heap, ma i loro dati pixel non lo erano (pur essendo parte del meccanismo OOM dell'heap), quindi il GC non sapeva quanto fosse buono/cattivo la situazione, e se non fosse stato t attivato durante la creazione di più bitmap, è possibile ottenere facilmente OOM. Questo è il motivo per cui è importante chiamare "recycle", in modo che pulisca le bitmap il prima possibile (perché il GC non ha funzionato bene). –
Ah, capisco. Questo spiega molto. È piuttosto strano che l'eccezione OutOfMemory contenga sia l'heap che la memoria nativa mentre il GC guarderebbe solo l'heap. Una volta da Honeycomb + i dati dei pixel delle bitmap sono anche nell'heap, allora il GC può fare il suo lavoro giusto. Che casino, hehe! Grazie per il chiarimento! – Tiago