Android: consumo della memoria di gioco LibGDX 2D

Question

Sto affrontando alcuni problemi con il consumo di memoria durante lo sviluppo di giochi 2D usando libGDX.

È un gioco 2D con un ricco contenuto grafico: ci sono molte trame, animazioni, font, ecc. Ho testato l'allocazione di memoria (nativo & heap) su dispositivi diversi ed ho ottenuto risultati diversi: (Ho diviso tutti i dispositivi per i gruppi da texture dimensioni)

Gruppo 1 (texture adottati per ~ 840 * 480 schermi)

HTC Desire (Froyo): 178Mb (nativo) - 12Mb (heap) - applicazione carica con successo

HTC One V (ICS): 30Mb (nativo) - 12Mb (heap) - applicazione carica con successo

HTC Desire S (Jelly Bean): 30Mb (nativo) - 12Mb (heap) - carichi applicazione con successo

Gruppo 2 (texture adottata per ~ 1366 * 768 schermi)

Samsung (Google) Galaxy Nexus 329Mb (nativo) - 18M b (heap) - funziona perfettamente

Galaxy TAB (Honeycomb) 164Mb (nativo) - 10Mb (heap) - applicazione va in crash (Surface.OutOfResouresException).

Penso che ci possano essere delle differenze significative nella gestione della memoria su tutte le versioni di Android, il che mi porta questi problemi.

Qualcuno può spiegare cosa succede esattamente durante il caricamento di trame su Android 3.x? O magari postare alcuni collegamenti per capire che cosa è necessario fare per risolvere questo problema.

qualche aggiornamento

Toady avevo fatto alcuni test supplementari su emulatori 3.x (so che questo non è il modo migliore, ma i registri era simile a emu e Galaxy Tab prima)

1. Ho eseguito il gioco con texture adottate per 1024 * 600: l'app si blocca su risorse di caricamento dell'80% (158 allocazione memoria nativa)
2. Con trame per 800 * 480 - Arresto anomalo dell'app su caricamento 100% (allocazione memoria nativa 145 Mb)

Infine, ho eseguito l'applicazione sul nuovo tablet Google Nexus (Jelly Bean) che utilizza le stesse texture di 3.x compresse (1280 * 800px) - ~ 30 Mb di memoria nativa e ~ 12 Mb di vm heap.

Ora mi perdo completamente la comprensione di quello che sta succedendo - stessa allocazione di memoria per le texture 800 * 480 e 1280 * 800 ...

FINALMENTE

io siamo stati risolvere questa situazione utilizzando le risorse di carico su domanda con qualche barra di progresso. Dopo tutti gli tentativi, non ho trovato un altro modo.

Answer 1

Se ti stai chiedendo perché Android 3 si blocca più di 2.X, è a causa di un bug ByteBuffer. ByteBuffer usa 4 volte la memoria. Quindi, è necessario utilizzare le immagini res inferiori per Android 3. Ciò è stato risolto in Android 4.

http://code.google.com/p/android/issues/detail?id=16941

Fortunatamente per Android 3+ si ha la possibilità mucchio di grandi dimensioni (circa 128+ dà mega), che è quello che ho ha dovuto accendere la nostra app.

Answer 2

Credo che l'utilizzo della memoria di runtime di una bitmap possa aumentare se il formato della bitmap non corrisponde al formato del display (il sistema finirà per creare una copia con il formato corretto da utilizzare). Penso che questo sia più un problema sui vecchi sistemi Android, e probabilmente non è quello che vedi 3.0, ma potrebbe valere la pena di essere esaminato. (Vedere il bit Prestazioni alla fine di Romain's post here)

Conteggio della memoria per gli array di byte sottostanti bitmap modificati in 3.0 (Honeycomb), la memoria spostata dal lato nativo all'heap Java. Tuttavia, questo ha appena spostato la memoria in giro, e non avrebbe dovuto influire sui limiti effettivi (la memoria nativa era ancora contabilizzata rispetto allo stesso limite, semplicemente non era visibile ad alcuni strumenti).

Il limite di heap è diverso anche su dispositivi diversi. (Vedere Android heap size on different phones/devices and OS versions)

Questo/O Google I discorsi copre un po 'di problemi intorno cambiamenti di gestione della memoria in 3.0 che potrebbero essere utili: http://dubroy.com/blog/google-io-memory-management-for-android-apps/

È possibile load a scaled-down version dei tuoi bitmap su dispositivi di memoria inferiore. Probabilmente vale la pena leggere anche il resto dello http://developer.android.com/training/displaying-bitmaps/index.html.

Quanti dati di immagini su disco sono presenti nell'applicazione? Quanto sono grandi gli altri dati non immagine che stai caricando (font, animazioni, ecc.)?