2012-05-18 12 views
5

Aquí es una pieza de código simplificado:¿Es esto una fuga de contexto de Android?

static Activity longLivedField; 

onCreate(...) {  
    longLivedField = this; // the only write to this field 
} 

He visto personas que dicen esto como una pérdida de contexto, y crear soluciones para ello. La solución típica es anular el campo en los lugares apropiados. Por ejemplo, en onPause():

onPause() { 
    longLivedField = null; 
} 
+0

haces esto para mantener contexto? – accordionfolder

+0

Sí. Y hay sugerencias que dicen que no deberíamos hacer esto, pero en su lugar usa getApplicationContext(). Pero solo quiero entender por qué hacer esto podría ser un problema. – dacongy

Respuesta

3

Sí, es una pérdida de memoria si no anular el campo en onPause(). Es casi seguro que nunca desea conservar una referencia estática a ninguna actividad. ¿Qué es lo que estás tratando de lograr?

El sitio web de desarrollador de Android contiene una página muy útil que describe cómo evitar pérdidas de memoria como éste:

Avoiding Memory Leaks

+0

Lo leí antes, varias veces. La diferencia, sin embargo, es que el campo estático solo se escribe una vez en ese ejemplo. Pero en este caso, el campo estático se escribiría cada vez que se crea un nuevo objeto de actividad (bueno, cuando onCreate() se llama en realidad), y por lo tanto, el anterior (el que se supone que se * filtró) no es más alcanzable desde el campo estático. Por lo tanto, parece que solo puede estar goteando durante un corto período de tiempo, lo que, en términos generales, es entre onPause() y la asignación en onCreate(). – dacongy

+2

Eso es cierto, pero la fuga ocurrirá cuando el usuario se mueva a una actividad diferente. El campo estático apuntará a la última instancia de tu actividad y, por lo tanto, se filtrará. –

+1

Aquí está mi entendimiento en función de sus respuestas, y corríjanme si me equivoco: el objetivo es hacer posible que la basura recopile la última instancia de actividad cuando el usuario se mueve a una actividad diferente. Es importante hacerlo porque toda la jerarquía de la GUI de una actividad (quiero decir esto explícitamente porque las filtraciones en actividades múltiples o incluso múltiples aplicaciones son obviamente perjudiciales) podría consumir una cantidad bastante considerable de memoria. Es razonable hacerlo porque la recolección de basura y la asignación de objetos son lo suficientemente eficientes como para recopilar y asignar la jerarquía de la GUI con bastante rapidez. – dacongy

Cuestiones relacionadas