Android app slow to optimize for memory jitter and memory leaks

Previous blog postIn the second case of memory jitter, it is necessary to create objects in a short time, but to control the number, this problem can now be solved using the object pooling method.

3) Object Pools

One of the frequently encountered problems in a program is the creation of a large number of objects in a short period of time, resulting in memory tension that triggers GC to cause performance problems. For this problem, we can use the object pooling technique to solve it. Typically objects in an object pool may be bitmaps,views,paints, and so on. For an idea of how the object pool works, do not unfold, see the following illustration:

There are many advantages to using object pooling technology, which avoids memory jitter and improves performance, but there are some things that require special attention when you use it. Normally, the initialized object pool is blank, when an object is used, the object pool query is present, if it does not exist then it is created and then joined to the object pool, but we can also populate the object pool with some data that is about to be used in advance when the program is started. This allows for faster first-time loading when you need to use these objects, which is called pre-allocation. Using object pooling also has a bad side, programmers need to manually manage the allocation and release of these objects, so we need to use this technique carefully to avoid the memory leaks of objects. To ensure that all objects are released correctly, we need to ensure that the objects that join the object pool and other external objects do not have a mutually referenced relationship.

In fact, the object pool to the author feel similar to the thread pool, the difference is the center of gravity is different, the thread pool is the speed of the increase (using pre-generation of idle threads), the object pool more focused on the number (perhaps the allocated object memory time is very short, so do not need pre-allocation, resulting in the object pool pre-allocation

Now the problem is not solved, the object pool is good for solving the memory jitter, but it is just a concept of ideas, not materialized. How to achieve, I recommend the use of Java Linkedhashmap This class, and ordinary hashmap have different, that is, you can control the number of Linkedhashmap more detailed information, I have reproduced a great feeling about Linkedhashmap blog , click here to view.

Here Android has provided a class that can solve the problem of control quantity

LRU cache by using the LINKEDHASHMAP implementation of the LRU cache (least recently used) algorithm, which is an algorithm of the operating system, the specific Baidu many, here ominous fine description.

LRUCache implementation and use, the author also reproduced a blog, feel very full Click here to view, see Mom no longer worry about my Android program memory jitter.

A memory leak is also mentioned at the end of the previous article, but a stroke of the previous memory leak discovery and positioning, in general, the common occurrence of memory leak location and the solution is as follows:

1. Collection classes

The collection class if there is only a mechanism for adding elements, and there is no corresponding removal of the element mechanism, this will cause memory to be occupied, if the class is a global variable (such as a static attribute in the class, global map, etc., there is a static reference or final always point to it).  Then there is no corresponding removal mechanism, which is likely to cause the collection to increase in memory only. Workaround: When using the collection class, increase the deletion element mechanism and make appropriate calls to reduce the memory occupied by the collection.

2. Single-case mode

Improper use of Singleton mode can also cause a memory leak when a singleton object is initialized for the entire lifetime of the JVM (in the form of a static variable), and if the Singleton object holds a reference to an external object, the external object will always occupy memory and may cause a memory leak (depending on whether the external object is consistent and useful). WORKAROUND: Avoid external object references that are not always useful in a singleton object.

Use of 3.Android components or Special collection objects

Braodcastreceiver, Contentobserver,fileobserver,cursor,callback, etc. in activity Ondestory or some kind of life cycle after the end must be Unregistere or close off, otherwise the activity class will be strongly referenced by the system, will not be recycled. Do not directly refer to the activity as a member variable, if you have to do so, call the private weakpeferense mactivity to do, the same, for the service and other objects with their own life cycle, Direct references all need to consider whether there is a possibility of a memory leak.

4.Handler

You know, as long as the message sent by handler has not been processed, the message and the handler object that sent it will be held by the thread MessageQueue. Because handler belongs to the TLS (Thread Local Storage) variable, the life cycle and activity are inconsistent. Therefore, this implementation is generally difficult to ensure that the life cycle of the view or activity is consistent, it is easy to cause the failure to release correctly.   As mentioned above, handler use to be particularly careful, otherwise it is likely a memory leak. Workaround: Make sure that handler has no unhandled messages (especially delay messages) before the view or activity life cycle ends.

5.Thread memory leaks

Threads are also an important source of memory leaks, and the main reason for a thread's memory leak is that the thread life cycle is not controllable, such as the thread is the inner class of activity, and a reference to the activity is saved in the thread object, and when the thread's run function takes longer to end, The thread object is not destroyed, so the old activity it refers to has a memory leak problem. WORKAROUND: 1. Simplify the task performed by the thread run function so that he runs out of tasks before the end of the activity life cycle. 2. Increase the undo mechanism for thread, and when the activity life cycle ends, the thread's time-consuming task is revoked (I recommend this).

6. Memory pressure caused by some bad code

Some code does not cause memory leaks, but they do not effectively and promptly release unused memory, or do not effectively use existing objects but frequently request new memory.

(1) Bitmap did not call recycle ()

When the Bitmap object is not in use, we should call recycle () to free the memory before it is empty, because the memory space of the Bitmap object is loaded, partly Java, and partly C (because the BITMAP allocation is called by JNI, Android's bitmap is implemented using the Skia graphics library, Skia is implemented in C). This recycle () function is the memory release for part C.

(2) When constructing adapter, the cached Convertview is not used. Workaround: Construct the adapter in a static holdview manner.

This is where memory jitter and memory leaks are discovered, positioned and resolved to complete the description.

Android app slow to optimize for memory jitter and memory leaks