¿Qué problemas causarán las pérdidas de memoria de Android?
1. Consultar la base de datos sin cerrar el Cursor
En Android, el Cursor es un objeto muy utilizado, pero al escribir código, la gente a menudo se olvida de llamar a cerrar, o debido a código Un problema lógico provocó que no se llamara a close.
Por lo general, en Actividad, podemos llamar a startManagingCursor o usar directamente ManagedQuery para permitir que Actividad administre automáticamente los objetos Cursor.
Pero cabe señalar que después de introducir la Actividad, ¡el Cursor ya no estará disponible!
Si el código que opera el cursor no está sincronizado con la interfaz de usuario (como un hilo en segundo plano), no es necesario determinar primero si la actividad ha finalizado o esperar a que finalice el hilo en segundo plano antes. llamando a OnDestroy.
Además, las siguientes también son situaciones comunes en las que el Cursor no se cerrará:
Aunque parece que se ha llamado a Cursor.close(), si ocurre una excepción, close( ) se omitirá, lo que provocará pérdidas de memoria.
Entonces, nuestro código debería escribirse de la siguiente manera:
Cursor c = queryCursor()
try {
int a =; c.getInt(1);
......
} captura (Excepción e) {
} finalmente {
c.close(); // Llama a close() finalmente para asegurarte de que será llamado
}
prueba {
Cursor c = queryCursor ();
int a = c.getInt(1);
......
c.close();
} catch (Excepción e) {
}
2. No se llama a UnregisterReceiver() después de llamar a RegisterReceiver.
Después de llamar a RegisterReceiver, si es unregisterReceiver No se llama, la memoria que ocupa es bastante grande.
Y a menudo podemos ver código similar al siguiente:
Este es un error muy grave porque hará que BroadcastReceiver no se cancele del registro y provocará una pérdida de memoria.
registerReceiver(new BroadcastReceiver() {
...
}, filtro...
3. InputStream/OutputStream
Al usar archivos o acceder a recursos de red, el uso de InputStream/OutputStream también puede causar pérdidas de memoria
4 No se llama a Recycle() después de usar Bitmap
<. p>Según la descripción del SDK, no es necesario llamar al reciclaje. Pero en el uso real, Bitmap ocupa mucha memoria, por lo que cuando ya no lo usemos, intente llamar a reciclar () para liberar recursos.5. Fuga de contexto
Esta es una pérdida de memoria muy oscura.
Primero echemos un vistazo al siguiente código:
En este código, utilizamos un objeto Drawable estático.
Esto suele ocurrir cuando necesitamos llamar a un Drawable con frecuencia, su carga lleva mucho tiempo y no queremos crear este Drawable cada vez que se carga la Actividad.
En este momento, usar estática es sin duda la forma más rápida de escribir código, pero también es muy mala.
Cuando se adjunta un Drawable a una Vista, la Vista se establecerá como la devolución de llamada del Drawable (llamando a Drawable.setCallback()).
Esto significa que este Drawable tiene una referencia a TextView y TextView tiene una referencia a Activity.
Esto hará que la memoria no se libere después de que se destruya la Actividad.
fondo dibujable estático privado
@Override
vacío protegido onCreate(estado del paquete) {
super.onCreate(estado);
TextView label = new TextView(this);
label.setText("Las fugas son malas"); /p>
sBackground = getDrawable(R.drawable.large_bitmap);
}
label.setBackgroundDrawable(sBackground);
setContentView(label) ;
}