java - tengo - Clueless sobre una(posible) pérdida de memoria de Android

memoria interna llena y no tengo nada

Question

He estado enfrentando algunos OutOfMemoryErrors molestos, incluso después de asegurarme de que todos mis mapas de bits estén correctamente escalados, etc. De hecho, el problema no parece estar relacionado con los mapas de bits en absoluto, pero puedo estar equivocado.

Para propósitos de prueba y aislamiento de errores, he estado cambiando entre dos actividades (llamémoslas Main y List) usando mi cajón de navegación (sin usar el botón Atrás). Puedo ver en el DDMS que la memoria asignada aumenta alrededor de 180 KB cada vez que regreso.

Hice volcados de memoria y utilicé eclipse MAT para analizar 3 puntos diferentes en el tiempo:

Sospecho una pérdida de memoria, pero realmente no puedo averiguar su causa. De acuerdo con los volcados de memoria, parece que es el "Resto" y java.lang.FinalizerReference que siguen aumentando. El usuario en esta pregunta también tiene muchas FinalizerReferences en su volcado de memoria, pero la respuesta no es muy clara.

El informe de sospechosos de fugas que realicé en el último momento no es muy útil, ya que sospecha de android.content.res.Resources y android.graphics.Bitmap que no parecen estar creciendo con el tiempo:

En uno de los informes (lamentablemente, no está aquí) he visto 13 instancias de android.widget.ListView señalado como un posible sospechoso de fuga.

Estos aumentos de memoria ocurren con cualquier transición entre actividades (no solo la lista principal y la lista que usé en este ejemplo).

¿Cómo puedo encontrar la pérdida de memoria (no obvia)? He estado rascándome la cabeza durante mucho tiempo, por lo que cualquier ayuda y consejos serían excelentes.

EDITAR:

• Mapas de bits (@ OrhanC1): He comentado algunas instancias de mapas de Bitmap en las dos actividades mencionadas anteriormente y la memoria sigue aumentando. El volcado de memoria todavía muestra algunos mapas de bits, pero creo que están relacionados con los recursos y no con los mapas de bits reales asignados por mí.

• Respecto a las fuentes personalizadas (@erakitin): las estoy usando, pero mantengo una única instancia de cada tipo de Typeface en el contexto de mi Application ( public class MyApp extends Application ) usando un singleton. He intentado comentar cualquier referencia a las fuentes en las dos actividades mencionadas anteriormente y la memoria sigue aumentando.

• No creo que esté filtrando el Context (@DigCamara): no tengo ninguna referencia estática dentro de estas dos actividades, estoy usando el contexto de la Application lugar de las Activity , excepto en un adaptador. Si me quedo en la misma Activity y hago algunas rotaciones de pantalla, la memoria no aumenta.

• Basado en el comentario de @NickT: Puedo ver que tengo muchos ejemplos de ambas actividades. ¿Es posible que estos aumentos de memoria sean simplemente el resultado de un aumento en el número de actividades de la pila trasera y no una pérdida de memoria (creo que el sistema operativo se ocupó de eso, al parecer no )? Si uso el FLAG_ACTIVITY_REORDER_TO_FRONT intento FLAG_ACTIVITY_REORDER_TO_FRONT , entonces la memoria solo aumenta hasta que todas las actividades diferentes se hayan instanciado (una vez). Útil para este asunto: Android no mata las actividades de la pila cuando la memoria es baja .

Answer 1

Parece que la razón por la que el Remainder está creciendo es el crecimiento del número de instancias de la Activity en la pila trasera (por ejemplo, 13 instancias de la Activity "Lista" + 13 instancias de la Activity "Principal").

He cambiado el cajón de navegación para que cuando el usuario haga clic en el botón "Inicio" (que lo lleva al "Panel de Intent.FLAG_ACTIVITY_REORDER_TO_FRONT | Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_NEW_TASK " de la aplicación), establezca la Intent.FLAG_ACTIVITY_REORDER_TO_FRONT | Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_NEW_TASK Intent.FLAG_ACTIVITY_REORDER_TO_FRONT | Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_NEW_TASK Intent.FLAG_ACTIVITY_REORDER_TO_FRONT | Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_NEW_TASK : la Actividad se reutiliza y la pila trasera se borra ( según lo recomendado por las directrices de Android, en realidad ). De hecho, ya debería haber hecho esto, ya que no quiero que se creen varias instancias de la actividad del Tablero ("Inicio").

Al hacer esto, puedo ver que las Actividades se destruyen y el tamaño del montón asignado (incluida la porción " Remaining ") disminuye:

Mientras solucionaba esto, también noté que una de mis Actividades y un Mapa de bits utilizado por ella no se estaban destruyendo, incluso si la pila trasera había sido borrada (fuga). Después de analizar con MAT, llegué a la conclusión de que la fuente de este subproblema era una referencia a un ImageView que ImageView en la Activity . Al agregar este código al método onStop() , logré que tanto la actividad como el Bitmap de Bitmap se destruyeran:

@Override
protected void onStop() {
super.onStop();
ImageView myImage = (ImageView) findViewById(R.id.myImage );
if(myImage .getDrawable() != null)
myImage.getDrawable().setCallback(null);
RoundedImageView roundImage = (RoundedImageView) findViewById(R.id.roundImage); // a custom View
if(roundImage.getDrawable() != null)
roundImage.getDrawable().setCallback(null);
}

Luego generalicé toda mi Activity y FragmentActivity para que llamen unbindDrawables(View view) en onDestroy() :

private void unbindDrawables(View view)
{
if (view.getBackground() != null)
{
view.getBackground().setCallback(null);
}
if (view instanceof ViewGroup && !(view instanceof AdapterView))
{
for (int i = 0; i < ((ViewGroup) view).getChildCount(); i++)
{
unbindDrawables(((ViewGroup) view).getChildAt(i));
}
((ViewGroup) view).removeAllViews();
}
}

Gracias a @NickT por señalarme en la dirección correcta.