¿Cómo encontrar la raíz de fugas de memoria?

Mi aplicación es básicamente y editor de imágenes. Hay una página de bienvenida que abre la actividad principal con una intención. Si la orientación cambia cuando la actividad principal está funcionando, el consumo de memoria simplemente se duplica y permanece así. Si cierro la actividad principal vuelvo a la actividad de bienvenida y comienzo actividad principal de nuevo el mismo problema no se produce. Creo que todo esto indica fugas de memoria, he investigado a mí mismo, pero no pude encontrar por qué la aplicación es la fuga de memoria. Estoy utilizando contextos de aplicación y no hay campo estático en mi aplicación. He tratado de volcar montón y analizar con MAT, sin embargo no pude encontrar nada bueno. Esperaba que alguien pudiera mostrarme la dirección correcta para encontrar las raíces de la pérdida de memoria u otra posible explicación del problema.

Recuerde que en una JVM (e incluso en una I-can-t-believe-it-no-a-JVM como Davlik) hay muchos elementos que usted utiliza que no están exactamente bajo su control. Por lo tanto, el enfoque correcto es encontrar una manera de verificar que su código no tiene fugas de memoria y, a continuación, sabrá que si la memoria florece, es probable que algún subsistema externo, o alguna consecuencia prevista de las necesidades reales de memoria de la aplicación.

A partir de su descripción, podría ser fácilmente que la representación de pantalla es simplemente mantener un búfer de memoria caché perezoso construido para cada orientación de pantalla.

Sólo menciono esto porque ya has comparado los volcados de montón, y si los montones no muestran una tendencia en la acumulación de objetos, es probable que se incluya algún elemento dentro de una implementación de biblioteca. Sé que esto es una regla muy general, y no se aplica a la mayoría de los programas (ya que probablemente contienen verdaderas fugas de memoria), pero es algo que podría ser investigado cuando se agotan otras opciones.

Si realmente desea verificar que una biblioteca en particular está manteniendo una copia en caché de la orientación de la pantalla, siempre puede escribir un pequeño "test" del programa que está faltando todos los factores de confusión (como el resto de su programa) y ver cómo Se realiza en los cambios de orientación de la pantalla.

En cuanto a la utilización de VisualVM, es excelente para detectar fugas de memoria del espacio del usuario; Sin embargo, como se está ejecutando en una arquitectura diferente y la implementación, puede perder problemas de biblioteca de plataforma específica.

Este escenario específico fue cubierto en una presentación de la conferencia Google I | O 2011 . Recomiendo observar la presentación, ya que puede ayudarle a encontrar mejor su problema usando MAT.

Mi aplicación estaba sufriendo de una fuga mala, y mientras que encontré la herramienta de la MAT útil, encontré que la causa principal era mi no que manejaba la pila de la actividad correctamente. Creo que la forma más útil de comprobar esto era desde la línea de comandos usando:

Adb shell dumpsys meminfo su.package.name

Obtendrá una salida como

adb shell dumpsys meminfo your.package.name Currently running services: meminfo ------------------------------------------------------------------------------- DUMP OF SERVICE meminfo: Applications Memory Usage (kB): Uptime: 150876 Realtime: 150875 ** MEMINFO in pid 253 [your.package.name] ** native dalvik other total size: 5404 4103 N/A 9507 allocated: 5294 3110 N/A 8404 free: 101 993 N/A 1094 (Pss): 2346 3737 2198 8281 (shared dirty): 1964 4644 1480 8088 (priv dirty): 2204 1856 956 5016 Objects Views: 30 ViewRoots: 2 AppContexts: 3 Activities: 2 Assets: 2 AssetManagers: 2 Local Binders: 13 Proxy Binders: 16 Death Recipients: 2 OpenSSL Sockets: 0 SQL heap: 0 dbFiles: 0 numPagers: 0 inactivePageKB: 0 activePageKB: 0 

Compruebe el conteo de actividades y observe cómo cambia el tamaño del montón a medida que cambia las orientaciones, etc. Asegúrese de que no está iniciando copias de actividades ya en ejecución. Usted puede controlar la pila con las banderas que usted da a la intención en comenzar una actividad.

VisualVM http://visualvm.java.net/
Está en la distribución de JDK desde alguna versión de 1.6

Si su aplicación es un editor de imágenes y está viendo este tipo de comportamiento, espero que no esté reciclando la memoria Bitmap (consulte http://developer.android.com/reference/android/graphics/Bitmap.html#recycle% 28% 29 ).

Cuando su orientación cambia y la actividad se destruye, tendrá que localizar cualquier Bitmaps grande en uso por sus vistas y, a continuación, o recycle llamada en ellos o utilizar el método onRetainNonConfigurationInstance (consulte http://developer.android.com/reference/android/ App / Activity.html # onRetainNonConfigurationInstance% 28% 29 ) para pasarlo a la nueva instancia de Activity.

  • Android: libera recursos de memoria de mapa de bits de forma programática
  • Creación de una carpeta en la memoria interna para guardar archivos y recuperarlos más tarde
  • El servidor NanoHttpd no puede transmitir videos grandes en android
  • Android: Fuera de error de memoria
  • Android Context Memory Leak ListView debido a AudioManager
  • Fugas de contexto de Android en AsyncTask
  • Eclipse - diseñador de GUI Android increíblemente lento y con mucha memoria
  • Android: ¿Cuánta memoria utiliza mi aplicación?
  • Android - comprimir mapa de bits antes de guardarlo en SDCARD en actividad para obtener resultados
  • Fuera de la memoria Picasso Lib
  • Cómo limpiar los recursos de mapa de bits
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.