java - para - manual programacion android español pdf

¿Cómo evitar pérdidas de memoria en la devolución de llamada?

Question

Java eficaz dice:

Una tercera fuente común de pérdidas de memoria son los escuchas y otras devoluciones de llamada. Si implementa una API donde los clientes registran las devoluciones de llamada pero no las cancele de forma explícita, se acumularán a menos que realice alguna acción. La mejor manera de garantizar que las devoluciones de llamadas se recopilen rápidamente es almacenar solo las referencias débiles, por ejemplo, almacenándolas solo como claves en un WeakHashMap.

Soy un principiante en Java. ¿Podría alguien enseñarme cómo crear referencias débiles en las devoluciones de llamada y decirme cómo solucionan los problemas de pérdida de memoria? Gracias.

Answer 1

Aquí también puede encontrar una explicación clara y práctica : Fugas de memoria en Android: identifique, trate y evite

Answer 2

Lee this articulo

Las claves para llevar son:

Puede pensar en las referencias directas como referencias sólidas que no requieren codificación adicional para crear o acceder al objeto. Los tres tipos de referencias restantes son subclases de la clase de referencia que se encuentra en el paquete java.lang.ref. Las referencias suaves son proporcionadas por la clase SoftReference, las referencias débiles por la clase WeakReference y las referencias fantasma por PhantomReference.

Las referencias blandas actúan como un caché de datos. Cuando la memoria del sistema es baja, el recolector de basura puede liberar arbitrariamente un objeto cuya única referencia es una referencia blanda. En otras palabras, si no hay referencias sólidas a un objeto, ese objeto es un candidato para su lanzamiento. Se requiere que el recolector de basura libere cualquier referencia de software antes de lanzar una excepción OutOfMemoryException.

Las referencias débiles son más débiles que las referencias blandas. Si las únicas referencias a un objeto son referencias débiles, el recolector de basura puede reclamar la memoria utilizada por un objeto en cualquier momento. No hay ningún requisito para una situación de memoria baja. Normalmente, la memoria utilizada por el objeto se reclama en el siguiente paso del recolector de basura.

Las referencias fantasmas se relacionan con tareas de limpieza. Ofrecen una notificación inmediatamente antes de que el recolector de basura realice el proceso de finalización y libere un objeto. Considérelo como una forma de realizar tareas de limpieza dentro de un objeto.

seguido de la lista de WeakListModel que no publicaré para evitar saturar esta respuesta.

Answer 3

Para ilustrar el concepto con un ejemplo rápido (en bruto), considere lo siguiente:

public interface ChangeHandler {
    public void handleChange();
}

public class FileMonitor {

    private File file;
    private Set<ChangeHandler> handlers = new HashSet<ChangeHandler>();

    public FileMonitor(File file) { 
        this.file = file;
    }

    public void registerChangeHandler(ChangeHandler handler) {
        this.handlers.add(handler);
    } 

    public void unregisterChangeHandler(ChangeHandler handler) {
        this.handlers.remove(handler);
    }

    ...
}

Si una clase de cliente utiliza esta API FileMonitor , pueden hacer esto:

public class MyClass {

    File myFile = new File(...);
    FileMonitor monitor = new FileMonitor(myFile);

    public void something() {
        ...
        ChangeHandler myHandler = getChangeHandler();
        monitor.registerChangeHandler(myHandler);
        ...
    }
}

Si el autor de MyClass se olvida de llamar a unregisterChangeHandler() cuando se hace con el controlador, el HashSet FileMonitor siempre hará referencia a la instancia registrada, lo que hará que permanezca en la memoria hasta que se destruya FileMonitor o se FileMonitor la aplicación.

Para evitar esto, Bloch sugiere utilizar una colección de referencias débiles en lugar de HashSet , de modo que si se destruye su instancia de MyClass , la referencia se eliminará de la colección del monitor.

Puede reemplazar el HashSet en FileMonitor con un WeakHashMap y usar los manejadores como claves, ya que este último eliminará automáticamente el manejador de la colección cuando todas las demás referencias al objeto hayan desaparecido.