error de falta de memoria, es culpa de mi aplicación?

Question

tengo una aplicación en el mercado de Android, en la que excepciones y errores son atrapados y enviados por acra.

pero recibo un buen montón de errores de memoria .. en diferentes tipos de clases ... algunos mi aplicación, algunos de Java en general ..

qué siempre significa que hay un problema en mi aplicación, o también puede ser que el teléfono se quedó sin memoria debido a otro proceso?

¿Los usuarios también recibirán un cuadro de diálogo de fc?

Información adicional

No hay nada Intensite memoria en mi aplicación ..

hay imágenes ... no hay grandes cantidades de datos .. solamente una sencilla view..and más intensa una Mobclix anuncio ...

soy nuevo en java ... así que puedo tener una fuga en alguna parte ... pero me resulta difícil de depurar eso. Pero en este punto, ni siquiera estoy seguro de que haya algo incorrecto ...

obtengo unos 25 -50 errores OOM diarios ... pero en comparación con 60,000 anuncios, se muestra un día. (muestro solo 1 o 2 anuncios por cada vez que se inicia) que no es demasiado.

1 recibe errores como:

"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) 

"

Así que la pregunta principal is..am i fugas en algún lugar .. o puede esto se considera normal porque en un pequeño% de los casos, el teléfono puede estar sin memoria debido a otras aplicaciones que se ejecutan en él.

Answer 1

Hay cosas que pueden estar fuera de tu control (la memoria en el teléfono es un ejemplo) pero, no obstante, eres responsable del comportamiento de tu aplicación.

La forma en que maneje los problemas de memoria influirá en la forma en que los usuarios vean su aplicación. Si funciona bien con otras aplicaciones, es más probable que los usuarios lo usen. Si no lo hace, no lo harán.

Answer 2

¿Qué quiere decir con excepciones de "java general" y si estas no están relacionadas con su software, entonces por qué las está recibiendo?

Como probablemente sepa, la máquina virtual Dalvik solo tiene una pequeña cantidad de memoria asignada a sí misma (y a su aplicación). Esto se implementa de esta manera para evitar la posibilidad de que un proceso crezca fuera de control y agote todos los recursos disponibles, haciendo que el teléfono no se pueda utilizar. Por lo tanto, si la aplicación realiza muchas operaciones de memoria intensiva (como cargar imágenes) y no tiene cuidado con sus asignaciones (y las borra tan pronto como no las necesite), se pueden observar resultados extraños.

Acerca del cierre forzado, ya que está detectando estas excepciones, no deberían causar un bloqueo de su aplicación, a menos que haya olvidado volver a crear una instancia después de haber capturado una excepción.

Tal vez sea útil la inspección de su código y la eliminación de las asignaciones de memoria innecesarias. Además, se puede probar que mi jefe hace - él simplemente se asusta apretar botones al azar hasta que algo se bloquea: D

EDITAR

Dado que usted dice que la memoria es nada caro en su código (sans los anuncios Probablemente), entonces puede hacer una simple comprobación para ver si todo el sistema tiene poca memoria cuando ocurre el error, o es su aplicación la que lo causa. Eche un vistazo a la devolución de llamada onLowMemory. Se invoca cuando todo el teléfono tiene poca memoria.

Answer 3

¿Ha utilizado el seguidor de asignación en DDMS? Podría ayudarlo a encontrar pérdidas de memoria inesperadas. http://developer.android.com/resources/articles/track-mem.html (no he utilizado yo mismo, aunque hasta el momento)

Answer 4

Como sugirió Thomas, que realmente quieren usar las DDM que mirar a su uso de la memoria.

Además, un problema muy común para las fugas es el uso de variables estáticas; úsalas solo si sabes lo que estás haciendo.

Manejar bitmaps también puede ser muy costoso para Android. ¿Qué hace tu aplicación? Además, ¿tiene muchas referencias a elementos de UI? ¿Alguno definido como estático?

Answer 5

Cuando obtiene OutOfMemoryError, puede estar seguro de que es su aplicación y no otra que lo causa. Cada aplicación de Android se ejecuta en su propia VM Dalvik con 16Mb de asignación máxima de memoria.

Si no utiliza mapas de bits (que son una fuente frecuente de pérdidas de memoria), también debe comprobar si maneja correctamente los cambios de orientación, es decir, sin guardar en la memoria ninguna referencia a un objeto relativo a la interfaz de usuario.

Answer 6

Un problema común de JVM es que el Garbage Collector solo puede eliminar objetos sin referencia. Si tiene grandes objetos persistentes, entonces es importante establecer las variables no utilizadas en esos objetos a nulo para que se eliminen las referencias. Un problema clásico es mantener algo como un objeto HashMap con muchos valores cuando no lo necesita, ya que cada entrada en el HashMap está masticando la memoria.