Referencia débil en lugar de getActivity () (evitar Android memoria fugas)?

Para evitar una fuga de memoria escribí el siguiente método que se utilizará en actividades y principalmente en fragmentos (mediante herencia). Se supone que ese método me permite nunca referirme directamente a la actividad llamando

//this or getActivity() 

El método es:

 private WeakReference<BaseActivity> activityWeakReference = null; public BaseActivity getActivityFromWeakReference(){ activityWeakReference = activityWeakReference == null ? new WeakReference<BaseActivity>((BaseActivity)getActivity()) : activityWeakReference; return activityWeakReference.get(); } 

¿Está llamando a este método getActivityFromWeakReference () en lugar de getActivity () seguro de acuerdo con la amenaza de fugas de memoria?

Si no es seguro hacerlo, ¿debo devolver el activityWeakReference y llamar a su método get () en su lugar, para que sea seguro?

He estado usando en múltiples fragmentos y no he tenido ningún problema hasta ahora. Hago la pregunta porque leo esto ( aquí ):

Mientras la vida del ayudante esté dentro de la vida útil de la Actividad, entonces no hay necesidad de usar una Referencia Weak. Si el ayudante puede vivir más tiempo que la Actividad, debe usar una Referencia Weak para evitar retener la Actividad en su gráfico de objetos cuando el sistema lo destruya.

Hasta ahora, no he enfrentado un caso en el que un elemento referido sobreviva a la actividad. Por favor, los chicos si usted encuentra un error o un posible sólo escribir en los comentarios.

2 Solutions collect form web for “Referencia débil en lugar de getActivity () (evitar Android memoria fugas)?”

Es totalmente factible. Por ejemplo, usted tiene este código pseudocódigo:

 public class MainActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); new DownloadTask().execute(); } public void showInfo() { } class DownloadTask extends AsyncTask<Void, Void, Void> { @Override protected Void doInBackground(Void... params) { return null; } @Override protected void onPostExecute(Void data) { // we can call showInfo() activity because Asynctask hold an implicit reference to activity showInfo(); } } } 

En el código anterior, hay una situación que causó pérdida de memoria.

Aquí está la explicación:

Cuando se crea DownloadTask como el ejemplo anterior, java llamada DownloadTask es una clase interna . Una clase interna implícita contiene una referencia a la clase externa, en este caso es MainActivity . Además, cuando inicie un asynctask, ese asynctask se mantendrá en el sistema hasta que finalice. Por ejemplo, la descarga tarda 30 segundos. En esos 30 segundos, gira el dispositivo. Cuando gira el dispositivo, MainActivity se vuelve a crear y, a menudo, la actividad antigua se destruirá. Pero en este caso, la antigua actividad no se destruye porque la instancia MainActivity edad se mantiene en DownloadTask y DownloadTask se mantiene en el sistema. Se filtra una instancia de actividad.

Para corregir esto, debe cambiar el código anterior a:

 public class MainActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); new DownloadTask(this).execute(); } public void showInfo() { } } class DownloadTask extends AsyncTask<Void, Void, Void> { WeakReference<MainActivity> mainActivityWeakReference; public DownloadTask(MainActivity activity) { mainActivityWeakReference = new WeakReference<MainActivity>(activity); } @Override protected Void doInBackground(Void... params) { return null; } @Override protected void onPostExecute(Void data) { if (mainActivityWeakReference.get() != null) { mainActivityWeakReference.get().showInfo(); } } } 

En este caso, cuando se crea la nueva MainActivity , la antigua no es retenida por DownloadTask (debido al atributo de referencia débil), por lo que la antigua será destruida por Android Garbage Collector en el futuro. También debe comprobar cada vez que utilice un objeto de referencia débil, porque no sabe exactamente cuándo GC destruirá esos objetos.

Aquí está mi propio blog sobre otra situación de pérdida de memoria. Fuga de memoria cuando se utiliza la clase interna estática

Espero que esto ayude.

Hay algunos casos, si su fragmento está configurado para retener la instancia, será más largo que la actividad, o si su fragmento se filtró.

  • Encontrar el mecanismo de caché de memoria "asesino" para Android
  • SocketTimeoutException Android
  • Excepción de objetos muertos de Android
  • Tamaño del mapa de bits devuelto por la cámara a través de la intención?
  • ¿Por qué Android HCE no admite Mifare Classic?
  • Android cómo implementar eficientemente el caché de datos y los eventos de cambio de configuración en fragmentos?
  • Cuando se reemplaza un fragmento y se coloca en la pila de atrás (o se quita) ¿permanece en la memoria?
  • guardar una cadena en la memoria interna y luego mostrarla
  • Pruebas de Android onTrimMemory
  • ¿Por qué debería descartar AlertDialog manualmente en Android?
  • ¿Los oyentes crean fugas de memoria si no se eliminan de una actividad destruida?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.