¿Por qué Android "abandona" las referencias suaves?
WeakReference
SoftReference
PhantomReference
Todas ellas Está diseñado para utilizar el montón de manera más eficiente.
WeakReference
Si la única referencia que queda a una variable es WeakReference, el GC reciclará la variable sin piedad. En otras palabras, WeakReference no puede mantener variables en la memoria durante períodos de tiempo más largos.
Los desarrolladores de Android deben comprender el uso de WeakReference. Un escenario de aplicación típico es un controlador. Para evitar pérdidas de memoria, definiremos una clase estática interna y luego haremos referencia a la Actividad en forma de WeakReference.
clase pública MainActivity extiende la actividad {
private static final int MSG_ID = 0x00;
public void testSafeHandler() {
controlador SafeHandler = new SafeHandler(this);
handler.sendEmptyMessage(MSG_ID);
}
clase pública estática SafeHandler extiende Handler {
Private WeakReference
public SafeHandler(actividad de actividad) {
mactivityRef = new WeakReference<>(actividad);
}
public void handleMessage(Mensaje msg) {
cambiar (msg.what) {
caso MSG_ID:
Actividad actividad = mActivityRef.get() ;
if (actividad ! = null) {
actividad.finish();
}
}
}
}
}
}
SoftReference
De la definición oficial de SoftReference, solo se usa en caso de pánico por la memoria (OOM está a punto de ocurrir). Solo cuando hay una emergencia de memoria (OOM está a punto de ocurrir), solo se reciclarán las variables de SoftReference, por lo que SoftReference es más adecuado para usar como caché:
SoftReference se usa más comúnmente para implementar memoria -cachés sensibles.
Pero la versión Android de SoftReference no está de acuerdo:
De hecho, SoftReference es muy ineficiente en el almacenamiento en caché.
Debido a que SoftReference no proporciona suficiente información, el tiempo de ejecución no puede decidir fácilmente si borrarla o conservarla. Por ejemplo, si tiene 10 variables SoftReference y ninguna de las variables a las que hacen referencia tiene referencias sólidas, el tiempo de ejecución se confundirá porque no sabe qué variables deben borrarse o conservarse.
Peor aún, el tiempo de ejecución no sabe si borrar SoftReference o aumentar el tamaño del montón.
Así que Android abandonó SoftReference y recomendó usar android.util. Al menos LruCache puede decidir si debe borrarse en función de la frecuencia de uso de la variable. Esto tiene una condición de decisión más que simplemente usar SoftReference: la frecuencia de uso de la variable.