Android memory overflow and memory leak

Android memory overflow and memory leak

In the interview, some interviewers often ask "do you know what is memory overflow? What is memory leakage? How to avoid it?" through this article, you can answer.

Memory overflow (OOM) means that the program does not have enough memory space for its use when applying for memory, and out of memory occurs; For example, if you only apply for an integer, but save it with a long to save the number, there will be a memory overflow.

Memory leak means that the program cannot release the applied memory space after applying for memory. The harm of a memory leak can be ignored, but the consequences of memory leak accumulation are very serious. No matter how much memory is, it will be occupied sooner or later.

A memory leak will eventually lead to a memory overflow.

How to avoid memory overflow?

Strong references: strong references are the most commonly used references. If an object has a strong reference, the garbage collector will never recycle it. When the memory space is insufficient, the Java virtual machine would rather throw outofmemoryerror error to make the program terminate abnormally, rather than solve the problem of insufficient memory by arbitrarily recycling objects with strong references.

Soft reference: if an object has only soft reference, but the memory space is enough, the garbage collector will not recycle it; It will not be recycled until the virtual machine reports that there is not enough memory. As long as the garbage collector does not recycle it, the object can be used by the program. Soft references can be used to implement memory sensitive caching. The soft reference can be used in conjunction with a reference queue. If the object referenced by the soft reference is recycled by the garbage collector, the Java virtual machine will add the soft reference to the associated reference queue.

Weak references: objects with only weak references have a shorter life cycle. When the garbage collector thread scans the memory area under its jurisdiction, once it finds an object with only weak references, it will reclaim its memory regardless of whether the current memory space is sufficient. However, since the garbage collector is a low priority thread, it is not necessary to quickly find objects with only weak references. A weak reference can be used in conjunction with a reference queue. If the object referenced by the weak reference is garbage collected, the Java virtual machine will add the weak reference to the associated reference queue.

Virtual reference: virtual reference can be understood as a virtual reference. Unlike other references, virtual reference does not determine the life cycle of an object. If an object holds only virtual references, it may be recycled by the garbage collector at any time as if it had no references. Virtual references are mainly used to track the activities of objects collected by the garbage collector. One difference between virtual references and soft and weak references is that virtual references must be used in conjunction with reference queues. When the garbage collector prepares to recycle an object, if it finds that it still has a virtual reference, it will add the virtual reference to the associated reference queue before recycling the memory of the object. The program can know whether the referenced object will be garbage collected by judging whether a virtual reference has been added to the reference queue. If the program finds that a virtual reference has been added to the reference queue, it can take the necessary action before the memory of the referenced object is reclaimed.

1. Release strong references and use soft references and weak references;

2. Most of the oom in image processing occurs in image loading. When loading large images, we need to pay special attention to avoid the occurrence of oom. When processing large pictures, no matter how large the memory of your mobile phone is, if you do not process the pictures, there may be a memory overflow problem.

1. Compress pictures in memory

When loading a large picture, you need to compress the picture, and use the equal proportion compression method to process the picture directly in memory

In doing so, it should be noted that the picture quality will become worse. The larger the value of insamplesize is, the worse the picture quality will be. The scaling ratio of different mobile phone manufacturers may be different.

2. Reclaim the memory occupied by pictures after using them

Because the outer layer of Android uses Java and the lower layer uses C language, the memory space allocated for picture objects in the inner layer. Therefore, although our external layer seems to be released, the inner layer is not necessarily completely released. We'd better release the memory space of the inner layer after using the pictures.

3. Reduce the color quality of the picture to be displayed

Bitmap in Android has four picture color modes:

ALPHA_ 8: Each pixel needs to occupy 1 byte RGB in memory_ 565: each pixel needs to occupy 2byte ARGB in memory_ 4444: each pixel needs to occupy 2byte ARGB in memory_ 8888: each pixel needs to occupy 4 bytes of memory

When we create a bitmap, the default color mode is ARGB_ 8888, this color mode is of the highest quality. Of course, this mode occupies the largest memory. And ARGB_ 4444 each pixel occupies only 2 bytes, so ARGB is used_ 4444 mode can also reduce the memory occupied by pictures.

4. Do not load pictures into memory when querying picture information

Sometimes we get a picture just to get some information of the picture, such as the width and height of the picture. We don't need to display it on the interface. At this time, we don't need to load the picture into memory.

We should not rely on striving for the maximum memory to solve the oom problem. We should avoid the oom problem as much as possible through reasonable coding.

How to avoid memory leakage?

1. Call mthread. Close() in ondestroy() method; This is used to end the thread, which avoids the memory leakage problem of the thread. 2. Use application context instead of activity context; 3. Memory leakage caused by resource object not being closed, such as cursor not being closed; 4. Remember to delete bitmap recycle; 5. When constructing the adapter, the cached convertview is not used.

Thank you for reading, hope to help you, thank you for your support to this site!