Android: campos estáticos y fugas de memoria

Question

He estado estudiando las mejores prácticas para evitar fugas de memoria de contexto/actividad al crear vistas, y parece que no puedo encontrar una respuesta definitiva sobre lo que está o no permitido cuando llega a los campos estáticos en las clases.

Digamos que tengo un código de esta forma:

public class MyOuterClass extends Activity{ 
    private MyInnerClass; 
    MyInnerClass = (MyInnerClass) findViewById(<XML call here>); 
    MyInnerClass.myXInt = 3; 

    // onCreate(), onResume(), etc. 

    public static class MyInnerClass extends SurfaceView implements Runnable{ 
     // Safe variables? 
     private static int myXInt, myYInt; 
     private static boolean myBoolean; 
     // Potentially safe? 
     private static Canvas myCanvas; 
     // Definitely bad. 
     private static Context myContext; 

     public MyInnerClass(Context context){ 
     myContext = context;  // This is bad. 
     } 
    } 
} 

Estoy un poco confundido sobre lo que la JVM en realidad considera que el cargador de clases para MyInnerClass. Técnicamente, dado que es un objeto SurfaceView, parece que las variables estáticas siempre deben existir una vez que la aplicación ha instanciado MyInnerClass una vez (lo que sucede cuando la vista se infló por primera vez), y luego permanecer allí hasta que la aplicación se termine. Si ese es el caso, ¿qué impide que los objetos Bitmaps y Canvas permanezcan abiertos y llenen el montón?

La única afirmación que veo repetida una y otra vez es que no se puede filtrar Contexto estático como el que he mostrado en el constructor, pero nunca va más allá. ¿Es eso realmente lo único que no puedes hacer?

Answer 1

En Java/Android no se recogerá basura static variable o constante. Simplemente permanece allí una vez que la clase que lo contiene se carga a través de un cargador de clases. El cargador de clases es afaik siempre el mismo para todas las clases dentro de su aplicación y es el que tiene referencias estáticas a todas sus clases (por ejemplo, MyInnerClass.class). Como el cargador de clases no desaparece, tus clases tampoco lo harán, ya que están referenciadas como & y, por lo tanto, no son recolectables.

Al igual que en el ejemplo

public class SomeClass extends SurfaceView { 
    private static Context myContext; 

    public MyInnerClass(Context context){ 
    myContext = context;  // This is bad. 
    } 
} 

Eso es de hecho mal. Incluso si no existe ninguna referencia a SomeClass (por ejemplo, el Activity que mostró que su SurfaceView personalizado ha finalizado) la referencia estática al Context (y cualquier otra variable static/constante en SomeClass se mantendrá. Puede considerar que todos se han filtrado ya que no es posible a la basura recolectar ese Context etc. Si tiene una referencia de variable regular algo, una vez que la instancia que contiene esa variable no tiene más referencias, la instancia completa incluyendo sus referencias a otras cosas puede ser recolectada. JAV incluso puede manejar circular referencias finas.

Para las constantes que desee que suceda y generalmente no está mal, ya que la cantidad de constantes y la cantidad de memoria que ocupan no es grande. Las constantes tampoco (no deberían) referencia otras instancias que ocupan grandes cantidades de memoria como Context o Bitmap.

Además de la posibilidad de crear pérdidas de memoria a través de variables estáticas, también puede crear problemas si no desea tener una sola cosa para todas las instancias al mismo tiempo. Por ejemplo, si guarda el Bitmap de su SurfaceView en una variable static, no puede tener dos imágenes diferentes. Incluso si los dos SurfaceView s no se muestran al mismo tiempo, podría tener problemas ya que cada nueva instancia probablemente sobrescribirá la imagen anterior y si vuelve a la otra SurfaceView, inesperadamente muestra una imagen incorrecta. Estoy casi seguro de que no quiere usar static aquí.

El hecho de que su clase interna sea static class no significa que tenga que usar variables estáticas, simplemente significa que se comporta más como un método static ya que no puede usar las variables de instancia (las que no son static) en su clase.

Para evitar fugas de memoria, simplemente no debe usar variables estáticas en absoluto. No es necesario usarlos a menos que haga cosas especiales (por ejemplo, contar instancias de una clase). Las constantes están bien.

Answer 2

Este artículo habla de campos estáticos variables: http://javabook.compuware.com/content/memory/problem-patterns/memory-leaks.aspx. Básicamente, evítelos y use constantes en su lugar.