errore di memoria insufficiente, errore della mia app?

Question

ho un'applicazione sul mercato Android, in cui eccezioni e errori vengono catturati e inviati a me da acra.

Ma ricevo un sacco di errori di memoria .. in diversi tipi di classi ... un po 'la mia app, un po' di java generale ..

significa sempre che c'è un problema nella mia app, o può anche essere il telefono a corto di memoria a causa di un altro processo?

Gli utenti riceveranno anche una finestra di dialogo fc?

Informazioni aggiuntive

Non c'è nulla di memoria intensite nella mia app ..

senza immagini ... non grandi quantità di dati .. solo un semplice view..and più intensa una Mobclix annuncio ..

sono nuovo di java ... quindi potrei avere una perdita da qualche parte..ma faccio fatica a fare il debug. Ma a questo punto non sono nemmeno sicuro che ci sia qualcosa di sbagliato ...

ottengo circa 25 -50 errori OOM giornalieri..ma rispetto a 60.000 annunci mostra un giorno. (mostro solo 1 o 2 annunci per ogni volta che viene avviato) che non è troppo.

1 ricevono errori come:

"java.lang.OutOfMemoryError 
at org.apache.http.impl.io.AbstractSessionInputBuffer.init(AbstractSessionInputBuffer.java:79) 
at org.apache.http.impl.io.SocketInputBuffer.<init>(SocketInputBuffer.java:93) 
at android.net.http.AndroidHttpClientConnection.bind(AndroidHttpClientConnection.java:114) 
at android.net.http.HttpConnection.openConnection(HttpConnection.java:61) 
at android.net.http.Connection.openHttpConnection(Connection.java:378) 
at android.net.http.Connection.processRequests(Connection.java:237) 
at android.net.http.ConnectionThread.run(ConnectionThread.java:125) 

"

"java.lang.OutOfMemoryError 
at java.io.BufferedReader.<init>(BufferedReader.java:102) 
at com.mobclix.android.sdk.Mobclix$FetchResponseThread.run(Mobclix.java:1422) 
at com.mobclix.android.sdk.MobclixAdView$FetchAdResponseThread.run(MobclixAdView.java:390) 
at java.util.Timer$TimerImpl.run(Timer.java:290) 

"

"java.lang.OutOfMemoryError 
at org.apache.http.util.ByteArrayBuffer.<init>(ByteArrayBuffer.java:53) 
at org.apache.http.impl.io.AbstractSessionOutputBuffer.init(AbstractSessionOutputBuffer.java:77) 
at org.apache.http.impl.io.SocketOutputBuffer.<init>(SocketOutputBuffer.java:76) 
at android.net.http.AndroidHttpClientConnection.bind(AndroidHttpClientConnection.java:115) 
at android.net.http.HttpConnection.openConnection(HttpConnection.java:61) 
at android.net.http.Connection.openHttpConnection(Connection.java:378) 
at android.net.http.Connection.processRequests(Connection.java:237) 
at android.net.http.ConnectionThread.run(ConnectionThread.java:125) 

"

Quindi la principale is..am domanda che perde da qualche parte .. o can questo è da considerarsi normale perché in una piccola percentuale dei casi il telefono potrebbe avere esaurito la memoria a causa di altre applicazioni in esecuzione su di esso.

Answer 1

Ci sono cose che possono essere fuori dal tuo controllo (la memoria del telefono è un esempio) ma comunque sei responsabile del comportamento della tua applicazione.

Il modo in cui gestisci i problemi di memoria influenzerà il modo in cui gli utenti visualizzano la tua applicazione. Se funziona bene con altre applicazioni, gli utenti saranno più propensi a usarlo. Se non lo fa, non lo faranno.

Answer 2

Cosa intendi con le eccezioni "general java" e se queste non sono correlate al tuo software, perché le stai ricevendo?

Come probabilmente saprete, la macchina virtuale Dalvik ha solo una piccola quantità di memoria assegnata a se stessa (e alla vostra applicazione). Questo è implementato in questo modo per evitare la possibilità che un processo diventi incontrollabile e prosciughi tutte le risorse disponibili, rendendo il telefono inutilizzabile. Quindi, se la tua applicazione sta eseguendo molte operazioni a uso intensivo della memoria (come il caricamento delle immagini) e non stai attento con le tue allocazioni (e cancellandole non appena non sono necessarie), allora si possono osservare risultati bizzarri.

Informazioni sulla chiusura della forza, dal momento che si stanno verificando queste eccezioni, non dovrebbero causare un arresto anomalo dell'applicazione, a meno che non si sia dimenticato di ripetere l'istanza di qualcosa dopo aver rilevato un'eccezione.

Forse l'ispezione del codice e l'eliminazione delle allocazioni di memoria non necessarie saranno utili. Inoltre, è possibile verificare come il mio capo fa - ha appena spaventa di premere i tasti a caso fino a quando qualcosa si blocca: D

EDIT

Dal momento che si dice che non c'è memoria nulla costoso nel codice (sans le annunci probabilmente), quindi è possibile effettuare un semplice controllo per vedere se l'intero sistema è in esaurimento di memoria quando si verifica l'errore, oppure è l'applicazione che lo causa. Dai un'occhiata al callback onLowMemory. Viene chiamato quando l'intero telefono ha poca memoria.

Answer 3

Avete utilizzato il tracker di allocazione in DDMS? Potrebbe aiutarti a trovare perdite di memoria impreviste. http://developer.android.com/resources/articles/track-mem.html (Non ho usato io stesso finora però)

Answer 4

Come suggerito Thomas, davvero si vuole utilizzare il DDMS di guardare il vostro uso della memoria.

Inoltre, un problema molto comune la presenza di perdite è l'uso di variabili statiche - usarle solo se si sa cosa si sta facendo.

La gestione di bitmap può anche diventare molto costosa su Android. Cosa fa la tua app? Inoltre, hai molti riferimenti a qualsiasi elemento dell'interfaccia utente? Qualcuno definito come statico?

Answer 5

Quando si arriva OutOfMemoryError, si può essere sicuri che è la vostra applicazione e non un altro che lo causa. Ogni app per Android viene eseguita nel proprio Dalvik VM con 16 MB di memoria massima allocata.

Se non si utilizzano bitmap (che sono una fonte frequente di perdite di memoria), è inoltre necessario controllare se si gestiscono correttamente le modifiche di orientamento, ovvero senza tenere in memoria alcun riferimento a un oggetto relativo all'interfaccia utente.

Answer 6

Un problema comune JVM è che soltanto gli oggetti senza riferimenti possono essere rimossi dal garbage collector. Se si dispone di oggetti persistenti di grandi dimensioni, è importante impostare le variabili non utilizzate in tali oggetti su null in modo che vengano omesse. Un classico problema è mantenere qualcosa come un oggetto HashMap con molti valori al suo interno quando non ne hai bisogno, dal momento che ogni voce in HashMap sta masticando memoria.