2012-11-10 4 views
11

Gente, io non credo che si tratta di un duplicato e non è uno di quelli Come evitare Ooms domande. Si tratta di una vera e propria ricerca della conoscenza in modo da tenere fuori coloro giù voti per favore ...Perché Android allocare più memoria del necessario durante il caricamento di immagini

Immaginate Ho un JPEG di 500x500 pixel. Lo carico come ARGB_8888 che è come "bad as it gets".

mi aspetterei Android per allocare 500x500x4 bytes = a little under 1MB però, guarda un cumulo discarica e vedrete che Android assegna un numero significativamente maggiore, spesso fattori di 5-10 volte maggiore.

È frequente vedere domande su qui circa OOMS in cui la traccia dello stack mostra un heap request of say 15MB ed è sempre molto più grande è necessario semplicemente per contenere i byte dell'immagine. L'OP di solito registra alcuni downvotes, quindi è bombardato da risposte e commenti sull'utilizzo di meno memoria (grazie a Romain!) E sul ridimensionamento. Penso che ci sia più di quanto possa sembrare qui.

Qualcuno sa perché questo è?

Se non c'è una risposta apparente, creerò un SSCCE se aiuta.

PS. Suppongo che JPEG vs PNG ecc. Sia irrilevante dal momento che stiamo parlando dell'utilizzo della memoria del bitmap di supporto che è semplicemente x volte y volte BPP - o sto rallentando?

+4

Sei sicuro che non stai causando il ridimensionamento dell'immagine in base a come la si applica (ad esempio, caricandola in un 'ImageView' che non ha le stesse dimensioni)? Inoltre, quando hai guardato la tua discarica di heap, dovresti vedere esattamente dove sono andati i "fattori di 5-10 volte maggiori" - dove hai visto quei valori finire? "Metterò insieme un SSCCE se aiuta" - per favore. – CommonsWare

+0

Ah. Sembra che potrei essere lento. Lasciatemi provare un esempio e tornare indietro se e quando scoprirò che non viene ridimensionato se applicato. Grazie – Simon

+0

Stranamente, il ragazzo in [questa domanda] (http://stackoverflow.com/questions/4866653/read-in-jpg-as-rgb888-on-android) * vuole * e ARGB8888, ma continua a ottenere un RGB565 . Forse puoi usare il suo metodo? – GolezTrol

risposta

1

Un tempo era un trucco abbastanza comune con la gestione della memoria per catturare un pool o un blocco di memoria suddiviso in richieste più piccole. Quando lavoravo con i sistemi embedded, era prassi comune mantenere pool di memoria di dimensioni diverse e abbiamo appena assegnato un blocco più grande della quantità richiesta da un pool. È un modo conveniente per evitare troppa frammentazione della memoria. Forse sta succedendo qui.

Problemi correlati