Summary of Android out of memory methods

The method to avoid memory overflow is to optimize the program in the following three aspects

@H_ 404_ 4 @ memory reference

Before dealing with memory references, let's review what are strong references, soft references, weak references and virtual references @ H_ 404_ 4 @ 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.

@H_ 404_ 4@ soft reference: if an object has only soft reference but enough memory space, 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.

@H_ 404_ 4 @ 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.

@H_ 404_ 4@ 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.

@H_ 404_ 4@1 Release strong references

Generally, when we declare object variables, we don't care after using them. We think that the garbage collector will help us recycle the memory space pointed to by these objects. In fact, if the memory space of this object is still in the referenced state, the garbage collector will never recover its memory space. Only when this memory space is not referenced by any object, The garbage collector will recycle. Therefore, after using the object, we can set the object to be empty, so that my garbage collector GC will release the memory space allocated for the object at an appropriate time

Of course, you need to confirm whether you no longer need to use the object when it is set to unprecedented. If you need to use the object at any time, you can't do so

@H_ 404_ 4@2 Use soft reference

All soft references will be cleared before the JVM reports that there is insufficient memory. In this way, GC can collect the memory space released by many soft references, so as to solve the problem of memory shortage and avoid memory overflow. When it is recycled depends on the GC algorithm and the available memory size when GC runs. We can use softreference to encapsulate strongly referenced objects

@H_ 404_ 4@3 The execution process of collecting weakly referenced objects using weak reference GC is the same as that of soft reference, but GC will not decide whether to recycle weakly referenced objects according to memory conditions.

If you want to be able to get the information of an object at any time, but do not want to affect the garbage collection of the object, you should use WeakReference to remember the object instead of a general reference.

@H_ 404_ 4 @ image processing

Most of the oom 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. Because the Android system will allocate a certain amount of memory for each application and will not allocate all the memory of the whole system to applications, no matter how large the memory of your mobile phone is, the memory it can use is limited for each app. This is very different from the PC side. If the PC side has insufficient memory, it can also request to use virtual memory, which is not available in the Android system.

@H_ 404_ 4@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.

@H_ 404_ 4@2 Reclaim the memory occupied by pictures after using them

Because the outer layer of Android uses Java and the lower layer uses the memory space allocated by C language 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.

@H_ 404_ 4@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 in 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.

In fact, most pictures are set to ARGB_ After 4444 mode, it can't be seen with ARGB on the display_ What's the difference between 8888 mode and 8888 mode? It's just that when a picture has gradient effect, it may make the gradient appear color strip effect. This method of reducing color quality has less effect on memory than method 1.

@H_ 404_ 4@4 . do not load pictures into memory when querying picture information @ h_ 404_ 4@

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.

Injustdecodebounds property. If the value is true, the actual bitmap object will not be returned and memory space will not be allocated, but it allows us to query the basic information such as picture width, height and size. (get the original width and height: options.outwidth, options.outheight)

@H_ 404_ 4@VMRuntime

Vmruntime is a class provided in the Android SDK. It is only useful before Android 2.3, and SDK after 2.3 does not support it, so this vmruntime is not universal. Here is a brief introduction.

@H_ 404_ 4@1 . optimize heap memory allocation of Dalvik virtual machine

The settargetheputilization method provided by the vmruntime class can enhance the processing efficiency of program heap memory.

@H_ 404_ 4@2 . customize the heap memory size, force to define the memory size allocated by Android to the current app, and use vmruntime to set the minimum heap memory of the application.

@H_ 404_ 4@largeHeap Let the Dalvik virtual machine allocate more memory for the app. This method can strive for more memory space for our app, so as to alleviate the pressure of insufficient memory. You can use the activitymanager. Getmemoryclass() method in the program to obtain the size of APP memory under normal use. Use activitymanager. Getlargememoryclass() You can get the maximum memory size when largeheap is turned on

@H_ 404_ 4@1 Usage @ h_ 404_ 4@

This method is very simple to use. Just add "Android: largeheap =" true "to the < Application > node attribute in the androidmanifest.xml file“

@H_ 404_ 4@2 . attention

Dalvik's increased memory for our app is likely to be obtained by killing other background processes. This is not moral for a developer. 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.

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.