Android: Memory control and Oom processing

  1. What is the relationship between OOM (memory overflow) and memory Leak (leak)?

Oom may be due to memory Leak, or it may be that your application consumes more RAM (than the slice-browsing type). Therefore, the occurrence of oom is not necessarily memory Leak.

Also, memory leak does not necessarily cause oom, and if the leak is slow, it may be restarted without a usable memory application, and it will not be oom. Of course, there are bugs that solve the best.

2. What is the shallow heap and the retained heap?

• Shallow heap: How much memory you own, such as you have an int attribute, which accounts for 4 bytes. Does not include other objects that you reference.
• Retained heap: If you are destroyed, how much memory will be released in total. The space occupied by your presence is the retained heap.

3. What is GC roots?

GC, it is from these nodes to start the traversal, keep looking for its child nodes until the end. Then release the nodes that cannot be traversed. The starting point of these loops (note, not a OH) is called GC roots.

So, for Java, who is GC roots? The simple point that (not so accurate) includes the following:

• Local variables above the stack
• function parameter variables above the stack
• All class variables loaded by bootstrap loader
• In addition, JNI-related will also have
• For more detailed explanations please see this blog post

4. How do I use the mat to locate memory leaks?

4.1 See Histogram (class chart)

For Android programs, memory leaks usually involve activity. Therefore, before dump, you can rotate the screen several times and repeatedly in and out of the potentially problematic activity, let the problem as much as possible.
By histogram we can see how many instances each class has, and how large the shallow and retained heap are respectively. If you just look at Java's underlying types and framework classes, it doesn't make sense to filter out your own types, such as

found that Leakinnerclassactivity produced 9 instances, must have been hold.

4.2 See Dominator Tree

How to use has not been clear, feeling and histogram than nothing special pinch, hey

4.3 Compared to the heap dumps, the location of memory leaks can be located faster. Operation Steps:

• Open a hprof file, switch to histogram view
• Right-click Histogram in Navigation View and select Add to compare basket
• Open another Hprof file, and repeat the previous step
• Compare the contents of the heap dumps two times, and see that the leakinnerclassactivity instance adds another. And I just started the activity again, so the problem is obvious.

Reference: Memory Analysis for Android applications

5. How can internal classes be used to generate memory leaks, and how to solve the Asynctask and handler problems derived therefrom?

• If the method of a non-static inner class has a life cycle greater than its class, then there is a problem. For example: Asynctask, Handler, these two classes are convenient for developers to perform asynchronous tasks, but both of these jump out of the activity/fragment life cycle.
• Why? Because a non-static inner class automatically holds an instance of the owning class, if an instance of the owning class has ended the life cycle, but the method of the inner class is still executing, the body is held. It also causes the principal to not be released, i.e. memory leaks.
• What about static classes? Static classes are compiled and non-intrinsic classes are the same, with their own independent class names. Instances of the owning class are not silently quoted, so it is not easy to divulge.

First, static class Incominghandler extends Handler {    ///second, weak reference    private final weakreference< Udplistenerservice> Mservice;     Incominghandler (Udplistenerservice service) {        mservice = new weakreference<udplistenerservice> (service);    }    @Override public    void Handlemessage (Message msg) {         Udplistenerservice service = Mservice.get ();         if (service! = null) {              service.handlemessage (msg);}}}    

6. How does an oom solution be caused by an image?

• When loading, use option, how large, and how large to load.
• Res directory image is the same, in time to clean up the large picture resources.
• If there is a problem, try to get rid of the invisible resources, for example, the fragment in Tab,viewpager in Tabactivity.
• If the activity has more picture resources, you need to consider destroying the existing resources when the screen spins. Please refer to this article

7. Do you use activity or application when you need the context?

• See if the period of use is within the activity cycle, if exceeded, must use application; Common scenarios include: Asynctask,thread, third-party library initialization, and so on.
• There are also situations where you can only use activity: for example, dialog boxes, various view, startactivity, etc.
• In short, use application whenever possible. Reference StackOverflow

8. When do I need to manually set the variable to null?

• Class variables, once run out, release as soon as possible. Because the class has the longest surviving time, the less resources it takes, the better;
• More time-consuming and memory-intensive methods within the local variables, such as the method of image processing, each bitmap object is discarded in time. Let the GC intervene as much as possible.
• Transferred from: http://m.oschina.net/blog/128309

Android: Memory control and Oom processing