Shulou(Shulou.com)05/31 Report--

Most people do not understand the knowledge points of this article "how to achieve memory management in Android", so the editor summarizes the following contents, detailed contents, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "how to achieve memory management in Android" article.

Memory leak: a situation in which the space allocated by an object in the memory heap heap cannot be normally reclaimed by GC when it is no longer in use or without reference points. Most of them occur in unreasonable coding situations, such as registering a broadcast receiver in Activity, but unRegister when the page is closed, there will be a memory overflow. In general, a large number of memory leaks can cause OOM.

OOM: OutOfMemoery, as the name implies, refers to a memory overflow. Memory overflow means that APP applies to the system for memory requests that exceed the * * threshold, and the system will no longer allocate excess space, resulting in OOM error. On our Android platform, most cases occur when images are loaded improperly.

The way of memory management is to first understand and find out the cause of the memory leak, and then based on these trans to reasonable coding, to prevent and avoid excessive memory overhead. Learn how to manage memory properly. * first understand the mechanism and principle of memory allocation. Only by deeply understanding the internal principles can we really avoid the occurrence of OOM. However, this article will not cover the mechanism of Jvm/Davilk memory allocation. If you are interested, please check out the historical messages, which have previously been shared entitled "JVM Runtime data region Analysis".

What is the amount of memory that Android APP can apply for? some people say it is 16MB, others say it is 24MB. This kind of thing, it is more reliable to test it with your own mobile phone. The testing method is also relatively simple. There is a Runtime class in Java, which is mainly used as APP to interact with the runtime environment. APP will not create an instance of Runtime for us, but Java provides us with a singleton acquisition method, Runtime.getRuntime (). Get the * memory that the system can allocate for APP through the maxMemory () method, and totalMemory () get the amount of memory heap space currently allocated by APP. I have two mobile phones, one Oppo find7, running Color OS, the actual memory allocation is 192 MB, and one Tianyu v9, running Xiaomi system, the measured memory allocation is 100MB. This can be seen, because Android is an open source system, different mobile phone manufacturers actually have the ability to modify this part of the authority, so it results in different brands and different systems of mobile phones, the memory support for APP is also different, and IOS's permanent 100MB is different. Generally speaking, the higher the configuration of the phone's memory, the manufacturer will also increase the memory threshold supported by the phone, especially when the flagship phone is released all over the sky. However, in order to consider the memory compatibility of the developed APP, developers can not guarantee which phone APP runs on, so they can only optimize memory from the point of view of coding.

Let's analyze the key points of Android memory optimization one by one.

1. Evil static

Static is a good thing, declaring that assignment calls are so simple and convenient, but there are performance issues that come with it. Because the life cycle of static declaration variables is actually the same as the life cycle of APP, it is somewhat similar to Application. If it is used in large quantities, it will occupy the memory space and will not be released, and the accumulation of a little will cause continuous memory overhead until it is hung up. The reasonable use of static is generally used to modify basic data types or lightweight objects, to avoid repairing collections or large objects, and is often used to modify global configuration items, tool class methods, and inner classes.

2. Irrelevant citation

In many cases, we need to pass the reference, but we cannot guarantee that the reference can be recycled in time after it is passed. For example, the typical Context leak, in many cases, when the Activity is finished, it can not be reclaimed because it is still pointed to by other objects, which results in memory leakage. The third suggestion can be considered at this point.

3. Make good use of SoftReference/WeakReference/LruCache

Is there such a mechanism in Java and Android? when memory is tight or GC is scanned, some memory can be released in time and allocated to places that need to be allocated. The answer is yes. Java provides us with two solutions. If you are more concerned about the memory cost of APP, you can consider using WeakReference, which will be reclaimed when GC recycling sweeps this memory area; if you are not so concerned, you can use SoftReference, which will be automatically released when the memory request is insufficient, which can also solve the OOM problem. At the same time, Android has also introduced the LruCache class since 3.0. using the LRU algorithm to free memory can also solve OOM. If it is compatible with version 3.0, please import the v4 package. With regard to the irrelevant reference of the second article, we can consider using WeakReference to wrap the parameters.

4. Cautious handler

Handler + thread is a good choice when dealing with asynchronous operations. But I believe that when using handler, everyone will encounter a warning situation, which is a reminder for developers of lint. Handler runs on the UI thread and constantly processes messages from MessageQueue. If the handler still has messages to process but the Activity page has ended, the Activity reference is not actually recycled, which results in a memory leak. The solution is to call the onDestroy method in Activity

Handler.removeCallbacksAndMessages (null); cancel the processing of all messages, including messages to be processed; second, declare the inner class of handler as static.

5. Bitmap*** Killer

Improper handling of Bitmap is very likely to lead to OOM, and the vast majority of cases occur for this reason. Bitamp bitmap is a well-deserved fat boy in Android, so of course you are very careful when operating it. Since Dalivk does not take the initiative to recycle, developers need to recycle it when Bitmap is not used. In the process of use, timely release is very important. At the same time, if the demand allows, you can also go to BItmap for a certain zoom, which can be controlled by the inSampleSize attribute of BitmapFactory.Options. If you just want to get the attributes of Bitmap, you don't need to allocate memory according to the pixels of BItmap, just use the inJustDecodeBounds attribute of BitmapFactory.Options when parsing and reading Bmp. * it is recommended that you use soft or weak references and local caching when loading network images. It is recommended to use android-universal-imageloader or xUtils. It must be a high-quality product. A few days ago, when I was talking about "Custom controls (3) inheriting controls", I also sorted out one. You can go to Github to download it.

6. Cursor shuts down in time

When querying the SQLite database, a Cursor is returned, and when the query is completed, it is closed in time, so that the result set of the query can be recycled in time.

7. Page background and picture loading

When setting the background and picture in the layout and code, if it is a solid color, try to use color; if it is regular graphics, try to use shape to draw; if it is a little more complicated, you can use 9patch; if you cannot use 9patch, cut images for several mainstream resolution models.

8. Item cache for ListView and GridView

For mobile devices, especially the hardware jagged android ecosystem, page rendering is actually time-consuming and findViewById is slow. So do not reuse View, especially when there is a list, there is often the phenomenon of sliding very stuck. Specifically refer to the historical article "talk about another way to write ViewHolder"

9 、 BroadCastReceiver 、 Service

Bind broadcasts and services, and be sure to unbind them when you don't need them.

10. Icano stream

The operation of the Icano stream is complete, the read and write is finished, and remember to close it.

11. Thread

When a thread no longer needs to continue execution, remember to close it in time. It is not easy to open too many threads. It is generally the same as the number of cores on your own machine. It is recommended to use thread pool when starting threads.

12 、 String/StringBuffer

When there are more characters that need to be stitched, StringBuffer is recommended.

The above is about the content of this article on "how to achieve memory management in Android". I believe we all have a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.