En breve:
Durante nuestro desarrollo, es fácil causar pérdidas de memoria en la aplicación, entonces, ¿qué es una pérdida de memoria, cómo la solucionamos y cómo optimizar la pérdida de memoria?
1. ¿Qué es una pérdida de memoria?
Si un objeto sigue siendo referenciado por otros objetos cuando no es necesario, el objeto no se puede reciclar y el objeto no se puede liberar, lo que resulta en una pérdida de espacio y memoria Esta situación es una pérdida de memoria.
2. ¿Cuáles son nuestras pérdidas de memoria comunes?
1) Pérdida de memoria causada por variables estáticas:
Las variables estáticas se almacenan en el área de métodos y su ciclo de vida comienza desde el principio hasta el final de la carga de clases. Una vez que se inicializa la variable estática, la referencia que contiene no se liberará hasta que finalice el proceso.
En muchos casos, la retención estática puede causar pérdidas de memoria debido al ciclo de vida inconsistente de su uso. Por lo tanto, al crear variables de retención estática, debemos considerar la relación de referencia entre varios miembros y usar la retención estática lo menos posible. Algunas variables para evitar pérdidas de memoria. Por supuesto, también podemos restablecer el valor estático a nulo en el momento adecuado para que ya no contenga una referencia, lo que también puede evitar pérdidas de memoria.
Observamos un fragmento de código:
public class MainActivity extends Activity{
public static Context mContext;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mContext = this;
}
}El objeto Contexto es estático, entonces la Actividad no se puede destruir normalmente y permanecerá en la memoria.
Solución:
Utilice el contexto de la aplicación. 2 Utilice la palabra clave estática con precaución
2) Las clases internas no estáticas causan pérdidas de memoria
La clase interna no estática contendrá la referencia de la clase externa por defecto. Cuando el ciclo de vida del objeto de la clase interna no estática es más largo que el ciclo de vida del objeto de la clase externa, causará pérdida de memoria.
El uso de Handler es típico:
El controlador contendrá implícitamente la referencia externa de la clase actual. Dado que el controlador es una clase interna no estática, contiene la referencia implícita de la actividad actual. Si el controlador no se libera, la referencia externa que contiene, es decir, la actividad, no se puede liberar. , Cuando un objeto ya no necesita ser usado, debe ser reciclado, y otro objeto en uso tiene su referencia, lo que hace que no pueda ser reciclado, lo que hace que el objeto que debería haber sido reciclado no pueda ser reciclado y se quede En la memoria del montón, esto crea una pérdida de memoria.
¿Cómo utilizar el controlador? Mostrar por código:
public class MainActivity extends AppCompatActivity{
private Handler mHandler;
@Override
protected void onCreate(BundlesavedInstanceState){
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mHandler=newMyHandler(this);
start();
}
private void start(){
Messagemsg=Message.obtain();
msg.what=1;
mHandler.sendMessage(msg);
}
private static class MyHandler extends Handler{
private WeakReference<MainActivity> activityWeakReference;
public MyHandler(MainActivity activity){
activityWeakReference=newWeakReference<>(activity);
}
@Override
public void handleMessage(Messagemsg){
MainActivityactivity=activityWeakReference.get();
if(activity!=null){
if(msg.what==1){
//做相应逻辑
}
}
}
}
}mHandler retiene la actividad a través de referencias débiles. Cuando el GC realiza la recolección de basura, recuperará y liberará la unidad de memoria ocupada cuando encuentre la actividad. De esta forma, no se producirán pérdidas de memoria.
3) TimerTask causa pérdida de memoria
Cuando se destruye nuestra Actividad, es posible que el Timer todavía esté esperando para ejecutar el TimerTask. Contiene la referencia a la Actividad y no se puede reciclar. Por lo tanto, cuando se destruye nuestra Actividad, debemos cancelar inmediatamente el Timer y TimerTask para evitar pérdidas de memoria.
4) Los objetos de la colección no se limpian provocando pérdidas de memoria
Si un objeto se coloca en una colección como ArrayList, HashMap, etc., esta colección contendrá una referencia al objeto. Cuando ya no necesitamos este objeto, no lo eliminamos de la colección, así que mientras la colección esté todavía en uso (y este objeto sea inútil), este objeto causa una pérdida de memoria. Y si la colección está referenciada estáticamente, esos objetos inútiles de la colección incluso causarán pérdidas de memoria. Por lo tanto, cuando utilice la colección, elimine o borre los objetos no utilizados de la colección a tiempo para evitar pérdidas de memoria.
5) El recurso no se cierra ni se libera provocando pérdidas de memoria
Al utilizar IO, File stream o Sqlite, Cursor y otros recursos, debe cerrarse a tiempo. Estos recursos suelen utilizar búferes durante las operaciones de lectura y escritura. Si no se cierran a tiempo, estos objetos de búfer permanecerán ocupados y no podrán liberarse, lo que provocará pérdidas de memoria. Por lo tanto, los cerramos a tiempo cuando no necesitamos usarlos, para que el búfer pueda liberarse a tiempo para evitar pérdidas de memoria.
6) Pérdida de memoria causada por animación de atributos
La animación también es una tarea que requiere mucho tiempo. Por ejemplo, cuando se inicia la animación de propiedad (ObjectAnimator) en la Actividad, no se llama al método cancle cuando se destruye. Aunque ya no podemos ver la animación, la animación continuará reproduciéndose. El control donde se encuentra la referencia se refiere a la Actividad, lo que hace que la Actividad no pueda liberarse normalmente. Por lo tanto, también es necesario cancelar la animación de atributos cuando se destruye la Actividad para evitar pérdidas de memoria.
para resumir:
La pérdida de memoria es un aspecto más importante en la optimización de la memoria de Android. En resumen, siempre que siga los siguientes puntos, puede evitar pérdidas de memoria en la mayoría de los casos:
Preste atención al borrado de los objetos de la aplicación o utilice referencias menos estáticas cuando se trate de referencias estáticas;
Utilice clases internas estáticas + referencias suaves en lugar de clases internas no estáticas;
Cancele la transmisión o el registro de observadores a tiempo; recuerde cancelar las tareas que consumen mucho tiempo y las animaciones de atributos cuando se destruye la Actividad;
El flujo de archivos, el cursor y otros recursos se cierran a tiempo;