1) análisis OOM
En primer lugar, debe comprender que el sistema Android creará una instancia de máquina virtual Dalvik para cada aplicación, luego creará un proceso y luego creará el hilo principal, formando así una aplicación. Luego, la creación de una máquina virtual tendrá en cuenta la asignación de tamaño de memoria DalvikHeap para cada máquina virtual. El tamaño de la memoria de los diferentes teléfonos móviles de rendimiento es diferente. En los primeros días, algunas máquinas asignaban 16M y otras 24M. Por supuesto, el tamaño de DalvikHeap es un intervalo con su umbral máximo (utilizable El comando adb se usa para ver la memoria máxima asignada: adbshell getprop dalvik.vm.heapsize) Cuando la memoria ocupada por la aplicación excede este umbral, se genera OutOfMemoryError (comúnmente conocido como OOM). OOM aparece principalmente porque la aplicación de memoria de la aplicación se acumula cada vez más, y el futuro y el reciclaje de gc superarán el umbral máximo de Heapsize.
Existen principalmente las siguientes situaciones:
1. El objeto de imagen cargado es demasiado grande;
2. Demasiados recursos, demasiado tarde para cargar;
3. No se ha liberado una gran cantidad de pérdidas de memoria.
Soluciones comunes para evitar OOM:
1. Si la imagen es demasiado grande al cargar la imagen, ajuste el tamaño de la imagen apropiadamente para la compresión;
2. La imagen utiliza un método de codificación de memoria baja: Bitmap.Config.ARGB_4444;
3. Cargue las imágenes de red usando la caché de nivel 2, generalmente terceros ya las han empaquetado;
4. Un gran número de referencias de memoria de imágenes locales utilizan referencias suaves;
5. El Adaptador de Listview reutiliza la caché convertView pasada a getView () para evitar inflar repetidamente, y usa el modo ViewHolder para evitar llamadas innecesarias a findViewById para reducir el consumo de memoria;
6. Trate de evitar pérdidas de memoria (las pérdidas de memoria se encuentran principalmente debajo para una introducción detallada);
7. Personalice el tamaño de la asignación de memoria del montón y optimice la asignación de la memoria del montón de la máquina virtual Dalvik;
2) Análisis de fugas de memoria
La recolección de basura JAVA (recolección de basura, GC para abreviar) maneja la recuperación de la memoria del montón, pero si se ha hecho referencia al objeto y no se puede recuperar, desperdiciará memoria y ya no se podrá usar, causando una pérdida de memoria.
Fugas de memoria comunes:
1. La pérdida de memoria causada por el singleton se debe principalmente a que el contexto de la actividad y el servicio se pasan como variables miembro para causar la pérdida de memoria. Puede usar context.getApplicationContext () para resolver la pérdida de memoria;
2. Las clases internas y anónimas no estáticas de la actividad, todas contienen referencias de actividad, que pueden conducir fácilmente a pérdidas de memoria. Las clases internas del controlador típico contienen referencias de actividad. Puede usar referencias suaves de clases internas estáticas para eliminar la referencia de las clases internas a la actividad. Para solucionar la pérdida de memoria;
3. No se llama a Recycle () después de que se usa Bitmap, lo que provoca pérdidas de memoria, que se pueden solucionar agregando reciclar () al final;
4. El cursor de la base de datos no está cerrado, se puede solucionar cerrándolo al final;
5. Llamar a register para registrar no se desvincula, se puede resolver llamando a unregister para desvincular después del final;
6. El zócalo y el IO no están cerrados, se puede solucionar cerrándolo después del final;
7. Webview no se destruye después del final, se puede resolver destruyéndolo después del final.
mWebViewContainer.removeView(mWebView);
mWebView.stopLoading();
mWebView.getSettings().setJavaScriptEnabled(false);
mWebView.clearHistory();
mWebView.removeAllViews();
mWebView.destroy();