Memory overflow and memory leak issues with Android face questions

In interviews, the interviewer often asks, "Do you know what a memory overflow is?" What is a memory leak? How to avoid it? "With this article, you can answer it."

A memory overflow (OOM) means that the program does not have enough memory space for its use when requesting memory, and out of memory, for example, if only one integer is applied, but a long can be stored to save it, there will be an overflow.

memory leak refers to the program after the application of memory, unable to free up the requested memory space, a memory leak hazard can be ignored, but the memory leak accumulation of serious consequences, no matter how much memory, sooner or later will be occupied.

A memory leak can eventually cause 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 there is not enough memory space, the Java virtual Machine prefers to throw a outofmemoryerror error, which causes the program to terminate abnormally, and does not rely on random recycling of strongly referenced objects to resolve out-of-memory issues.
Soft Reference : If an object has only a soft reference, but the memory space is sufficient, the garbage collector does not recycle it until the virtual machine reports enough memory to be recycled, and the object can be used by the program as long as the garbage collector does not recycle it. Soft references can be used to implement memory-sensitive caches. A soft reference can be used in conjunction with a reference queue (Referencequeue), and if the object referenced by the soft reference is reclaimed by the garbage collector, the Java Virtual machine will add the soft reference to the reference queue associated with it.
Weak references : Objects with only weak references have a shorter life cycle. As the garbage collector thread scans the area of memory it governs, once an object with only a weak reference is found, its memory is reclaimed regardless of whether the current memory space is sufficient. However, because the garbage collector is a low-priority thread, it is not necessarily quick to discover objects that have only weak references. A weak reference can be used in conjunction with a reference queue (Referencequeue), and if the object referenced by the weak reference is garbage collected, the Java virtual machine adds the weak reference to the reference queue associated with it.
Virtual Reference: A virtual reference can be understood as a dummy reference, and unlike several other references, a virtual reference does not determine the life cycle of an object. If an object holds only virtual references, it can be reclaimed by the garbage collector at any time, just as there are no references. Virtual references are primarily used to track activities that objects are reclaimed by the garbage collector. One difference between a virtual reference and a soft reference and a weak reference is that the virtual reference must be used in conjunction with the reference queue (Referencequeue). When the garbage collector prepares to reclaim an object, if it finds that it has a virtual reference, it will add the virtual reference to the reference queue associated with it before reclaiming the object's memory. The program can see if the referenced object is going to be garbage collected by judging whether the reference queue has been added to the virtual reference. If the program discovers 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, use soft references and weak references;

2, image processing
Most of the oom is happening on the image loading, and when we load the larger map, we need to pay special attention to avoid the oom.
When working with large images, no matter how big your phone's memory is, there is a possibility of a memory overflow problem if the image is not processed.
1. Compress the image in memory
When loading a large picture, you need to compress the picture and use the proportional compression method to process the picture directly in memory.

Options options = new BitmapFactory.Options(); options.inSampleSize5; // 原图的五分之一，设置为2则为二分之一 BitmapFactory.decodeFile(myImage.getAbsolutePath(), options); 

In doing so, it is important to note that the image quality will become worse, the larger the value of the Insamplesize setting, the worse the picture quality, and the different scale of the handset manufacturers may be different.
2, after the use of pictures to recover the memory of the image
Because the Android outer layer uses Java and the bottom layer uses the memory space assigned by the C language to the picture object in the inner layers.
So our exterior, although it seems to be released, but the inner layer is not necessarily completely released, we use the picture after the best release of the inner memory space.

if (!bitmapObject.isRecyled()) {     // Bitmap对象没有被回收      bitmapObject.recycle();     // 释放      System.gc();     // 提醒系统及时回收 }  

3, reduce the color quality of the picture to be displayed
There are four image color modes in Android bitmap:
Alpha_8: Each pixel needs to occupy 1byte in memory
rgb_565: Each pixel needs to occupy 2byte in memory
argb_4444: Each pixel needs to occupy 2byte in memory
argb_8888: Each pixel needs to occupy 4byte in memory
When we create bitmap, the default color mode is argb_8888, which is the highest quality, and of course, this pattern consumes the most memory.
While argb_4444 consumes only 2byte per pixel, using argb_4444 mode can also reduce the amount of memory used by the image.

4. Do not load images into memory when querying picture information
Sometimes we get a picture, maybe just to get some information about this picture, than the width of the piece, height and other information, do not need to display the interface, this time we can not load the picture into memory.

BitmapFactory.Options options = new BitmapFactory.Options(); options.inJustDecodeBounds = true; // 不把图片加载到内存中 Bitmap btimapObject = BitmapFactory.decodeFile(myImage.getAbsolutePath(), options);  

We should not put the problem of solving oom in the pursuit of the largest memory, should be through reasonable coding to avoid the oom problem as much as possible.

How do I avoid memory leaks?
1, the call to Mthread.close () is displayed in the OnDestroy () method, which ends the thread, which avoids the thread's memory leak problem.
2, use application context instead of activity context;
3, the resource object is not closed due to a memory leak, such as the cursor does not close off;
4,bitmap remember recycle drop;
5, when constructing adapter, no cached Convertview is used.

Memory overflow and memory leak issues with Android face questions