GC_FOR_ALLOC es más "serio" al investigar el uso de la memoria?

Actualmente estoy investigando los problemas de recolección de basura con mi aplicación de Android, y tengo curiosidad de saber si GC_FOR_ALLOC es indicativo de un problema mayor que otros mensajes de GC, como GC_CONCURRENT.

Desde mi entendimiento, GC_CONCURRENT está haciendo lo que el recolector de basura debería hacer. El montón ha alcanzado un límite determinado, mejor ir a limpiar la memoria.

GC_FOR_ALLOC me sugiere que algo más grave está sucediendo si estoy tratando de crear un objeto y no queda memoria para hacerlo.

¿Hay un nivel de prioridad o "gravedad" para los mensajes del GC?

En cierto sentido, GC_FOR_ALLOC es más grave que GC_CONCURRENT , porque GC_FOR_ALLOC significa que no había suficiente memoria libre para cumplir con una solicitud de asignación, por lo que una recolección de basura era necesario, mientras que GC_CONCURRENT sólo significa que el GC sentía como correr, por lo general porque la cantidad de La memoria se hizo inferior a un determinado umbral después de una asignación.

Un GC_FOR_ALLOC por sí solo no es un signo de un problema en su aplicación sin embargo:

  • Las aplicaciones de Android empiezan con un pequeño montón que crece (hasta un punto) cuando las aplicaciones requieren más y más memoria, y un GC_FOR_ALLOC se realiza antes de aumentar el tamaño del montón. En este caso, GC_FOR_ALLOC es perfectamente normal.
  • Si asigna memoria más rápido que el GC concurrente tiene tiempo para liberarlo, GC_FOR_ALLOC es inevitable. Y no hay nada inherentemente mal con la asignación de memoria más rápido que el GC concurrente puede liberar memoria.

Un tipo más grave de GC en Android es GC_BEFORE_OOM , que se realiza cuando una solicitud de asignación falla incluso después de GC_FOR_ALLOC y cuando el montón de aplicaciones ha crecido tan grande como se le permite ser. Cuando esto ocurra, como último recurso, Dalvik intentará liberar SoftReferences también, antes de hacer un intento final de asignar memoria y si falla lanzará una excepción OutOfMemory.

Si tiene curiosidad por ver el código de esta lógica, está en tryMalloc() en dalvik.git / vm / alloc / Heap.cpp

De todos modos, si no te importa, dudo que mirar la salida logcat sea la manera más eficiente de depurar tus problemas de recolección de basura. No sé qué problema específico tiene, pero ¿ha estudiado herramientas como el Asocation Tracker en DDMS y ha analizado los volcados de montón con la ayuda de la herramienta hprof-conv ? (Ver http://android-developers.blogspot.se/2011/03/memory-analysis-for-android.html por ejemplo para empezar.)

  • Recogida de basura GridView de Android (GC_EXTERNAL_ALLOC) <1K excesivamente, causando una interfaz de usuario muy intermitente
  • El recolector de basura de Android trabaja duro en mi aplicación
  • Formatea una dirección MAC en Android / Java sin crear basura innecesaria
  • Problemas con la recolección de basura y Picasso
  • Android - Bitmap y gestión de la memoria?
  • ¿Cómo encontrar el origen de un GC_FOR_MALLOC?
  • Android GC - LogCat siempre muestra actividad de GC
  • Obtener la lista de procesos en ejecución y eliminar sus servicios de fondo
  • Consideraciones del GC de Android: ¿cuándo se ejecuta el GC y se puede rastrear su estado de ejecución desde el código?
  • El servicio detenido está haciendo la recolección de basura constante
  • La interfaz de usuario de aplicación se congela con mensajes de GC
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.